Game Development

A work in progress

Jason Olson — Mon, 05 Jan 2009 04:06:51 GMT

Here's a sneak peek at a project/library I'm currently working on:

include Microsoft::Xna::Framework
include Microsoft::Xna::Framework::Graphics
include RubyXna

class FluxxGame < RubyXnaGame
    def initialize
        self.background_color = Color.black
    end

    def load(loader)
        @font = loader.load_font("Title")
    end

    def render(renderer)
        renderer.draw_text(@font, "Fluxx, v0.1", Vector2.zero, Color.white)
    end
end

The combination of IronRuby and XNA Game Studio is proving to be pretty darn fun!

Stones, Day 4

Jason Olson — Thu, 05 Oct 2006 07:01:00 GMT

Well, day four of Stones. I didn't get too much work done last night because I went out and had an excellent dinner with my wife and my father (who was in town on a business trip). Oh, and I also was working out some plans with some friends on an ultra-secret project :). I can't say anything yet, but hopefully once things settled down and we're a way into the project, we'll reveal it publicly. Until then, mum's the word :).

Soooooo, here is Stones on Day 4: ... (Read More)

Stones, Day 2

Jason Olson — Tue, 03 Oct 2006 09:06:00 GMT

Well, today was my second day in XNA land working on Stones (my Bejeweled clone and my first XNA game (and also a subtle play off of Jason Mauer's Bouncing Balls demo)). Once this game is finished, I'll be using it as a vehicle to do a series of game development screencasts on XNA (most likely it will also be in tutorial form that will be included with the video in the download).

I'm still just psyched how good XNA is. Maybe once I come down from "Cloud 9," I'll be able to come up with some constructive criticism. But until then, I'm going to just enjoy the ride. So, here's what Stones looks like today after Day 2: ... (Read More)

The XNA Sojourn Begins

Jason Olson — Sun, 01 Oct 2006 09:52:00 GMT

Hey folks. After a good amount of time away, I have decided to come back to game development land. This time, I will continue work on my game Spaceballs (a Geometry Wars clone), only using XNA this time around. I can't believe I'm going to admit this, but to give myself time to do this, I have even canceled my World of Warcraft account (again). I just have way too much stuff on my plate, and if I want to get back into game development, something has to go (thanks go to Chris and George for encouraging me to do so simply by reading their posts).

So, I've started "porting" Spaceballs to XNA. Maybe not so much porting, as re-writing (as I want the game architecture to reflect the new XNA environment and framework). My first impressions of XNA? ... (Read More)

XNA Game Studio Express and writing your own games for the 360

Jason Olson — Mon, 14 Aug 2006 08:16:00 GMT

I know Dave, Tom, and Boyd had stated that they were pleasantly surprised that the announcements coming out at GameFest tomorrow hadn't been leaked. Well, close but no cigar (if this is indeed the announcement they were talking about). Of course, considering that it is already "tomorrow" on the east coast (and many of you won't read this post until "tomorrow" anyway), it's probably close enough :).

So, check out that link above :).

As a hobbyist developer myself, I have to admit that I did entertain thoughts in the back of my mind that it perhaps wasn't going to get any easier for us. Well, I'm happy to say that it looks like that thought was totally false. Not only was that thought wrong, it was WAY wrong. Microsoft (according to the Joystiq article) will release a free version of XNA Game Studio inline with their current Express products. So, for those of you enjoying writing games with totally free tools like Visual C# Express, you will be able to apparently continue doing so when XNA is released. ... (Read More)

Microsoft Robotics Studio, Holy Cow

Jason Olson — Tue, 20 Jun 2006 21:57:00 GMT

Holy Moly! Could Microsoft release fewer cool products for a while please? :). There has been so many exciting technologies coming out lately that it seems like there is hardly enough time to investigate them all. The latest edition to this group of great technologies? Microsoft Robotics Studio.

There are a few things that excite me about this specific technology (from what limited investigation I have done on it during my lunch break today):

1) It is enabled for both Visual Studio _and_ the Express products (you can even use it from IronPython).

2) Robotic simulation. If you don't have the hardware to play around with it, Microsoft Robotics Studio includes robot simulation using DirectX that you can use to programatically build a robot and show how your "software" would work with the robot. I'm slightly jealous because this was one of the ideas I had behind my next game (take this Studio and make a "battle game" around it, and that was Tanks).

So, I obviously need to play around with this some more. Perhaps I'll still build Tanks now that a good amount of the "leg work" has been done for me through Microsoft Robotics Studio. I'm wondering since Robotics Studio has its own runtime and such, if I can embed that runtime within a game so that I can build a game around it. Heck, that sounds like a fun project as a matter of fact. Perhaps I've found my next endeavor after Spaceballs is finished.

Enjoy!

[Crosspost from Managed World]

Spaceballs - Day 22 - Meet My Friend Mister Reaper

Jason Olson — Fri, 09 Jun 2006 07: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 :).

OgreDotNet

Jason Olson — Thu, 08 Jun 2006 20:16:00 GMT

OgreDotNet was recently pointed out to me by a friend and co-worker. I don't know have I missed it in the past, but I see it's there now which is the important part :). With the lack of mature, open-source 3d graphics engines for managed code out there right now*, I'm glad to see this come to fruition.

Since Ogre3d is already object-oriented, you can't tell from the code of OgreDotNet that it is simply a set of bindings down into the C++ libraries of Ogre3d :). Not only that, but it appears the forum is fairly active and alive (and that's the OgreDotNet forum I'm talking about (since the regular ol' Ogre forum is _very_ much alive)).

In the future (aka after I finish Spaceballs and perhaps another game or two), I will probably end up using this for my first 3d game I do (and possibly all the other 3d games I do after that). I really want to just break down and start playing around with it now, but I'm sure my competition in this contest would like for me to do exactly that. SOOOO, perhaps once Spaceballs is finished I can start playing around OgreDotNet.

Until then, make sure you check it out :).

http://www.ogre3d.org/wiki/index.php/OgreDotNet

* Axiom priorly being sucked up into RealmForge (I know the source forge project has started up again, but it _just_ started up again seriously, in my opinion), RealmForge now being "deprecated" of sorts, and the other options like Irrlicht.NET and Haddd not being as mature and supported as Ogre (again, just my opinion)

[Crosspost from Managed World]

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

Jason Olson — Wed, 07 Jun 2006 07: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 — Tue, 06 Jun 2006 06: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 :)).