TGB and Prototyping
by Jerrod Putman · 12/11/2007 (3:06 am) · 8 comments
So it was just over a week ago that I decided to stop procrastinating and finally sit down and make something with Torque Game Builder. I'd had an idea of what I wanted to do for a while, but I kept getting bogged down in design specifics when I would try to write out a game design document. Finally, I just said that there's no way I can really know beforehand what's really going to work, especially if I want to try different things. So I just decided that I knew enough about what I was trying to do to just start working and see where I ended up.
I've been wanting to do a turn-based tactical strategy game for a while now, so I basically began at the beginning. I created a script class for the base unit (which will be customized through datablocks), the player (with support for multiple players on the same local machine), and the battlefield controller, which keeps track of everything and maintains order.
I essentially assembled everything one piece at a time, keeping in mind where I was trying to go, but not really trying to plan for features that may or may not make it into the game. This type of development was pretty revelatory to me -- usually I like to have everything laid in front of me before I start development. Unfortunately, when I have that, I start trying to develop the whole thing at once, instead of doing things in small, iterative pieces. This time around, I started with getting units to snap to the tile layer grid. I can place them anywhere on the map, and they'll automatically snap to the center of the nearest tile layer grid. Nothing fancy, but it was something that I could see.
The following days, I worked on the mechanics for selecting a unit, determining and highlighting the tiles that he could move to, selecting and moving the unit to the selected tile, calculating the targets in range and the ability to select them, and actually performing an attack. It was nice to see things come together piece by piece so quickly. TGB is pretty much perfect for throwing together a prototype really quickly.
As of tonight, I just managed to get multiple player controllers into the game, meaning that here are actually two teams of units on the map that can attack each other (before this, any unit could attack any other unit). So in some basic form, I actually have the beginnings of a game.
So a week later, and here are a few screens of what I've got. You'll have to forgive the temporary art. My intention wasn't necessarily to make something that looked great, but something that demonstrated the gameplay elements clearly enough.
What you see when you start the game. Notice the tile cursor in the upper left corner. This moves around with the mouse cursor, but stays snapped to the tiles so that the player knows exactly what tile he'll be clicking on when he clicks.
Here is a screen after one of the units has been selected. The tiles where the unit can move have been highlighted. Notice that it looks like the unit's movement is severely hampered going over the sand tiles. I implemented movement costs into the tiles using tile custom data.
The red unit is about to attack the blue unit. When a unit moves within attack range of another unit, the tile beneath the opposing unit with turn red, denoting that you can attack him. You can't see it in this image, but multiple units can be in attack range at once, allowing the player to pick from multiple targets.
Poor blue unit. Even though his friend came to help, it was too late.
So there you go. It doesn't look like much, but as this is essentially still the prototyping phase of the project, it doesn't need to look like much. Just the fact that the essential gameplay elements are there is a big help in determining some of the specifics for the game's design.
Up next on my plate is to try and figure out TGB's GUI system. Also, I'm planning on putting in networking support for the small portion that I have running here. I've written the classes in a way that I think will make it easy to just write the client/server scripts on top of. We'll see how it turns out though.
Also of note, I'm using 1.5.1, but I decided not to use behaviors. I felt the added complexity of trying to get behaviors to talk to each other and not step on each other wasn't worth it considering that most of the units in the game will have what is essentially the same functionality with a different coat of paint. I do plan on using behaviors for certain things though. I think the great part of TGB is that I can choose to use either method.
Anyways, that's all for me now. Time to sleep!
I've been wanting to do a turn-based tactical strategy game for a while now, so I basically began at the beginning. I created a script class for the base unit (which will be customized through datablocks), the player (with support for multiple players on the same local machine), and the battlefield controller, which keeps track of everything and maintains order.
I essentially assembled everything one piece at a time, keeping in mind where I was trying to go, but not really trying to plan for features that may or may not make it into the game. This type of development was pretty revelatory to me -- usually I like to have everything laid in front of me before I start development. Unfortunately, when I have that, I start trying to develop the whole thing at once, instead of doing things in small, iterative pieces. This time around, I started with getting units to snap to the tile layer grid. I can place them anywhere on the map, and they'll automatically snap to the center of the nearest tile layer grid. Nothing fancy, but it was something that I could see.
The following days, I worked on the mechanics for selecting a unit, determining and highlighting the tiles that he could move to, selecting and moving the unit to the selected tile, calculating the targets in range and the ability to select them, and actually performing an attack. It was nice to see things come together piece by piece so quickly. TGB is pretty much perfect for throwing together a prototype really quickly.
As of tonight, I just managed to get multiple player controllers into the game, meaning that here are actually two teams of units on the map that can attack each other (before this, any unit could attack any other unit). So in some basic form, I actually have the beginnings of a game.
So a week later, and here are a few screens of what I've got. You'll have to forgive the temporary art. My intention wasn't necessarily to make something that looked great, but something that demonstrated the gameplay elements clearly enough.
What you see when you start the game. Notice the tile cursor in the upper left corner. This moves around with the mouse cursor, but stays snapped to the tiles so that the player knows exactly what tile he'll be clicking on when he clicks.
Here is a screen after one of the units has been selected. The tiles where the unit can move have been highlighted. Notice that it looks like the unit's movement is severely hampered going over the sand tiles. I implemented movement costs into the tiles using tile custom data.
The red unit is about to attack the blue unit. When a unit moves within attack range of another unit, the tile beneath the opposing unit with turn red, denoting that you can attack him. You can't see it in this image, but multiple units can be in attack range at once, allowing the player to pick from multiple targets.
Poor blue unit. Even though his friend came to help, it was too late.So there you go. It doesn't look like much, but as this is essentially still the prototyping phase of the project, it doesn't need to look like much. Just the fact that the essential gameplay elements are there is a big help in determining some of the specifics for the game's design.
Up next on my plate is to try and figure out TGB's GUI system. Also, I'm planning on putting in networking support for the small portion that I have running here. I've written the classes in a way that I think will make it easy to just write the client/server scripts on top of. We'll see how it turns out though.
Also of note, I'm using 1.5.1, but I decided not to use behaviors. I felt the added complexity of trying to get behaviors to talk to each other and not step on each other wasn't worth it considering that most of the units in the game will have what is essentially the same functionality with a different coat of paint. I do plan on using behaviors for certain things though. I think the great part of TGB is that I can choose to use either method.
Anyways, that's all for me now. Time to sleep!
About the author
#2
12/11/2007 (8:48 am)
I really like the visual walk-through. Keep it up.
#3
12/11/2007 (9:42 am)
Great read-through, thanks!
#4
12/11/2007 (12:28 pm)
You're actually being very smart in building a less "artsy" prototype. You'll be able to include more flashy art later, but getting the game mechanics to a state where it's fun is really key. So never feel you should have to apologize for your prototype art. ^_^
#5
I think the only thing that you didn't specifically mention would be your "evaluate at end of spiral/iteration" phase, which I'm sure you performed, but didn't specifically mention. The evaluation of the previous iteration step is what makes the whole iterative development process work, and I teach that it is arguably the most important step!
Glad to see that you were able to move past the "I need a design document!" phase, and get to the prototyping stage, and also glad to see the process work in such an excellent manner!
12/11/2007 (2:25 pm)
Just to add to Deborah's comments, the concept of prototyping that you used is incredibly effective, and is in fact exactly what we recommend to game developers, and even what we teach in Torque Boot Camps. You hit just about every appropriate point in your write up, and utilized the concept of rapid prototyping/spiral development exceptionally well, so kudos!I think the only thing that you didn't specifically mention would be your "evaluate at end of spiral/iteration" phase, which I'm sure you performed, but didn't specifically mention. The evaluation of the previous iteration step is what makes the whole iterative development process work, and I teach that it is arguably the most important step!
Glad to see that you were able to move past the "I need a design document!" phase, and get to the prototyping stage, and also glad to see the process work in such an excellent manner!
#6
But I think you're not really "prototyping"... Or maybe I just have the wrong concept of prototype in my head. I think a protototype, as a proof of concept, should contain only the new ideas you're trying to test.
Instead, your project started with normal rts features... Maybe you should start just mocking the common features of a rts and code only the real new ideas you have for your game.
If your prototype is actually to test whether TGB is adequate to your project, then just ignore me :)
12/11/2007 (2:28 pm)
I agree with Stephen, that is great that you have chosen an iterative aproach to your development, and not the "I need a document that tells me what next week will look like" - the infamous game design document.But I think you're not really "prototyping"... Or maybe I just have the wrong concept of prototype in my head. I think a protototype, as a proof of concept, should contain only the new ideas you're trying to test.
Instead, your project started with normal rts features... Maybe you should start just mocking the common features of a rts and code only the real new ideas you have for your game.
If your prototype is actually to test whether TGB is adequate to your project, then just ignore me :)
#7
I normally teach that a true prototype is complete when you've implemented a game mechanic (not necessarily a game concept--there is a fundamental difference), and most importantly, evaluate the game mechanic for "fun". Sometimes that requires one or more iterations of development before you can even address your actual "new" (or modified) game mechanic, and that's ok--just don't go all the way towards a game concept or implementation before you start your evaluation process.
12/11/2007 (2:46 pm)
Diego has a good point, but sometimes you do have to implement a baseline before you can adequately test a new game mechanic.I normally teach that a true prototype is complete when you've implemented a game mechanic (not necessarily a game concept--there is a fundamental difference), and most importantly, evaluate the game mechanic for "fun". Sometimes that requires one or more iterations of development before you can even address your actual "new" (or modified) game mechanic, and that's ok--just don't go all the way towards a game concept or implementation before you start your evaluation process.
#8
@ Stephen: Yeah, I did the post-iteration evaluation. It was my goal to have something new that I could actually see/play at the end of every day, so that I would be able to load up the game, and see exactly how far I had come since the previous day. I can't stress how great it is to be able to see forward momentum, and not get bogged down in trying to write everything at once.
@Diego: Actually, I had two goals for this prototype -- 1) Learn TorqueScript and how to use the engine (heh); 2) Get the game to a known, playable state as quickly as possible so that I can start trying out new mechanics. The prototype isn't finished by any means. Basically, so far I've done what every other turn-based strategy game has done before (only buggier and uglier, heh). But as Stephen mentioned, I needed to get to some sort of baseline, gameplay that I knew already worked on its own, before I start playing around and trying different things. I knew the style of the game I wanted, I just didn't know a lot of the specifics.
And I would say there's actually a lot of stuff missing still. A lot of information about the units and the battlefield are pretty much just temporary code at this point. However, wherever I placed temporary code, I made sure to comment on exactly what that temporary code should be when I need to return to it. Like I said, I wasn't trying to write the game all at once -- just whatever I needed to do to get something up and running quickly.
So I guess I'm kind of agreeing with you, haha. I still have a lot of backend work that needs to be done to actually finish the project, but doesn't need to be done for the prototype.
Anyways, again, thanks for all the comments. We'll see what this week brings! Hopefully, it brings me some knowledge on how to use the GUI editor.
12/11/2007 (7:18 pm)
Thanks for all the great comments everyone! It's given me even more motivation to press onward. :)@ Stephen: Yeah, I did the post-iteration evaluation. It was my goal to have something new that I could actually see/play at the end of every day, so that I would be able to load up the game, and see exactly how far I had come since the previous day. I can't stress how great it is to be able to see forward momentum, and not get bogged down in trying to write everything at once.
@Diego: Actually, I had two goals for this prototype -- 1) Learn TorqueScript and how to use the engine (heh); 2) Get the game to a known, playable state as quickly as possible so that I can start trying out new mechanics. The prototype isn't finished by any means. Basically, so far I've done what every other turn-based strategy game has done before (only buggier and uglier, heh). But as Stephen mentioned, I needed to get to some sort of baseline, gameplay that I knew already worked on its own, before I start playing around and trying different things. I knew the style of the game I wanted, I just didn't know a lot of the specifics.
And I would say there's actually a lot of stuff missing still. A lot of information about the units and the battlefield are pretty much just temporary code at this point. However, wherever I placed temporary code, I made sure to comment on exactly what that temporary code should be when I need to return to it. Like I said, I wasn't trying to write the game all at once -- just whatever I needed to do to get something up and running quickly.
So I guess I'm kind of agreeing with you, haha. I still have a lot of backend work that needs to be done to actually finish the project, but doesn't need to be done for the prototype.
Anyways, again, thanks for all the comments. We'll see what this week brings! Hopefully, it brings me some knowledge on how to use the GUI editor.
Torque Owner Don Hogan