Simple Space Shooter (source included)
by Clint Herron · in Torque Game Builder · 12/06/2006 (10:18 am) · 29 replies
Hey all!
Here is a project I've been working on for the past few weeks. It's an attempt to make a game that focuses on having good cooperative multiplayer. When we were created, I feel we were wired for games. I really think that cooperative gaming was one of the things God had in mind when He created us, and I feel a distinct lack of good implementations of that in games today. MMOs of course have great cooperative play, Lego Starwars has fantastic cooperative play, and the Diablo series is right up there as well.
But I feel there could be more. One of the things that bugs me about the camera in Secret of Mana and Lego Starwars is that the camera only zooms out so far, and then you're locked. It can make for frustrating gameplay.
So I decided to experiment with a dynamically zoomable camera in Torque Game Builder. For that, I returned to my perennial project of Air Locked, and in an evening or two had learned enough to get a camera that updates itself to track all of the players on the screen. I think it's pretty neat!
I took some more evenings to learn how to do some AI, and spent a fair bit of time poring over equations in Wikipedia's Torpedo Data Computer entry (which was incredibly helpful).
I finally got some AI that uses trig properly to lead targets accurately, and I must say I think I understand why games like Escape Velocity didn't do this -- it's quite tough at times!
But I persevered and prevailed. Here's a screenshot:
Download the game!
Or, if you're so inclined, feel free to even check out the source -- at some point, I intend to add two-players-one-keyboard multiplayer, and hopefully at some point in the future Internet multiplayer. The game layout was designed so that multiple players could hop-in and hop-out without disrupting gameplay for the others (because cooperative AI could take over for any players who left), etc.
I realize it's somewhat small and cheesy, but I hope it's fun, and if nothing else, it's been a fantastic learning experience for me and TGB.
Feedback is appreciated, and I hope people can find it useful! Please feel free to copy/paste and learn from that source code, or even build bigger games from it. I'll continue to be working on it, and hope to eventually open it up as a fun game that can bring people together having fun. :)
Cheers!
--clint
Here is a project I've been working on for the past few weeks. It's an attempt to make a game that focuses on having good cooperative multiplayer. When we were created, I feel we were wired for games. I really think that cooperative gaming was one of the things God had in mind when He created us, and I feel a distinct lack of good implementations of that in games today. MMOs of course have great cooperative play, Lego Starwars has fantastic cooperative play, and the Diablo series is right up there as well.
But I feel there could be more. One of the things that bugs me about the camera in Secret of Mana and Lego Starwars is that the camera only zooms out so far, and then you're locked. It can make for frustrating gameplay.
So I decided to experiment with a dynamically zoomable camera in Torque Game Builder. For that, I returned to my perennial project of Air Locked, and in an evening or two had learned enough to get a camera that updates itself to track all of the players on the screen. I think it's pretty neat!
I took some more evenings to learn how to do some AI, and spent a fair bit of time poring over equations in Wikipedia's Torpedo Data Computer entry (which was incredibly helpful).
I finally got some AI that uses trig properly to lead targets accurately, and I must say I think I understand why games like Escape Velocity didn't do this -- it's quite tough at times!
But I persevered and prevailed. Here's a screenshot:
Download the game!
Or, if you're so inclined, feel free to even check out the source -- at some point, I intend to add two-players-one-keyboard multiplayer, and hopefully at some point in the future Internet multiplayer. The game layout was designed so that multiple players could hop-in and hop-out without disrupting gameplay for the others (because cooperative AI could take over for any players who left), etc.
I realize it's somewhat small and cheesy, but I hope it's fun, and if nothing else, it's been a fantastic learning experience for me and TGB.
Feedback is appreciated, and I hope people can find it useful! Please feel free to copy/paste and learn from that source code, or even build bigger games from it. I'll continue to be working on it, and hope to eventually open it up as a fun game that can bring people together having fun. :)
Cheers!
--clint
About the author
#2
12/09/2006 (7:31 pm)
This is a nice little resource. Thanks for the look at your code!
#3
Chris: Thanks for the nice feedback. :) I'm really glad to hear that snippets have been useful in your game. If you think of a good solution for the super-far camera, I'm very interested in hearing it. About the best I can think of is splitting the view into multiple sections when they're very far apart, and then merging them together again when closer -- but I'm not even sure how well that would work.
Dan: Glad you enjoyed it! :) I hope to keep updating this.
Several people have expressed interest in seeing this once it gets networking enabled. I've been studying Torque networking, and I think I'm going to tackle that soon. In the meantime, I've now gotten cooperative two-players-on-one-keyboard to work.
I really like the cooperative gaming in Lego Starwars -- one of the favorite things that I like is how easy it is for players to hop into the game and drop out, without affecting the other player, because the AI is free to take over. It makes for a very casual multiplayer environment.
Keys:
Jump in/jump out:
Player 1: \
Player 2: g
Thrust:
Player 1: Up
Player 2: w
Left/Right:
Player 1: Left/Right
Player 2: a/d
Fire:
Player 1: rcontrol
Player 2: g
The game starts out in double-AI mode, and you have to press your join button to get into the game.
Download the game
Download the source
Screenshot 1
Screenshot 2
Screenshot 3
Once again, this isn't multiplayer over network yet, only two players on the same keyboard. Regardless, I still wanted to post this so that people could see an example of multiplayer gaming that lets players hop in and hop out on the fly.
Cheers!
--clint
12/10/2006 (11:45 am)
Hey all!Chris: Thanks for the nice feedback. :) I'm really glad to hear that snippets have been useful in your game. If you think of a good solution for the super-far camera, I'm very interested in hearing it. About the best I can think of is splitting the view into multiple sections when they're very far apart, and then merging them together again when closer -- but I'm not even sure how well that would work.
Dan: Glad you enjoyed it! :) I hope to keep updating this.
Several people have expressed interest in seeing this once it gets networking enabled. I've been studying Torque networking, and I think I'm going to tackle that soon. In the meantime, I've now gotten cooperative two-players-on-one-keyboard to work.
I really like the cooperative gaming in Lego Starwars -- one of the favorite things that I like is how easy it is for players to hop into the game and drop out, without affecting the other player, because the AI is free to take over. It makes for a very casual multiplayer environment.
Keys:
Jump in/jump out:
Player 1: \
Player 2: g
Thrust:
Player 1: Up
Player 2: w
Left/Right:
Player 1: Left/Right
Player 2: a/d
Fire:
Player 1: rcontrol
Player 2: g
The game starts out in double-AI mode, and you have to press your join button to get into the game.
Download the game
Download the source
Screenshot 1
Screenshot 2
Screenshot 3
Once again, this isn't multiplayer over network yet, only two players on the same keyboard. Regardless, I still wanted to post this so that people could see an example of multiplayer gaming that lets players hop in and hop out on the fly.
Cheers!
--clint
#4
12/10/2006 (6:13 pm)
@Clint, very very interesting game ... very easy to get lost and not be able to get to a point where you have control, but VERY interesting idea ... however, I played the game straight from the source, loading up the main.t2d and was unable to get Player 1 to actually fire using my 'rcontrol' key -- I tried right control, left control, and a number of other keys as well, and my player just would not fire, had great fun moving him around the screen and watching it zoom ever so nicely though -- great job.
#5
Oh, can I offer a suggestion that might make the appearance even better?
Convert your planets from sprites into 3d sphere objects, then have them set to rotate on an X/Y like a planet would ... I believe that'd add an extra bit of flare to the overall appearance, as well as add an added level of confusion into the gameplay as the center object is constantly "in motion" ...
12/10/2006 (6:28 pm)
@Clint, I just looked at the art resources for this game -- I'm a bit confused about something, the ship artwork is made up of a a very large tilemap (imagemap) ... From the brief gameplay I had, I did not see any reason to use this type of artwork as a single image which is told to rotate would have sufficed ... am I to understand that the code actually tells the graphics to switch when the rotation changes?Oh, can I offer a suggestion that might make the appearance even better?
Convert your planets from sprites into 3d sphere objects, then have them set to rotate on an X/Y like a planet would ... I believe that'd add an extra bit of flare to the overall appearance, as well as add an added level of confusion into the gameplay as the center object is constantly "in motion" ...
#6
Not sure why you would have a problem with the rcontrol key -- it Works For Me (tm) on my machine. However, if you want to remap it to comma or something, you can edit it in the player.cs file -- it's right near the top of the source and should be fairly easy to find.
Regarding the art resources -- you're right that one could write this with simply rotating a sprite. There are two reasons that I use separate images.
#1) That's the way I got my original ship graphics, way back in the day. Air Locked was the first big project that I cut my teeth on as a budding programmer 10 or 12 years ago, and I used a graphics format ripped from an old game called Subspace. So that's the first reason -- is because I am just re-using my ship graphics that are 10 years old (though the bug enemy I created just a week ago).
#2) Because while you may not notice it, there are subtle lighting and angle changes with the graphics. You can see the ship exhaust ports when the ship is facing upwards, but not when it is facing downwards. There are also lighting hilights that move around on the ship the way you would expect them to that you wouldn't see happen if it were a simple rotated graphic. It's not like I just rotated the picture 9 degrees and stored each one in sequence in the file -- those are all actually separate renders from the modeling program that are film-stripped together.
Thanks for checking out the source! I really appreciate the feedback and questions. :)
Edit: BTW, I really liked your split-screen example, and I'm mentally playing with the idea of a split-screen that fades in when ships get too far apart, and fades out to be a single large screen when the ships get close enough together. We'll see if I get the gumption together to work on that though -- a more pressing matter is to add networked multiplayer to this game so that we can play it at an upcoming LAN party. :)
--clint
12/10/2006 (6:40 pm)
Hey David!Not sure why you would have a problem with the rcontrol key -- it Works For Me (tm) on my machine. However, if you want to remap it to comma or something, you can edit it in the player.cs file -- it's right near the top of the source and should be fairly easy to find.
Regarding the art resources -- you're right that one could write this with simply rotating a sprite. There are two reasons that I use separate images.
#1) That's the way I got my original ship graphics, way back in the day. Air Locked was the first big project that I cut my teeth on as a budding programmer 10 or 12 years ago, and I used a graphics format ripped from an old game called Subspace. So that's the first reason -- is because I am just re-using my ship graphics that are 10 years old (though the bug enemy I created just a week ago).
#2) Because while you may not notice it, there are subtle lighting and angle changes with the graphics. You can see the ship exhaust ports when the ship is facing upwards, but not when it is facing downwards. There are also lighting hilights that move around on the ship the way you would expect them to that you wouldn't see happen if it were a simple rotated graphic. It's not like I just rotated the picture 9 degrees and stored each one in sequence in the file -- those are all actually separate renders from the modeling program that are film-stripped together.
Thanks for checking out the source! I really appreciate the feedback and questions. :)
Edit: BTW, I really liked your split-screen example, and I'm mentally playing with the idea of a split-screen that fades in when ships get too far apart, and fades out to be a single large screen when the ships get close enough together. We'll see if I get the gumption together to work on that though -- a more pressing matter is to add networked multiplayer to this game so that we can play it at an upcoming LAN party. :)
--clint
#7
12/10/2006 (6:57 pm)
@Clint, I'm glad you liked my split-screen resource, however, I can't take full credit for it as I really did just copy the idea from one of the TorqueX starter kits provided with the beta (I asked permission first, heh) -- I am hopefully going to extend on the idea and provide a code library or whatever that allows for easy integration into a game and configuring 1-8 or 1-4 or whatever players and have the scene windows automatically created and share the scenegraph and auto-size and position them, etc ... but who knows, time is a very interesting obstacle ;)
#8
12/10/2006 (6:58 pm)
Oh and -- I figured there had to be some subtle differences in the graphics, but the images are so small when looking at them in windows, it was hard to notice ...
#9
I just downloaded your source and am looking it over (I'm at work right now (shhh!) and can't run it until I get home). First off, THANK YOU for sharing. I just purchased the TGB license a couple days ago, and am slowly climbing the learning curve. This will certainly be a good guide.
A question and a comment, both regarding your UpdateCamera() function
1) I see you call UpdateMovement in UpdateCamera, which is in turn, called by UpdateScene. Is your method of using user input to set movement flags, and then having a single UpdateMovement method called via UpdateScene a pretty typical setup? I did it in my little LunarLander test game, but wasn't sure if that was The Best Way(tm) to do it.
2) Your dynamic camera sizing method looks really fantastic. I can't wait to see it in action. I wonder, though, if you might be able to clean up the "firstpass" concept a little. I'd suggest that rather than setting the min/max X/Y variables to 0 at the start, set MinX and MinY to a REALLY BIG value. Set MaxX and MaxY to a REALLY SMALL value. Then just run through the loop and forget the whole first-pass thing. Just a thought...
Thanks again!
Adman
12/18/2006 (1:35 pm)
Hey Clint...I just downloaded your source and am looking it over (I'm at work right now (shhh!) and can't run it until I get home). First off, THANK YOU for sharing. I just purchased the TGB license a couple days ago, and am slowly climbing the learning curve. This will certainly be a good guide.
A question and a comment, both regarding your UpdateCamera() function
1) I see you call UpdateMovement in UpdateCamera, which is in turn, called by UpdateScene. Is your method of using user input to set movement flags, and then having a single UpdateMovement method called via UpdateScene a pretty typical setup? I did it in my little LunarLander test game, but wasn't sure if that was The Best Way(tm) to do it.
2) Your dynamic camera sizing method looks really fantastic. I can't wait to see it in action. I wonder, though, if you might be able to clean up the "firstpass" concept a little. I'd suggest that rather than setting the min/max X/Y variables to 0 at the start, set MinX and MinY to a REALLY BIG value. Set MaxX and MaxY to a REALLY SMALL value. Then just run through the loop and forget the whole first-pass thing. Just a thought...
Thanks again!
Adman
#10
1) Yes. I set movement flags, and then I look for them in my main game update function. This is the way I've almost always done my game programming. I would guess that it's one particular school of thought that does it this way, but as far as it being the Best Way(tm) -- I dunno'. I think it's the Best Way(tm) for larger projects, but for smaller projects (such as tutorials), it's often more understandable to just update the player's velocity and stuff in the key kit handlers. A nice thing about setting flags like this though, is that it made it really easy for me to have my AI simulate keypresses.
2) You're right -- the first pass concept is a little off. I should have deleted the first pass code out of there -- setting the initial values to 0,0 is actually intentional (I didn't used to do it that way) -- originally, the camera would just focus on the players, whether they were near the planet or not. However, that made it *really* easy to lose the planet's view. So since the planet is at 0,0, I decided to make at least that always in view -- so that's why I have those numbers as initial values.
I've gotten health bars added to the game, and I've been experimenting with making the game more of a progressive challenge by spawning more enemies, but in the process, I seem to have made the game less fun. So I'm trying to analyze what I changed that made it lose fun, and so progress on this game is in "rumination" mode. However, if you (or anyone else) would like to see it with health bars, I might post that as heavily WIP code.
Cheers!
--clint
12/19/2006 (10:33 am)
Hey Adam! Thanks so much for checking out the source! :)1) Yes. I set movement flags, and then I look for them in my main game update function. This is the way I've almost always done my game programming. I would guess that it's one particular school of thought that does it this way, but as far as it being the Best Way(tm) -- I dunno'. I think it's the Best Way(tm) for larger projects, but for smaller projects (such as tutorials), it's often more understandable to just update the player's velocity and stuff in the key kit handlers. A nice thing about setting flags like this though, is that it made it really easy for me to have my AI simulate keypresses.
2) You're right -- the first pass concept is a little off. I should have deleted the first pass code out of there -- setting the initial values to 0,0 is actually intentional (I didn't used to do it that way) -- originally, the camera would just focus on the players, whether they were near the planet or not. However, that made it *really* easy to lose the planet's view. So since the planet is at 0,0, I decided to make at least that always in view -- so that's why I have those numbers as initial values.
I've gotten health bars added to the game, and I've been experimenting with making the game more of a progressive challenge by spawning more enemies, but in the process, I seem to have made the game less fun. So I'm trying to analyze what I changed that made it lose fun, and so progress on this game is in "rumination" mode. However, if you (or anyone else) would like to see it with health bars, I might post that as heavily WIP code.
Cheers!
--clint
#12
Of course spliting the screen would also solve this problem, but in my humble opinion I think I'd prefer a single screen game. Any way, keep up the good work :)
Oh.. and by the way..
Happy new year!
[edit]
Spelling ^^;;
12/31/2006 (6:31 am)
Another thing I'd love to see in this game is some sort of "P1" and "P2" icons appearing above the ships when the game is zoomed out. The smaller the ships are the harder it is to tell the difference between them.Of course spliting the screen would also solve this problem, but in my humble opinion I think I'd prefer a single screen game. Any way, keep up the good work :)
Oh.. and by the way..
Happy new year!
[edit]
Spelling ^^;;
#13
When they get so small you can't see them anymore, make an icon of the player's ships appear next to their score or their name (step in, step out) that shows what direction their facing.
So the little icon would use the same graphics and update what direction it is facing just like the regular ship, but always at the same size.
07/04/2007 (1:51 am)
I'm about half a year late to the party, but Jakob's last post just gave me an idea on how to solve the problem with seeing which way they are facing.When they get so small you can't see them anymore, make an icon of the player's ships appear next to their score or their name (step in, step out) that shows what direction their facing.
So the little icon would use the same graphics and update what direction it is facing just like the regular ship, but always at the same size.
#14
07/04/2007 (8:17 am)
That's actually a really good idea -- sortof a mini focused camera that is always focused on the player to give a detailed view of their ship. That's a pretty good idea!
#15
That way, you don't have to write update code to keep updating both the player and the player icon ... you just simply write your code as if nothing has changed ...
the cool side effect is ... you can see the player explode in the tiny scene graph ... or, with a few extra lines, you can stop that tiny scenegraph from displaying objects in certain groups or layers ... or to only show certain groups or layers ... so it only ever shows the player, for example.
Not necessarily the 'right' way to go ... but it's a fun little trick I like to play with :)
07/04/2007 (10:46 am)
In the case that clint mention, the 'mini focused camera' ... you could actually make it a mini focused camera, hehe ... check out one of my earlier .plans where I mentioned a Split-Screen method for TGB games ... use the same general idea, but place a tiny scenegraph where you want the player ship to appear ... then in your startup code, mount the tiny scenegraphs camera to the player ... and it will always show the player ... :)That way, you don't have to write update code to keep updating both the player and the player icon ... you just simply write your code as if nothing has changed ...
the cool side effect is ... you can see the player explode in the tiny scene graph ... or, with a few extra lines, you can stop that tiny scenegraph from displaying objects in certain groups or layers ... or to only show certain groups or layers ... so it only ever shows the player, for example.
Not necessarily the 'right' way to go ... but it's a fun little trick I like to play with :)
#16
Do scene graphs have an alpha? It would be neat to only fade in those focused views when the zoom level is past a certain level.
--clint
07/04/2007 (10:54 am)
I didn't realize that one could keep a scene graph from showing certain layers or groups -- that would be extremely cool. :)Do scene graphs have an alpha? It would be neat to only fade in those focused views when the zoom level is past a certain level.
--clint
#17
as for displaying certain layers and groups ... look at the masking functions in the docs to see how
The masking also works in the regular sceneWindow2D default graph ... so you can hide and show things more or less 'on the fly' ...
07/04/2007 (11:08 am)
Scenegraphs by nature are transparent ... so if the objects in them are transparent ... you'll see through it ... a scenegraph is effectively just a camera view ... so you can treat it as such ... think of it like a window ... as for displaying certain layers and groups ... look at the masking functions in the docs to see how
The masking also works in the regular sceneWindow2D default graph ... so you can hide and show things more or less 'on the fly' ...
#18
Just read through this entire thread. This game sounds really brilliant and I just downloaded it, I can't wait to give it a try!
That's pretty hilarious that you used a certain "Torpedo Data Computer" on wikipedia for your AI! I have some enemies in my current project that need to lead the player, and I got a decent AI out of just . . . "guessing" at it, though it is never one hundred percent. The hard part is getting the enemy to predict where the player is going to be.
But anyway, I'll let you know when I give your game a spin.
07/10/2007 (7:36 am)
Hey Clint!Just read through this entire thread. This game sounds really brilliant and I just downloaded it, I can't wait to give it a try!
That's pretty hilarious that you used a certain "Torpedo Data Computer" on wikipedia for your AI! I have some enemies in my current project that need to lead the player, and I got a decent AI out of just . . . "guessing" at it, though it is never one hundred percent. The hard part is getting the enemy to predict where the player is going to be.
But anyway, I'll let you know when I give your game a spin.
#19
I haven't forgotten about this game, and there are a number of un-published changes sitting on my hard drive.
To be honest, I've been so enthralled by the behavior system in 1.5, that I've not done much TGB development. It's like a prize that's just out of my reach -- the beta seems so close, but it doesn't feel usable for me to start projects with it.
I'm looking forward to taking my "torpedo data computer" aiming code and putting that into a behavior, and making a flexible enemy system for this game. It just doesn't seem that it's very easy or convenient to add new behaviors at this point though, so I've been holding off doing anything until I see an example of the Right Way to do it.
I look forward to hearing your impressions of the game so far, and I hope to revive this project when behaviors gets off the ground.
Cheers!
--clint
07/10/2007 (8:05 am)
Hey Kevin, thanks for your interest in my game!I haven't forgotten about this game, and there are a number of un-published changes sitting on my hard drive.
To be honest, I've been so enthralled by the behavior system in 1.5, that I've not done much TGB development. It's like a prize that's just out of my reach -- the beta seems so close, but it doesn't feel usable for me to start projects with it.
I'm looking forward to taking my "torpedo data computer" aiming code and putting that into a behavior, and making a flexible enemy system for this game. It just doesn't seem that it's very easy or convenient to add new behaviors at this point though, so I've been holding off doing anything until I see an example of the Right Way to do it.
I look forward to hearing your impressions of the game so far, and I hope to revive this project when behaviors gets off the ground.
Cheers!
--clint
#20
I did get a chance to play your game and I was pretty impressed with the camera zooming. It was so smooth and always kept all ships in sight, nice work! I just played alone, but I suspect it would be much more fun with 2 people. I liked the handling of the ship, but it does take a while to get used to. It was pretty difficult to hit the enemy ships, but I might just be really bad.
You had a good idea and you executed it well. A game is never finished though! ;)
07/10/2007 (12:59 pm)
I have yet to look at the beta version of TGB, but I hear that it's pretty sweet. I don't really know what you mean by behaviors, but I assume different types of AI. With Glatte 2 I have some different types of AI: Fly By, Charge, Delayed Charge, and Sweep. The current ones work pretty well, but I hope to add some more and tweak the existing ones.I did get a chance to play your game and I was pretty impressed with the camera zooming. It was so smooth and always kept all ships in sight, nice work! I just played alone, but I suspect it would be much more fun with 2 people. I liked the handling of the ship, but it does take a while to get used to. It was pretty difficult to hit the enemy ships, but I might just be really bad.
You had a good idea and you executed it well. A game is never finished though! ;)
Torque 3D Owner Chris Jorgensen
Cascadia Games LLC
One bad thing about a camera that zooms out super far, imo, is the sprites get so small that the players can't tell which direction they're aiming. I'm still working on a solution for this in my game.