Blog for David Grace at GarageGames.com

Monday Jun 13 5:42

David Grace — 2005-06-13T05:42:31+00:00

GID #13 and post-mortem on my entry, De-Fusion

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:

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.

Wednesday Jun 8 6:26

David Grace — 2005-06-08T06:26:01+00:00

Yay! I'm back (sorta) and am still working with T2D. :)

I'm still alive! Now, how many .plans have I started like that...?

If you've been wondering about my extended absence, it's mainly due to two things. First, I'm buying a house. So I've been uber-busy trying to finalize everything, while staying over at my mother's temporarily until the place is ready. Sadly, it means no high-speed internet until sometime in July. Sob. I hate dialup; Worse, this USRobotics modem is glitchy and tends to crash after an hour or two of constant use.

The other reason? Well, still can't talk about that, but let's just say it's related to Torque and it's very, very cool. :)

I see that a lot has changed on here! Brand new, slick GG site, all new search system, and some new content packs too I see. Awesome stuff that I can't wait to check out/play with once I get everything situated with the new home. I know I've probably missed a lot in the forums and on IRC!

Well, after over two months (!) of being unable to work on my personal projects, I've managed to squeeze in some very productive time in the last two days.

First off, I've updated my code base to Torque 2D 1.0.2. This is Melv's latest patch to the T2D engine which fixes a number of things. I also merged in my own code mods. (Such as the ability to retrieve tile layer pan position, ability to set a mounted object rotation offset, and a new "control layer" flag for a tile layer -- More on that later.) One of the biggest changes I've made is to add a true scaled font object. T2D's font system is pretty versatile, but it does not handle auto-scaling fonts based on resolution. While this is normally fine, as you don't want to scale text used in HUDs, this just doesn't do for in-game text that you want to interact with the gameworld. (ie: Score or "1-Up" messages that float above enemies or icons.) There's a resource on GG that adds a fxTextObject2D control, but it uses Torque's built-in font system which, as I mentioned, doesn't auto-scale. After some code hacking, I changed it so that it uses a font texture which gets auto-scaled in relation to the T2D camera.

That was the last needed piece in order to make a nice, nifty new HUD that will look great at any resolution. I don't care if there are a few scaling artifacts -- It's just score and extra-life information.

Now, on to actual game changes; I ripped out the simple easy/hard difficulty and replaced it with a scaling system that uses heuristics to calculate the "onscreen difficulty." Basically, this is technology I developed for Adagio and just applied the same algorithms to Cloudburst. It's pretty simple, in that it computes difficulty based on the number of enemies and bullets onscreen, and adjusts for several other factors. (Player's power up level, how long they've been alive, etc.) You can set difficulty, and the game will attempt to keep the onscreen difficulty rating at that level, or lower. So, in other words, setting game difficulty gives the engine an upper-water mark to use for estimated difficulty. Enemies that don't pass the mark aren't spawned. I have to say, it works well. As an added bonus, it linearly scales the difficulty up the higher your survivability factor increases (via time-alive and powerups). I was rather impressed with how Gradius V utilizied this in order to slowly ramp up the action for a good player, while toning it down when you died so you weren't immediately swamped as you would be with a fixed difficulty.

I also modified the tile system somewhat, and added a new flag to always toggle OnTileScript() events whenever a tile scrolls onscreen. This lets me paint enemies on the control tile layer much like one would paint terrain or buildings; The game automatically spawns the appropriate enemy type. This is a lot better than having to ctrl-click on every tile and typing something into the script event line, as now as the tile appears it fires the event which reads the tile type at that location and spawns the appropriate thing. (Such as a powerup, enemy, or boss.) I also fixed a few problems with the tile and particle editor save dialogs; Annoying little issues about it not saving the filename I used for loading and so on.

Also a new major addition to the engine is a BulletML-style definition system (written entirely in TorqueScript) which gives me very granular control over how enemies generate bullets. If you are a shmup fan, then you probably have played at least one PC-based shmup that uses BulletML. (For example, rRootage or Torus Trooper.) Using this new system I have been able to create all kinds of wickedly complex bullets; Bullets that suddenly change behavior, bullets that spawn new bullets, or that fly in really complex patterns. I even managed to create the dreaded 90-degree laser which is my personal bane in a lot of shmups. (ie: The sort of lasers that fly straight, but when you pass them, make a sudden 90-degree turn in your direction. Worse, I can, if so desire, configure mine so they will continue to make 90-degree turns until they either fly off the screen, or kill you. Heehee.) So far, it's just a handful of behaviors that the bullet system implements, but they can be combined in almost limitless ways. There's even a recursion-limitor so that bullets won't spawn endless droves. (Configurable, in case I do want endless droves...)

I'm scrapping almost all of the existing enemies. I've been studying a lot of the more manic shmups (Cave and Treasure has been great for inspiration), and I'm going to modify the enemies of level one so that they are more dynamic and complex. Right now, they move in rather simple, uninteresting patterns that are easy to dodge. I am also changing the boss so that it has a few extra patterns that it will execute randomly, adding a bit of unpredictability to boss fights. Plus, adding a few mid-sized enemies that are "chunky." ie: Are made of multiple pieces that can be shot off.

Shmups might look complex, but in reality the great shmups are fairly simple. They have a small set of gameplay rules and stick to them consistantly. Some games focus on strategy (such as the R-Type games) while others rely more on high speed finger-twitching skills (such as most Cave shooters), while others do a good job at mixing the two (most Treasure games, such as Ikaruga). Cloudburst currently plays like neither right now, and my goal is give it a bit of a manic feel. It's not exactly normal to have a side-scroller be manic, but I've seen a Cave shmup do it so it's possible.

Next on the list? I really want to work my fxDeformableObject2D idea. I also want a fxQuadtrailLaser2D -- a simple series of quads that leaves a trail. I'm hoping I can enlist some aid to create a nice, new rock'n sound track. Something of a mix of metal and synth...

Anyway, just wanted to touch base with folks and let 'em know I haven't run away or entirely been idle. :)

Sunday Mar 13 9:13

David Grace — 2005-03-13T09:13:58+00:00

Against better judgement, I decided to join GID10...

UPDATE: Without further ado, here is Boulder Squish: Boulder Squish! (about 5 megs)

I'm not at all sure if the multiplayer works, as I added a bunch of stuff after my roomie went to bed, so I had nobody to test it with. :) It *should* work, but you know how it goes. The game now has rounds that last a certain amount of time, and after a set number of rounds, the game ends. Here's an updated screenshot:

I'm still pretty woogy after finishing Cloudburst, but I decided to give it the ole college try. Game In a Day is a lot of fun, and I was disappointed I missed the last few.

My entry is called Boulder Squisher. It's a real simple game; You start as either the Attacker or Defender. Defenders get a repulsing cannon that can knock boulders (or other players) away. The Attackers get an attraction gun that pulls boulders (or again, other players) together.

Now, lock those two types up in a small room and then give the game a time limit. (Where the Attacker will switch with one of the Defenders.)

It's kinda fun, I was playing with my roomie for a bit before he went to bed. Sadly, I didn't get any screenies then, so I had to snap some later.

Unfortunately, without someone local to test the game with, I really can't make much progress on tonight. Maybe I'll get some more done tomorrow.

Sunday Mar 6 11:44

David Grace — 2005-03-06T11:44:49+00:00

Torque 2D is great fun!

Seems I missed the initial release of Torque 2D on Friday. I didn't notice it was out until Monday. When I saw it, I knew I had to pick it up. I knew this even back when Melv was talking about a keeno 2D scenegraph he was adding to TGE in the forums... :)

Here are some screenies of my first (official) T2D project:

Cloudburst 1
Cloudburst 2
Cloudburst 3
Cloudburst 4
Cloudburst 5
Cloudburst 6
Cloudburst 7
Cloudburst 8
Cloudburst 9
Cloudburst 10
Cloudburst 11
Cloudburst 12

The robot boss's arms and legs are completely seperate from its body, and can be shot off. (For the amusement of the player -- You only need to take out his rocket jet backpack in order to kill him.) When you destroy his backpack, he goes through a little death animation that was influenced by the spider-robot death scene from Einhander. ;)

Here are some vidoes of it in action:

Cloudburst Preview (low quality MPG, 4.8M)

Cloudburst Preview (high quality MPG, 10.2M)

(Note, some people have reported the videos aren't playing properly in WMP. I'm not sure why, it's just an MPEG-1 stream, encoded using TMPGEnc. You can use VLC player or Quicktime if you have problems.)

Cloudburst is just a single level game that I don't plan on extending. It's both a demo of my own abilities, and a test for myself. Can I make a modern looking 2D game that has slick graphics with this new 2D game engine by GG? How quickly can I get a project like this up to speed, and how well does it work?

Judging from the response on here, and elsewhere, it looks like I passed the test. I am totally and utterly sold on T2D. :) Cloudburst has taken me about a week to get working. One of those days was spent chasing a slowdown issue that had a simple solution once I understood some currently-undocumented part of T2D and another was spent making that robot rat!

T2D has not only met my (fairly demanding) expectations, but it has exceeded them as well! T2D is the sort of 2D-over-3D-hardware engine I've been thinking about implementing myself. I'm glad Melv and Josh came along and did all the hard stuff for me. That's worth a bit of my cash. ;)

One thing about T2D -- I would say it's harder to get used to if you've already been doing 2D game programming using your own engines/libraries and haven't been accustomed to making games under 3D limitations. No, you can't just have a sprite of unlimited size or dimensions, and no you can't have a bazillion frames of animation, each frame its own independant size. However, with 3D hardware you get rotation, scaling and blending for just about absolutely free, so the benefits outweight the slight loss of freedom.

Also gone are the days of absolute, per-frame control over your sprites. T2D handles that for you. You just give it data to feed into its physics system and let it take it from there. Sure, you can write scripts that sets sprite positions absolutely, but a lot of the time it's easier to refactor your idea so it can be done with T2D's physics system. But, like above, you get a lot of stuff for free by using that system -- damping, rebound, friction and restitution.

So what have I been working on? Well, mostly HalfLight: Adagio. It's a very retro-styled shooter that features a pretty detailed story. I've recently ported it over to OSX and was glad to see it mentioned on a few well known Mac sites. It got so many downloads, it absolutely crushed my poor DSL-hosted website! ;)

Now that T2D is here, though, I've scrapped a few of my plans on making my next game using my own engine and will be using T2D.

"But David, what about Spacerace/Raven's Run/GRM?" Indefinitely on hold for now. I gave my hand at doing 3D with Torque. But I've found that making even a fairly simple 3D game is a lot of work for just one person. Plus, I've noticed that my abilities as an artist are better tuned for 2D work. I can do 3D, but it takes a certain mindset for doing low-poly work. Sure, SpaceRace only took me a week to make but it's a really simple game, filled with a lot of problems and graphically isn't that appealing. Worse, the modeler I love to use (Lightwave) isn't directly supported by GG and there's been some roadbumps on getting my creations into TGE. Anyway, I'm not that much of a coding whiz to be able to understand most of the intricacies of TGE/TSE or to fix any roadbumps I might encounter in the art path. :)

Besides, a lot of the games I like to play are still 2D. I've given thought to 3D-izing some of my ideas, but I've spent enough time with Torque to know this is a fairly monumental task. That third dimension really does add a lot of complexity, and I don't just mean in code/logic.

Some might say that's a pretty limited view of game making, or even a cop-out, but honestly I think it doesn't matter if your game is 2D, 3D, or ASCII graphics on a Commodore PET -- as long as it entertains and engrossed the player, it has accomplished its task. I don't necessarily mind making games that many might view as unnecessarily niche-market; If I wanted to make popular, big-industry style games, I'd be working on "Doom 4: The MMORTSFPSOMGWTFBBQ."

Let me tell you a story: A long time ago, I made a game in QuickBASIC for DOS on my old Commodore Colt computer. (Yes, they once made PCs. Shush, I'm telling a story.) I uploaded it to local BBSes and it had a moderately positive reaction among my friends. But I never really did that much with spreading the game. Once, when I was back on AOL (hey, it was the only decent-sized online service available in Meridian, Mississippi until around the mid-90s!), I uploaded it to their games section and completely forgot about it.

Six months or so later, I got a letter in the mail. It was from a lady who wanted to register the game (her check was enclosed) and who told me that the game's universe had impressed her. To the point that she even included a sketch she had drawn of the main character, Quiwkali.

My eyes nearly welled up reading that letter. I just hadn't made a video game, I had had told a story that touched someone far away. To me, that is what making games is about. It's not about polygons, or sprites, or sound effects -- It's about creating something that both entertains and surrounds you in a world of its own, where you can let yourself go and live in an alternate universe, dodging laser blasts as you rush to save the world. Even my stupid little 2D shooters have rich, detailed milieu with what I hope are engrossing stories and vivid characters.

I guess the point I am trying to make is that I am a storyteller who uses video games as his medium. And I'm thankful that GG has given me another tool I can use to bring my worlds alive.

Uh, heh. I didn't mean for this .plan to turn so maudlin. Now, back to game making! And you, Melv! Add 3D rotating isometric hexmap sprites to T2D! I demand it! *whip crack*

Saturday Nov 27 7:58

David Grace — 2004-11-27T07:58:56+00:00

Torque Torque Revolution!

Yeah. I know, I've been quiet lately! Ever since my return from IGC, in fact. Whew, let me say -- I was very impressed with IGC! It was the perfect blend of business, friendship and coolness.

What hit me the most was GarageGames' modesty. I liked how Jay was concerned that they were pimping out too much this year... I actually went to IGC expecting a lot of GG-centric content but I am glad to see that IGC is aware of how much they do so. Not wanting to turn IGC into a GG-only sort of event. Considering that they are the ones who are funding and promoting it, and have ever right to make as much a media circus as they want, that's real cool in my book that they choose not to. :)

I got to meet lots of the GG crew, plus tons of regulars on here. That to me, was the coolest part of the whole thing.

I will certainly be back again next year! A very memorial experience... That impromptu jam session was the best thing I've seen a con/event ever!

Unfortunately, the one Torque game I had to show was crashing due to a bug in the GUI. Ooops. Did manage to fix it, but not without a lot of annoying debugging. I wrote several pages of analysis, too. It was invaluable seeing total strangers play my game. (Taught me that the game needed a lot of work, for one. ;)

Now, what have I been up to since then? Well, a few things! I'm nearly done with my 2D shooter, Adagio. Just a few more polishing touches and I'll be releasing it.

As for the other stuff, I want to keep it a secret. But I will demonstrate one thing I just got working:

Yeah, that's me playing a Torque-based game using a dance pad! (It's from the game called "Pump It Up" made by Andamiro. Think of it as a Korean knock-off of Dance Dance Revolution.) I've got a new input class in Torque that will read the pad via the USB port and output keyboard events to TGE. It works pretty good, though I had to thread it to prevent it from blocking the main Torque sim loop.

I'm keeping what it's for under wraps for now though. Mainly because I'm not sure if it's going to work! :)

Monday Sep 20 16:48

David Grace — 2004-09-20T16:48:05+00:00

Nuts and bolts and custom classes, all in preperation of IGC04

I've decided to concentrate on re-working Space Race for IGC04, instead of GRM. The yet-unnamed game will expand upon the original and include many more dangers, plus what I hope will be exciting boss fights. It's shaping up to be less of a racing game and more like a mix between rally racing and a shooter. I've decided to forego multiplayer so I can concentrate on fine-tuning the gameplay.

Most of my time has been devoted to getting moving platforms working. Sadly, I still haven't been able to come up with anything that satisfies me; I tried to build my own object class, a ShapeBase that contained camera pathing code. It worked fine, as far as moving around is concerned, but I couldn't get collision detection to work right. (My ship could shoot/ram the platforms fine, but if the platform rammed my ship, nothing would happen.)

Someone from IRC showed me how to lobotomize the FlyingVehicle class and make it a "hockey puck" as he put it. (Basically a moveable object that will trigger collisions correctly.) I then glued in pathing code, but this didn't work out as I expected; Due to the class being controlled by rigid physics, you can't just set its transform matrix and go, you have to work with relative positions. I ended up getting the aiming and pathing code to work, but I will use this for my chaser/patrol ships, instead of moving platforms. In that respect, the code is fairly robust and it will follow a path correctly in 3D space, including height changes. (In fact, I've pretty much duplicated the AIFlyingVehicle mod that is floating around on the forums. Too bad I didn't discover this until after I was 90% done with my own implementation, heh.)

I've finished the pathed starship class, so I can take a ship, populate it with turrets and have it patrol a section of my mission. I'm now working on the chaser ship type, which uses the same modified flying vehicle, except it sets waypoints in realtime to fly towards the player.

One problem I am having is that when my AI-controlled flying vehicles collide with any DIF shapes, the game locks up. The problem seems to happen less if I set the integration higher, but it doesn't entirely go away. Besides, that slows down the game. (As I will have at least a dozen or more of these shapes in a single mission.)

No screenshots as of yet, I forgot to snap a few. :)

Tuesday Sep 7 2:09

David Grace — 2004-09-07T02:09:11+00:00

Space Race is finished!

Whee, my first Torque game! And only written in a week, too. It came out pretty good, even if a lot of features were cut. I planned on having powerups, chaser ships (that tried to shoot you down), and pathed static shapes (for moving stuff to dodge). Oh, and of course multiplayer.

This game was for a charity auction and therefore, won't be available for purchase or download seperately. It went for $30, which I suppose isn't bad since it was a rushed 15-second bid with the starting price of $5. There was a lot of items in the auction, and unfortunately a lot of the later items got 15 or 30 second bids as time ran out. However, they did raise over $14,000 for Tiger Haven.

If you want to check out the rest of the screenies, here they are: gapingwolf.com/spacerace/screens/

While the game was only for the auction, I plan on filling in the missing features, redoing the artwork and releasing it as a complete game. What do you think? I'm pretty pumped about this; It's proven to me, without a doubt, that Torque is a solid foundation for any sort of game and that I can very easily do RAD/prototyping.

Monday Aug 30 16:56

David Grace — 2004-08-30T16:56:44+00:00

Space Race: It needs a better name...

For some reason, I just don't know when to quit. I've got one major project already on my plate, that being Adagio. Once that is complete (and it nearly is), I planned to move on to working on Giant Robot Monster. But then (www.gameinaday.com) GID5 came up and I started work on a small puzzle/action game called Fort Blox. Think I've got enough projects going on and that I'd have learned my lesson when it comes to starting new ones? Wrong!

May I proudly introduce, the yet-finalized-name of Space Race!

This game is actually for charity. I'm donating it to an auction for TigerHaven, which in case you don't know is like a halfway house for abandoned wild mammals. (Like tigers, lions, wolves, etc. Animals that people think is 'cool' or 'cute' to own when they are pups, but once they grow up they abandon.) The bad thing? The auction is this Saturday! Doh!

This game is very simple. It's "out of the box" Torque as much as possible. For example, my spaceship is just a flying vehicle inside a giant physical zone with gravity mod set to zero. (With a few tweaks to the FV code to make it behave a bit more logically for freeflight.)

You have a time limit and you must fly through a bunch of rings and other structures in order to complete the mission. Along the way, turrets, spaceships, and asteroids will provide resistance. Powerups can be collected by destroying various enemies. They range from time bonuses to extra weapons and health recharges.

Yes, the models are currently untextured. And that ring looks real crappy. :) I haven't started work on the art resources as of yet, other than just to slap some stuff together in Lightwave real quick. I'm almost done with the basic gameplay, once that is finished I will start refining the artwork.

I'm hoping to at least have all of the singleplayer stuff ready by this Saturday. I will be only releasing this game to the auction, though I plan on redoing the game (plus add multiplayer play) and making a public release.

Paul's turrets work very nicely. :) There's a few problems with them, however, such as their triggers tend to eat up events scheduled for other triggers, but some quick lobotomy to his code fixed that. (The only minus is that now turrets do not properly deactivate, but I can live with this for now until I can trace it down.)

Monday Aug 16 16:40

David Grace — 2004-08-16T16:40:51+00:00

My first GID event and entry, Fort Blox. Too bad I slept through most of it. :)

This weekend was a lot of fun! This was my first try at GID, and while I didn't actually complete a playable game, I managed to whip up not one but two ideas for small, easy-to-make games. In fact, I am tempted to postpone Giant Robot Monster so I might work on these two games -- Though I really should stick to my original plan. :)

My game plan was already decided. Instead of doing yet another shooter, with yet more generic spaceships, I decided to aim a bit different this time. No, I wanted to make a fun little action/puzzle game that featured cute, cartoony characters and subdued psychodelic visuals. There wouldn't a deep plot to this game (another deviation for me) and it would be something you could sit down, pick up and play without a tutorial.

The only initial defining factor I had was that it had something to do with blocks. Shortly after that, I came up with the name "Fort Blox." Partially as a pun, and partially as a description of the game; You will be this little fox, who's built himself a multi-level fort. Maybe to reach the grapes? :) Anyway, these mean, nasty wolves want to tear down his fort, and have brought their ladders. They stack them against the edges of your fort and climb aboard, seeking out the building blocks used to make your fort and tossing them over the edge. Once all of the blocks have been removed, one level of your fort falls down, and you quickly scamper up to the next one...

So, after telling this to my artist friend, Ryan Hudson, he whipped up this sketch of the main character from Fort Blox:

Keen! Just the style I was wanting! So, I set him down and showed him how to use ProMotion's animation system and got him on his way. Next, I started to code.

Now, here is where I made my second mistake. I decided to reuse my Hrafn engine, which I was using to make a game called Crusade. (Some might recall the pictures in my first .plans about a 3D space shooter.) It had almost all that I needed to finish a game, except for sound (not necessary at this stage) and a built-in sprite system. But the hooks were already there (since the engine had been pure 2D until converted to 3D), shouldn't be that hard to add 2D sprites, right?

Wrong! I blew a good six hours alone on the task of getting sprites to work properly. First of all, I had to load sprites from ProMotion's custom .SPR file format. That was easy, but actually converting the paletted textures to something that DirectX could natively store on the video card turned out to be a bit of a trouble. I was thinking about this, the night before, and asked the folks on GD.net what they thought; Someone pointed me to a DX helper function that will convert any format file into the proper texture format. Not very good, but appearently it also has an alterate version that works on images stored in RAM. Keen! So, I did a little dirty hack of converting my 8-bit textures into 8-bit memory-mapped targas and fed them to this routine. It works! After a little bit more of getting sorting issues worked out properly, my hybrid 2D/3D was ready to go.

So, I added the player, blocks, and then proceeded to work on the enemies.

I didn't get anything much more done than that. Around 9pm on Saturday, I signed off the #gameinaday channel, telling everybody I would be back later. I then laid down on the couch and watched some TV, and more or less dozed off. I slept most of Sunday, too. :) While I technically still had almost twelve hours left on my GID5 entry, I just couldn't make it. I blame work for making me pull a 60-hour week beforehand. :(

Anyway, if you want to try out the last build of my game, here it is:

FORT BLOX alpha version 0.00 build

(If you want to see in-progress screenshots, I have some saved right here!)

Be warned, it contains absolutely no error checking, so if DirectX 9 can't initialize something, it will crash big-time. :)

PS: My first mistake, you ask? Well, that was simply biting off more than I could chew. Fort Blox is a fairly simple game, but I was still in "future compatibility" mode when writing it. Therefore, I didn't take nowhere near as many shortcuts as I should have. Also, my artist had to work both on Friday and Saturday, so he wasn't able to provide me with much more than the main character sprite.)

Update: Since Nic didn't like my "novel" as he called it ;), I managed to get rid of some redundant files so the archive is only 2 megs instead of 4! Hee, that's what I get for putting on my release engineer hat when very, very tired.

Friday Aug 6 16:45

David Grace — 2004-08-06T16:45:02+00:00

I call shotgun!

Well, Adagio is just about finished. I received the next few tunes from the musician and I am tickled with how they came out. The artwork for level two and level four is done, and level three is nearly done. I'm starting on the last two levels that remain to be done; Five and six. For those who are in the beta: I'll be posting something to the beta website here this weekend.

I also fired up Lightwave and played around with making some weapons for Torque. I really don't need these, as my current Torque game doesn't use normal projectile weapons, but it's good practice: Both for modeling and for figuring out how the projectile/weapon classes work.

The first one I've done is a grungy, futuristic shotgun. Here's a picture of it:

(Sorry for the lack of detail, didn't realize the JPG's gamma was borked.)

I've already imported it into Torque and have written some scripts to support it, based upon the rifle.cs file. Being that this is a shotgun, and there's no specific projectile class to handle this in Torque, I've modified it so it fires out 10 individual projectiles when you press fire, and they spread out realistically. I haven't tested this in multiplayer, but currently it looks pretty good and works well. I can kill Kork with one shot if he's close enough. :)

Right now, I'm working on tweaking the particle effects. I want to finish everything but the sound effects.

After that, I plan on releasing this as a resource that you can just drop into your project and go.

UPDATE: Well, I finished the shotgun. It's a full set, too; Model, ammo, sound effects, and .cs files to drive it all. Here's what Orc looks like, packing a shotgun: