A Game In 45 Days

Spaceballs - Day 22 - Meet My Friend Mister Reaper

Jason Olson — Fri, 09 Jun 2006 00:41:00 GMT

I know I was shooting to get the lives system implemented last night, but I wasn't able to do so because I needed to fill out a bunch of paperwork and do some general catch up on some other tasks (non game-development related, that is). So tonight was my first opportunity to work on Spaceballs since Tuesday night.

I'm proud to say that not only did I get done what I was shooting for (multiple lives for the player as well as the "Get Ready, Set, Go!" countdown at the beginning), I also got done a lot more. I love the feeling of being very productive because the architecture and framework just enables you to be productive :). With the way I had implemented my state management (combined with existence of my new Task Manager), I was able to finish the GameOverState as well as add a death animation for when the player dies. I also added a bunch of prompts throughout play and stuff. What a great feeling!

Now with lives, respawning, death, death animation, game over, etc. all implemented, the functionality and flow of the gameplay is _literally_ feature complete now (must haves + nice to haves). Now I can move on to adding the new enemies, power ups, and such (read: all the fun stuff). I find myself getting more and more confident with each coding session (of getting something fun and complete done by the deadline, not of winning (especially with all the other fun games being done)).

I do have some cleanup left to do after tonight's coding session. This just involves creating a quick UI component that can be re-shared between the various GameStates I have for the Scoreboard area (Score + Lives + Prompt/Possible Message To User). That should take almost no time at all. Perhaps after that I will do a release of the binaries and source for all of you to download (maybe tomorrow night?). Regardless, sharing code and binaries is very easy for me since I have a script that automates the cleanup of the source code, generation of release notes, and creation of the zip files for me.

Once I'm able to do that, I'm hoping that starting tomorrow night and ending sometime Saturday, I can create and finish a HomingSpaceball (charges after the ship wherever you go) and a WanderingSpaceball (moves in random directions). If I'm able to get those done, I would like to extend the HomingSpaceball to break up into four smaller spaceballs when it is destroyed. That should add some more fun to the game.

Now, in the miraculous case that I'm able to get all that done this weekend, I will move on to adding a new weapon (which will require me to finally create a new Weapon class and change my firing mechanism around a bit (once again, shouldn't take that long)) that you will automatically upgrade to at 10k points. When that is finished, the next step will be adding bombs to the player's arsenal that will destroy all spaceballs that are in play when it is dropped. Holy cow, if I could get all that done (even by next Tuesday or Wednesday), I would _REALLY_ be cooking along toward my goal. Perhaps then I could start doing some play testing.

Until next time, that's how the cookie crumbles :).

Spaceballs - Day 20 - Screens, States, and Transitions, Oh My!

Jason Olson — Wed, 07 Jun 2006 00:36:00 GMT

I didn't quite get around to implementing the lives functionality tonight. However, I did do some general cleanup and "paved the road" for me to easily drop in the code for respawning and multiple lives tomorrow.

One of the refactorings I did was to take what I was calling "States" before and change them to "Screens". Really, they were screens. As I needed to start adding states to the gameplay itself (like PlayingState, LostLifeState, etc.), I didn't want to go down the road of making a hierarchical state manager because I felt it would muddle up what was really being done under the hood. I felt that separating out Screens from States would lead to a much more clean implementation.

Rather than states being things like MenuState, PlayState, RecapState, and HighScoreState, those are now MenuScreen, PlayScreen, RecapScreen, and HighScoreScreen. In my mind, that makes it much more clear what they are actually doing. States are now concepts like ReadyToPlayState, PlayingState, LostLifeState, PowerUpState, GameOverState, etc. Once again, I am happy about this change as I am really liking the separation between "Screens" and "States" rather than hacking both concepts into one. The code is not only cleaner, but it will also be much more clear where the functionality I'm about to implement goes. For instance, the multiple lives functionality will simply be transitions from PlayingState to LostLifeState and back to PlayingState. If I add the "countdown" at the beginning of the game (think "Starting in 3... 2... 1.... GO!"), it will simply be starting with ReadyToPlayState and transitioning to PlayingState when appropriate. This will also help break out the code into more manageable chunks as well (which I always like).

On an aside, I think I use Source Control much more than I originally thought. It's only day 20, and I'm already up to revision 61 in SVN (61 commits). Better safe than sorry, I suppose :).

I still don't have any comments to make on Visual C# Express. I still haven't really noticed the difference all that much for my hobbyist development. Anyone out there that wants to get into C# development should _totally_ download Visual C# Express and use that. Besides, you can't beat the price of FREE :). The one thing that I can say is that, in my opinion, the Express products are better than the other free IDEs that are out there today. Usually, you get what you pay for (meaning free can suck tremendously), but not with the Express editions.

That's it for this update. For tomorrow night, I'm going to shoot for implementing multiple lives (a.k.a. LostLifeState) and hopefully get around to implementing the ReadyToPlayState as well to add the countdown to play time. Those shouldn't take too long (hence the reason I'm hoping I can get both of them done tomorrow night). Until then, I'll see you on the flip side :).

Spaceballs - Day 19 - Bug Squashing

Jason Olson — Mon, 05 Jun 2006 23:32:00 GMT

Not much functionality change tonight. Nope, tonight was mostly bug squashing night.

The first bug I squashed was around spawn point generation. Sometimes, a spawn point would be generated that would cause a Spaceball to be spawned within a wall. This was due to the spawn point generation algorithm not taking into account the size of the entity is was generating a spawn point for. That was an easy fix :).

The next bug I squashed was around the ball-reflection logic I had to bounce Spaceballs off of the walls when they hit. Unfortunately, it didn't take into account whether the code had already flipped the velocity vector based on a prior collision with the wall (i.e. a collision from the frame before (meaning, it is _still_ stuck in the same wall since not enough time has passed to clear the wall)). This was causing Spaceballs to become "caught" in a wall or to pass right through it. This was also an easy fix. I basically added logic to not only check for the collision, but to also check whether the Spaceball was still headed in the "wrong" direction before correcting its velocity.

The last thing I implemented was more around missing code. When implementing the game loop originally, I had forgot to add the ability for a game to be "paused". This meant that if the form lost focus (like navigating away to a different window), that the game would still run in the background. Oops :). That was also an easy fix, so it behaves properly.

Fixing the game pausing functionality exposed another bug, though (don't you love when that happens?). My EnemyEmitter class that was spawning new enemies on a frequent basis was checking a DateTime field from the last time it spawned to DateTime.Now to verify whether it needed to spawn a new enemy. This meant that the second a new enemy was spawned, I could make the window lose focus, wait several seconds, give the window focus again and a new enemy was spawned right away. Bad Jason! I should know not to check against *real world* elapsed time. I changed the code to record how much time had elapsed *in game* since the last spawn (by adding up the elapsed time through each "Update" call to the Emitter) and Poof! Bug fixed :). Once again, easy fix.

That's about it for tonight. Hopefully tomorrow night I can implement the lives system (i.e. giving you three lives rather than the game being over the first time you get hit). I was really hoping to do that tonight, but I guess it just wasn't in the cards :). Once I do that (which will include some refactoring to add "spawning" of ships themselves and fixing an annoying spawning issue I currently have), I will truly move on to implementing some of the various other Spaceballs I have in mind. Then the true fun begins (not that it hasn't been fun up to this point :)).

Spaceballs - Day 18 - Upgrade from GDI+ to Managed DirectX

Jason Olson — Sun, 04 Jun 2006 12:09:00 GMT

Well, I was able to squeeze in _some_ coding time last night and this morning. The update to Managed DirectX is all finished. It's kind of nice to see FPS should up from 90 fps to around 550 :).

All in all, it took about three hours to upgrade from GDI+ to Managed DirectX. Boy am I glad that I wrote the infrastructure the way I did. After a quick refactoring (making it so the IGraphicsService implementation rendered the Sprite rather than the Sprite itself), all I had to do was implement a new Direct3dGraphicsService and change the ServiceLocator to use an instance of that instead of the GdiGraphicsService it was using before. Viola! I'm now in Managed DirectX land. I love when to make a change like that, all you have to do is add another class rather than comprehensively changing your existing code.

Unfortunately, I'm still at the hotel in Seattle so I can't commit my changes to my Subversion repository yet (boy does that feel weird; I guess I'm used to committing often when I make small functional changes).

Now I believe I'm in a position to sustain for the long haul (as in, the system can grow to handle a particle engine and the like rather than having to find clever ways around the fact that GDI+ is not hardware accelerated).

So, what are the next steps?

1) Resolve a bug around Spaceball creation (sometimes the Spaceballs are created in the walls). This should be easy as it is simply limited the spawn area by the dimensions of the Spaceball being created.

2) Add "lives" to game. You will start out with three lives and the game will be over when you have no lives yet (currently, you only really have one life). I will probably re-implement my TaskMaster here to handle delayed spawning.

3) Create "invisible time" for two seconds when a new Spaceball is spawned. Currently, if a Spaceball just happens to spawn where you are: BLAMO! Game over. Just a little annoying, to say the least. I want to fix this.

Once those are done, I figure I will either "beautify" the Menu screen, or I will start adding in more enemies and gameplay mechanics (like Ship power-ups and such). Currently, I'm leaning towards adding some more gameplay mechanics as I would rather get those down and fleshed out before making the various screens look good (which I can always do at the end). Basically, I want to prevent myself from spending so much time make it look pretty that the gameplay suffers.

DirectX Rant #1 - The errors. They're horrible. If I accidentally try to Draw a Sprite before calling Begin(), please just tell me that "Begin must be called first" or something like that. Whoever thought that "<INSERT MAGIC NUMBER HERE> D3DERR_INVALIDCALL" is a useful error should be SHOT on sight.

Visual C# Express Thoughts - I agree with George, here. In this case, no news is good news. I work with Visual Studio at work and the fact is that I have hardly noticed that I'm _not_ working with it at home. The only difference for me is that I'm missing ReSharper, but that is _only_ because I've been too lazy to install it yet :). You gotta love a quality IDE that doesn't get in your way and has so much functionality to it!

Spaceballs - Day 16

Jason Olson — Sat, 03 Jun 2006 01:03:00 GMT

I haven't done any coding recently as I've been getting ready for the gig I just had tonight in Seattle. I'm now checked in to the (crappy) hotel (the room is about as big as my left thigh). Luckily, they have wireless, so I'm able to at least give this update.

I realized yesterday that to take this game where I want to take it, I really need to upgrade to Managed DirectX to leverage the hardware acceleration (especially once I get into implementing my particle engine/system). So, as soon as I get back, I will be upgrading the game from GDI+ to Managed DirectX. Luckily, this conversion shouldn't take too long as I simply need to add a new Direct3dGraphicsService class and change my application to use that.

Actually, that's not entirely true. I also need to change some of my game logic. This is because GDI+ expects the origin to be in the upper left corner, while the way I will be setting up my camera in MDX will expect the origin to be in the _lower_ left corner. That should be pretty easy to fix though.

Perhaps if I really start using MDX, it will allow Andy to start giving some blogging love to it :) (don't forget Andy that George is also using Managed DirectX for the contest).

Anyways, back to reading the AI book I picked up the other day.

You may not get another Spaceballs update until Monday or Tuesday night. Sorry :).

Spaceballs - Day 14

Jason Olson — Thu, 01 Jun 2006 00:33:00 GMT

Well, I didn't think I was going to be able to make much progress on the game until next week (since I'm going to be gone all weekend), but I was able to get in some coding time tonight that I wasn't expecting. And you know what? I'm glad I did :).

My tracer bullet is completely finished now (take that George, :P) :).

Tonight I wrapped up the High Score system and made it persistent using simple XML serialization to the game's own folder under the Application Data directory. The High Score screen is displaying the results and the Recap screen will congratulate you if you have achieved a new high score.

So, all the major "required" features are done and checked off the check list. That means that what is left is making it look good, adding more enemies, tuning game play mechanics, etc. This is one feeling that I love about implementing tracer bullets: once you finish the tracer bullet, you realize that a large portion of your system is fully operational and ready to be added onto.

So, now I'm on to simply making it fun. Not bad for Day 14. I still have roughly 28 days to finish the game (giving me some wiggle room, just in case). I'm fairly confident I will have quite a fully-featured game by that time considering that I have twice as long left than I've already spent on it.

Yee haw :).

Perhaps I will take some time next to do some performance profiling and getting my framerate back up since it has dipped to under 100 fps. Although, on second though, I won't worry about that until it dips under 60 fps since it won't be noticeable 'til then anyways.

Soooooo, I guess I'm on to adding some new enemies, weapons, power-ups, and the like. Sweet! Here's where the real fun begins :).

Spaceballs - Day 13

Jason Olson — Wed, 31 May 2006 01:04:00 GMT

Well, since Sir Georgio decided to give me some crap about losing focus, I figured I would post about what I've been doing.

The MVC work is all finished, cleaned up, refactored, and ready to drop a bunch of new types of enemies into the game. Before I did that though, I decided to clean up the graphics a bit.

One of the first tasks was to implement a "playing field" that play would take place on. Before, play was just the whole screen which wasn't very conducive for HUD-like UI (like Score, Lives, etc.). The playing field is now implemented and operational.

I still think it is important for me to hook up the High Score system before plugging in new enemies. Once the high score system is fully implemented (shouldn't take that long), my tracer bullet will actually be entirely complete and functional. Then I can move on to beautify-ing the application and adding some more gameplay elements.

Here's a new screenshot of how it looks now. Still not stellar, but a definite improvement over my last post (and yes, I made the Sprites myself (although any artists out there can probably tell that fact already)).

Spaceballs - Day 10

Jason Olson — Sun, 28 May 2006 00:33:00 GMT

The tracer bullet is basically all finished now. I have enemies being spawned on a regular basis, the scoreboard is operational, the "Recap" screen is working. The only thing that is not implemented yet is the High Score system and screen. Of course, currently there is only one "type" of enemy and the game stays at an even pace and never "accelerates" to make it harder.

Obviously, there is a lot more work to do. I'm just happy to be at a point where the game is basically entirely functional now. That makes me happy :).

Tomorrow night will probably be spent doing some cleanup and refactoring to make up for today's coding session(s). Once I hook up the High Score system, I will need to add some different types of enemies and add some increased pacing to the game. I will probably also have to tweak the game flow a bit (ship speed, bullet speed, enemy speed, etc.).

Now, to show how truly pathetic I am at art, and to show off my extreme programmer art, I present this screenshot. Just remember that to this point, I am _not_ worrying about graphics. I am worrying about gameplay and functionality. Perhaps posting this screenshot will really make Chris and George think that I will definitely lose :).

Spaceballs - Day 9

Jason Olson — Sat, 27 May 2006 00:21:00 GMT

Just a quick update for the night before I head off to bed :).

I finished my move over to a more Model/View/Controller-centric codebase. The move was pretty painless. The code is definitely starting to look a lot cleaner. I like seeing smaller sized classes that only have a single responsibility :).

Of course, the MVC pattern does mean more code in general, but the code that is there is much more cleaner and easier to maintain if done well. So I'm not so worried about that.

The gist of it is that the code is now in a _great_ place for a marathon coding session tomorrow of adding enemies, scoring, health, etc. I should be able to plop new enemies in relatively easy. Once I get some enemies and scoring in place, then I will look at producing a code drop for everyone.

Like I said, it's a short update :). There will most likely be more to come tomorrow :).

Spaceballs - Day 7, Part 2

Jason Olson — Thu, 25 May 2006 11:22:00 GMT

Okay, just one last update before I head off and hit the sack. I was able to get the Wall game object written. I also just wrapped up my CollisionDetectionService so I have collision detection working in my game now. For now, the collision detection is rather rudimentary. It just uses bounding boxes along with the RectangleF.Intersects() method in the .NET Framework to do bounding volume collision detection. Pretty simple, but pretty effective (I may not even have to change it for the rest of the project).

I'm liking how the collision detection reads. I'll have to show that at a later time though (maybe in my retrospective?). I'm also storing a "cache" of collisions so you don't see "Ball1 collided with Wall1" and "Wall1 collided with Ball1" as two separate collisions. All my game objects derive from a common GameObject base class which has an ID property that is generated by producing a new Guid. So, the "cache key" that I'm using is basically xor'ing the hashcode of both objects' Guids together. Once again, pretty simple.

My one concern with the collision detection algorithm now is that it is brute force (checking every object against every other game object). Since this game is a simple 2D game that may not grow that complex in regards to the number of game objects, I'm hoping this algorithm will continue to work. If not, I'll look at moving the game object repository to storing by quadtree or something like that to better cut down on the number of collision checks that I'm having to do.

With this progress, I'm thinking that I can spend Friday night and Saturday working on plugging in some enemies (e.g. the Spaceballs that will gives the game its name), getting the scoreboard working, and perhaps getting health on the ship working as well. All in all, I'm happy with where I am. I'm well on my way to getting a functional tracer bullet up and running in a week or so. Then I can start working on polishing the game up (aka making the game look pretty and be fun).

Good night, all!