Plan for FenrirWolf
by Fenrir Wolf · 06/12/2005 (10:42 pm) · 5 comments
Game In A Day? Huh?
It was somewhat sudden, but I decided to enter Game In A Day #13. For those who are just now tuning in, Game In A Day ("GID" as it is known) is a fun "contest" where participants attempt to create a fully playable game in just a mere 24 hours. I say "contest" because there are no prizes, no judges, and cheaters only cheat themselves. Therefore, as you can imagine, it's a nice relaxed affair where newbies or pros alike can chip in and crank out some fun and creative little games. Sometimes you don't always finish a game. My first GID was that way; I took too long working on the underlying engine. Other times, you can bite off more than you chew, concept-wise. Don't worry if you are unsure about your ideas; Participating in a few GIDs will teach you rather quickly what is doable in just a day or so.
GID has more uses than just teaching you how to put together a product in an accelerated, shoestring-budget environment; It also acts as a fertile ground for rapid prototyping. The faster you can play your game, the sooner you know if it's a hit or miss.
For more details, you can check out the main website at www.gameinaday.com.
(If you only want to download the game I made and don't care to read my progress report, here's a link:
Download De-Fusion v1.00 Installer (1.8 megs)
Sorry, PC only for now -- I'll do an OSX port once I get moved into the new place and unpacked my Mac Mini.)
My GID #13 Entry: De-Fusion

It's called De-Fusion and it's a kinda-sorta remake of a Commodore PET game that was later converted to GWBASIC back in the early 80's. My sister and I used to have loads of fun competeting against one another in this game on my 8088 clone, and I felt it deserved a remake. Here's the story straight from the game help file itself:
It's the 21st Century and limitless power is nearly here!
Recently, two fusion research groups have been competing against one another for the breakthrough that is free, cheap, universal power. Of course, both of you are neck and neck when it comes to your respective breakthrough -- So what do you do? Sabotage each other, of course!
You've managed to break into the other group's computer. Their main fusion reactor is purring along, awaiting its inspection by the World Energy Atomic Power Network. You can't let that happen! So your plan is to alter the injector program to start feeding heavier elements into their fusion pile; This will cause their reactor to eventually overload and burn out. It'll be months before they can repair it, and in the meanwhile, you will publish your findings, give the demo and reap an endless supply of government power contracts. Not to mention a nice, fat Nobel science prize.
Muhahaha! But...wait! Looks like the other group has the same idea! No time to pull the plug, that'll ruin months of research! So, it's a race to bring the other reactor down, and win humanity's everylasting gratitude for fulfilling its voracious appetite for power!
Yay! So I managed to work in the theme for this GID, which was fusion. Probably a first for me, as I tend to just do my own crazy thing. :) Anyway, here's a description of how to play:
The objective is to reduce the other group's fusion reactor stability to zero by selecting heavier elements. (Higher numbered tiles.)
You start out with a game board that is arranged in a 8x8 grid. At each intersection, there is an element, ranging from hydrogen and on up. A number is associated with each element; This is its location on the perioidic table, which roughly corresponds to how heavy each element is. In order to sabotage the other group, you must use the arrow keys to move the cursor and select the heaviest element possible, and then press enter.
This will send a command to their remote fuel injector, and that selected element will be fed into their reactor. You will notice that the stability meter for the other group goes down accordingly. The heavier the element, the more the meter goes down.
Once stability has been lost, a winner is declared. Be warned, the other group will be trying to do the same thing to you!
If you disable the AI player, two humans can compete in hot-seat style play.
Complicated story for a fairly basic game. :)
How I put it together
I decided to use GarageGame's awesome 2D game engine, Torque 2D. Over the last few months, I've really grown to love Melv and Josh's baby. As I become more familiar with TAP (that's Torque Application Platform, the underlying core that binds GarageGame's Torque engines), I am able to whip out code in just a fraction of the time it would take for me to get even a simple new 2D engine working.
Since De-Fusion was going to be a puzzle-style board game, I didn't need much in terms of artwork and code. So it only took me a short while before I had a game screen up on my monitor. The board is a single fxSceneObject2D that has a bunch of fxStaticSprite2Ds mounted to it in a grid pattern, as such:
I decided to go this route instead of using a true fxTilemap2D for simplicity, as I didn't need costume boards. It was just a bit easier to use a global $tile array to access the individual sprites. This would also let me do cool effects such as have the board fly apart or re-assemble rather easily, as the pieces would be seperate sprites. (Which I didn't get a chance to implement!)
Here's my first screenshot after about an hour or so:

Most of that time was spent drawing the little tiles in Photoshop, which amounted to a lot of cut and pasting of numbers and letters. :) The most important aspect of doing a GID is keeping everything within your immediately ability, so I picked a simple game that didn't have much of an art requirement. (It really does help if you can hunt down an artist friend and get them to assist, or use pre-made art resources. Heck, just pop into the #gameinaday channel on IRC and ask around, maybe somebody will be free and willing to assist.)
Now that I had the board rendering, I started work on the interface. Agzain, I was keeping this as simple as possible. The player would use the arrow keys to move a cursor, and enter to select a tile. Once I had the selector working, I added in a move validator (so the player couldn't select already-useed tiles) and then started game flow logic. Each tile had a point value associated with it -- selecting it caused the other player's score (his/her "reactor stability") to decrease by a set amount. After that, it was just a matter of adding in hooks for detecting end-of-game situations, of which there was just two. You can either run out of valid moves or one player's HP can go below zero. In the case of no-more-moves, just compute who has the higher score and you're done. I also added a hook for the rare (but not impossible) chance for a tie.
Here's how the interface was looking by then: (The little bulb indicates whose turn it is.)

Okay, that wasn't too bad. What was left? Well, a computer player for one. This particular part ate up most of my remaining time right there; It took me a few hours alone to get this working. (About half of that was spent chasing a really stupid mistake in my code, heh.) The algorithm is simple, in that it searches ahead a few moves to see what would net it the highest score and give the player the lowest at the same time. Though it still needs tweaking, as it can be fooled fairly easily. I had hoped to have a difficulty rating, but it took so long getting the AI to merely work that I decided I'd better finish the game instead.
Once the AI was done and the game was playable until conclusion (for either AI or two-player), it was just a matter of finishing the game-over screen and menu. Running out of time, I had to skimp and make a universal game-over screen when I would have preferred to have seperate ones; For example, one when the player wins and one for when he/she loses. I also wanted to draw some custom art for the scientists to further enchance the goofy 1950's flair to the game. All that left was to create an opening menu so that the players could configure their options:

I barely had enough time to do basic testing of the game before I slapped it into a self-extracting archive and uploaded it to my server. Later my sister played it and demonstrated that the game was indeed playable, even if a little rough at the edges. (For example, in the case of a no-more-valid-moves situation, the win/lose screen pops up too fast. There should be some sort of delay to let the player register why they won/lost.)
All in all, I wanted De-Fusion to appear as polished as I could make it within a mere day's worth of time. I think it came out decent and I will likely go ahead and finish the game and release it.
It was somewhat sudden, but I decided to enter Game In A Day #13. For those who are just now tuning in, Game In A Day ("GID" as it is known) is a fun "contest" where participants attempt to create a fully playable game in just a mere 24 hours. I say "contest" because there are no prizes, no judges, and cheaters only cheat themselves. Therefore, as you can imagine, it's a nice relaxed affair where newbies or pros alike can chip in and crank out some fun and creative little games. Sometimes you don't always finish a game. My first GID was that way; I took too long working on the underlying engine. Other times, you can bite off more than you chew, concept-wise. Don't worry if you are unsure about your ideas; Participating in a few GIDs will teach you rather quickly what is doable in just a day or so.
GID has more uses than just teaching you how to put together a product in an accelerated, shoestring-budget environment; It also acts as a fertile ground for rapid prototyping. The faster you can play your game, the sooner you know if it's a hit or miss.
For more details, you can check out the main website at www.gameinaday.com.
(If you only want to download the game I made and don't care to read my progress report, here's a link:
Download De-Fusion v1.00 Installer (1.8 megs)
Sorry, PC only for now -- I'll do an OSX port once I get moved into the new place and unpacked my Mac Mini.)
My GID #13 Entry: De-Fusion

It's called De-Fusion and it's a kinda-sorta remake of a Commodore PET game that was later converted to GWBASIC back in the early 80's. My sister and I used to have loads of fun competeting against one another in this game on my 8088 clone, and I felt it deserved a remake. Here's the story straight from the game help file itself:
It's the 21st Century and limitless power is nearly here!
Recently, two fusion research groups have been competing against one another for the breakthrough that is free, cheap, universal power. Of course, both of you are neck and neck when it comes to your respective breakthrough -- So what do you do? Sabotage each other, of course!
You've managed to break into the other group's computer. Their main fusion reactor is purring along, awaiting its inspection by the World Energy Atomic Power Network. You can't let that happen! So your plan is to alter the injector program to start feeding heavier elements into their fusion pile; This will cause their reactor to eventually overload and burn out. It'll be months before they can repair it, and in the meanwhile, you will publish your findings, give the demo and reap an endless supply of government power contracts. Not to mention a nice, fat Nobel science prize.
Muhahaha! But...wait! Looks like the other group has the same idea! No time to pull the plug, that'll ruin months of research! So, it's a race to bring the other reactor down, and win humanity's everylasting gratitude for fulfilling its voracious appetite for power!
Yay! So I managed to work in the theme for this GID, which was fusion. Probably a first for me, as I tend to just do my own crazy thing. :) Anyway, here's a description of how to play:
The objective is to reduce the other group's fusion reactor stability to zero by selecting heavier elements. (Higher numbered tiles.)
You start out with a game board that is arranged in a 8x8 grid. At each intersection, there is an element, ranging from hydrogen and on up. A number is associated with each element; This is its location on the perioidic table, which roughly corresponds to how heavy each element is. In order to sabotage the other group, you must use the arrow keys to move the cursor and select the heaviest element possible, and then press enter.
This will send a command to their remote fuel injector, and that selected element will be fed into their reactor. You will notice that the stability meter for the other group goes down accordingly. The heavier the element, the more the meter goes down.
Once stability has been lost, a winner is declared. Be warned, the other group will be trying to do the same thing to you!
If you disable the AI player, two humans can compete in hot-seat style play.
Complicated story for a fairly basic game. :)
How I put it together
I decided to use GarageGame's awesome 2D game engine, Torque 2D. Over the last few months, I've really grown to love Melv and Josh's baby. As I become more familiar with TAP (that's Torque Application Platform, the underlying core that binds GarageGame's Torque engines), I am able to whip out code in just a fraction of the time it would take for me to get even a simple new 2D engine working.
Since De-Fusion was going to be a puzzle-style board game, I didn't need much in terms of artwork and code. So it only took me a short while before I had a game screen up on my monitor. The board is a single fxSceneObject2D that has a bunch of fxStaticSprite2Ds mounted to it in a grid pattern, as such:
for (%a = 0; %a < $BoardX; %a++)
for (%b = 0; %b < $BoardY; %b++) {
$tile[%a,%b] = new fxStaticSprite2D() { scenegraph = dfSceneGraph2D; };
$tile[%a,%b].setsize ("40 40") ;
$tile[%a,%b].setlayer (9) ;
$tile[%a,%b].setimagemap (imgTiles) ;
$tile[%a,%b].mount (board.getid(), (%a - 5) * 0.25 SPC (%b - 5) * 0.25, 0, true, true, true, false) ;
} I decided to go this route instead of using a true fxTilemap2D for simplicity, as I didn't need costume boards. It was just a bit easier to use a global $tile array to access the individual sprites. This would also let me do cool effects such as have the board fly apart or re-assemble rather easily, as the pieces would be seperate sprites. (Which I didn't get a chance to implement!)
Here's my first screenshot after about an hour or so:

Most of that time was spent drawing the little tiles in Photoshop, which amounted to a lot of cut and pasting of numbers and letters. :) The most important aspect of doing a GID is keeping everything within your immediately ability, so I picked a simple game that didn't have much of an art requirement. (It really does help if you can hunt down an artist friend and get them to assist, or use pre-made art resources. Heck, just pop into the #gameinaday channel on IRC and ask around, maybe somebody will be free and willing to assist.)
Now that I had the board rendering, I started work on the interface. Agzain, I was keeping this as simple as possible. The player would use the arrow keys to move a cursor, and enter to select a tile. Once I had the selector working, I added in a move validator (so the player couldn't select already-useed tiles) and then started game flow logic. Each tile had a point value associated with it -- selecting it caused the other player's score (his/her "reactor stability") to decrease by a set amount. After that, it was just a matter of adding in hooks for detecting end-of-game situations, of which there was just two. You can either run out of valid moves or one player's HP can go below zero. In the case of no-more-moves, just compute who has the higher score and you're done. I also added a hook for the rare (but not impossible) chance for a tie.
Here's how the interface was looking by then: (The little bulb indicates whose turn it is.)

Okay, that wasn't too bad. What was left? Well, a computer player for one. This particular part ate up most of my remaining time right there; It took me a few hours alone to get this working. (About half of that was spent chasing a really stupid mistake in my code, heh.) The algorithm is simple, in that it searches ahead a few moves to see what would net it the highest score and give the player the lowest at the same time. Though it still needs tweaking, as it can be fooled fairly easily. I had hoped to have a difficulty rating, but it took so long getting the AI to merely work that I decided I'd better finish the game instead.
Once the AI was done and the game was playable until conclusion (for either AI or two-player), it was just a matter of finishing the game-over screen and menu. Running out of time, I had to skimp and make a universal game-over screen when I would have preferred to have seperate ones; For example, one when the player wins and one for when he/she loses. I also wanted to draw some custom art for the scientists to further enchance the goofy 1950's flair to the game. All that left was to create an opening menu so that the players could configure their options:

I barely had enough time to do basic testing of the game before I slapped it into a self-extracting archive and uploaded it to my server. Later my sister played it and demonstrated that the game was indeed playable, even if a little rough at the edges. (For example, in the case of a no-more-valid-moves situation, the win/lose screen pops up too fast. There should be some sort of delay to let the player register why they won/lost.)
All in all, I wanted De-Fusion to appear as polished as I could make it within a mere day's worth of time. I think it came out decent and I will likely go ahead and finish the game and release it.
About the author
Recent Blogs
• Plan for FenrirWolf• Plan for FenrirWolf
• Plan for FenrirWolf
• Plan for FenrirWolf
• Plan for FenrirWolf
#3
My one complaint... no linux version for me to have a play with :)
06/13/2005 (3:31 am)
For a GID it looks like a very complete game, even the graphics look polished. Something you should be proud of :) My one complaint... no linux version for me to have a play with :)
#5
@Melv: Hey, I take that as a great compliment coming from the guy who wrote all of that nifty-keen code. ;) Trust me, T2D has served me well and will continue to do so for a long time.
@Gary: Heehee, I don't have a Linux system to actually develop on. (Well, one that isn't running headless as a server, that is.) Maybe once I get moved and setup I can get something setup, as room has sofar been tight when it comes to have all these dev systems sitting around, heh.
My goal was indeed to make the game look as polished as I could in just a mere 24hr-ish hours... Think I hit the mark!
06/13/2005 (11:09 pm)
Thanks for the comments, everybody!@Melv: Hey, I take that as a great compliment coming from the guy who wrote all of that nifty-keen code. ;) Trust me, T2D has served me well and will continue to do so for a long time.
@Gary: Heehee, I don't have a Linux system to actually develop on. (Well, one that isn't running headless as a server, that is.) Maybe once I get moved and setup I can get something setup, as room has sofar been tight when it comes to have all these dev systems sitting around, heh.
My goal was indeed to make the game look as polished as I could in just a mere 24hr-ish hours... Think I hit the mark!

Associate Melv May
Great read. I really like the detail you've included here. To your credit, it's hard to believe that this is a GID, great job.
Looks like you're really getting to grips with T2D. May it serve you well. :)
- Melv.