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 :).
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)). 
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 :). 
I noticed that in Chris's "latest post", he is merely talking about what technologies he will use, what the game will be, etc. Chris, I'm going to give you a little tip. If you want to win the contest, you have to WRITE SOME DAMN CODE! It's ironic that at the start of your project, you were trash talking me about how I wouldn't get anything done. Where are you now? Huh? For goodness sakes, a guy who has never written a game is further along than you :P. I'm just curious, how does that feel?
Although, I must fully admit, I want to see some updates from Chris on writing code as I want to be able to steal any ideas if necessary to guarantee my victory over him :) (I could care less about winning the 360 as long as I beat Chris (and George, for that matter :))). I also like reading about people's progress on their games as I think the "behind the scenes" aspect is one of the best things you get with blogging.
So, get to blogging tattoo boy :P.
On a different note: George and Rick, you are still in the Portland area right? If so, we should geek out on developing our games together some time :).
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!
Luckily, I was able hit most of my goals for the day. I still have yet to get to collision detection, but that's not that big of a deal as I can whip that up sometime on Friday night or Saturday. I have my ship automatically firing now according to a firing rate and have all controls working through the messaging system. The architecture is starting to shape up a bit and I can see that it is going well.
Next is to add one enemy and get collision detection working. After that is when the fun really starts. I then get to start hooking up the ship's health, number of lives, the scoreboard, various different enemies, etc. Basically, all the fun stuff :).
Perhaps I will post a picture here soon. Just be aware that it is suffering from programmer art something FIERCE. Of course, for the first half of the project, my focus won't be on looks, it will be on gameplay. I want to get the tracer bullet in place as soon as possible.
Back to coding for now :).
::code, code, code, code::
::some time later::
More updates. I got some boundary checking finished. The code now checks if bullets have left the field of play. If they have, they are immediately removed from the game. I don't like the way it feels though. I'm thinking of implementing a Wall game object. This way, there will be four Walls that comprise the "field of play". If I go this route, than I can use normal collision detection for boundary checking as well. Basically, if a bullet collides with a wall, remove it from play. Also, if a ship collides with a wall, don't let it go any further. I will feel more comfortable when all this code is using the same collision detection algorithm rather than numerous "special cases". This could also open up some interesting game mechanics (like having a non-rectangular field of play or adding obstructions in the middle of the field of play, etc.).
So after that last coding session, I am exactly where I wanted to be by the end of tonight (and I still have another hour of coding left :)). Maybe I will move on now to writing up the Wall object I talked about above. If I can crank that out real quick-like, I will whip up a CollisionDetectionService that will be used to detect collisions. Then the SpaceballsGame class can determine what collision interactions it needs to deal with (like Bullet -> Wall, Ship -> Wall, etc.).
If I can get all that finished tonight, I will be ahead of where I was hoping to be at this point in the project (although perhaps not, since I won't have any coding time on Thursday Night, Sunday, or Monday :(). The good news would be that almost everything would be in place to start dropping in enemies and getting them going :).
Until next time, I'll see you on the flip side :).
|