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 :).
A couple minor changes (or not so minor when it comes to control schemes). Tonight I took some time to play Geometry Wars Evolved for a while (the game Spaceballs is based on) and I came to a decision.
One of the difficulties is translating the control scheme to the PC as the console gamepad has the two joysticks that are both used to control the ship in Geometry Wars. As of earlier today, I was using a combination of the mouse and the keyboard (nearly Quake-style controls). You "dragged" the ship around with the mouse and turned where it was facing using the A and D keys. After trying it out for a while (and going back to play Geometry Wars), I realized that it felt unnatural and was not very intuitive. I have changed it to flying the ship forward using the W key, and flying backwards using the S key (full-blow Quake-style control scheme now).
With this change I realized that I needed zero mouse support for my game, so I had the pleasure of ripping all that code out (have I mentioned the sick twisted pleasure I get ripping code out of a code base?). It wasn't much code to rip out, but it still gave me a pleasure :). I saw in an earlier posts of Chris that he was considering support a Gamepad. That is a fabulous idea and I might need to steal the idea (Chris, you want to check out XInput now, I believe, not Direct Input). Heck, I have an extra 360 controller lying around from Microsoft Meltdown so I might just have to put it to use here. I will save that until the end though because I don't want to get hung up on a feature that is only "a nice to have" and not "a must have".
I had talked about it earlier, and after much internal debate, I have decided to re-introduce the messaging and tasking system. However, I am only re-introducing a much simplified model. It won't be nearly as complex or as feature complete as I am only going to add the bare necessities this time around. Once those are finished, I will change my ship to fire continuously like Geometry Wars (rather than based on an input command). Hrmph, even as I'm typing this I'm still having an internal debate about whether to go forward with this. Perhaps that is a sign that I still haven't quite decided yet and the back of my brain wants to work some additional things out. Oh well! I'm not going to let that hold me up from making more progress. Back to coding.....
::code, code, code, code::
::two hours later::
Sidetracked!! I ended up re-working my keyboard handling since I wasn't happy with it (it was quite *hackish*). That is all fixed, and I did some "cleanup on aisle 7"-style refactorings (nothing too big). I went ahead and converted the ship controls to be completely keyboard driven. It feels a lot better, but it's still not as comfortable as I would like it. It will work for now though.
Tomorrow I will probably whip up a quick Vector2D class (if I was using DirectX, I could just use the one that is built in). I will move all location/velocity values over to be Vector2D rather than PointF (I'm really getting tired of this ".X"/".Y" crap everywhere rather than using simple Vector-based math). Once I get that in place, I might go ahead and add a "slowdown" feature of controlling the ship where it will slow down after you let up the key rather than stopping right away.
My hope is that once I get some of these architectural issues settled, hooking up enemies, collision detection, scoring, etc. should be pretty easy. At least the technical aspect should be easy, there would still be the fun part of writing the AI :). So far, I'm making progress though.
My goal for tomorrow is to have the Messaging and Task subsystems hooked in and working by the end of the day. I would also like to get the GameObjectRepository hooked up and doing some rudimentary boundary checking (like destroying game objects (like bullets) when they leave the playing area). Once the GameObjectRepository is working, adding some easy collision detection (I probably won't do per-pixel at this time and will settle simply for bounding volume checking) shouldn't take that long.
Anyways, time for sleep :).
P.S. Minor Annoyance #2 with VCS Express - The limited debugging features. Visual Studio's debugging capabilities in the IDE seem much more robust (like forcing the code execution to a specific line (aka "going back in time")), etc.
|