M. Brandon Miller dot com

I'm alive.  Hooray.

There are three reasons for the lack of posts as of late.  The first cause is that, the search for employment has heated up and demanded more of my time, which is a good thing.  The second reason is that I had proceeded far enough with the engine that I felt that I needed to step back and decide what sort of game I was intending to create.  This resulted in a lot of game design brainstorming that, while productive, did not make for good video.   The third reason is 3D Dot Game Heroes, which was completely legitimate research into developing retro-style games.  Yes.

The bosses in Beat Hazard, with their random assortment of turrets, reminded me a bit of the super procedural bosses in Warning Forever.  This rekindled an idea I had for making a game with this engine, namely, the generation of random side-scroller bosses.

The first type of boss I could imagined creating a simple set of, interchangeable powers and behaviors for was a character similar to our hero.  A guy with a set of attachable weapons and armor that do various things.  I thought back to the endless supply of Robot Masters from the Mega Man games and came up with the next phase in this process.

Random boss guys should drop their random boss weapons when defeated.  This made the immediate mental connection with my recent experience playing Borderlands and Torchlight.  A supply of random boss 'man' characters dropping random weapons could make for a highly amusing 'loot treadmill' scenario.  

I won't get into too many further details of the assorted silly game ideas I had, but they were numerous and silly.

But were they fun?  To determine that, I began laying out plans to develop some of the basics of the system and prototype it out, starting with a system by which I would randomly generate weapons for our side-scrolling protagonist.

The early phases of that can be seen in this video, where ten or so random weapons are dropped into the inventory.

These weapons have properties that are rolled for on various tables including increasingly rare gun attributes.  

The most important may be the type of projectile fired.  While the bullets have few differences at this early phase, they do pull from different asset files that can define stats such as damage and velocity, as well as what sub-class of bullet they are actually defined by.  This will allow me to do things like having a grenade that respects gravity and bounces without changing the core 'dynamic gun' class at all.

I also added some basic stats on the back-end to define things like hit points and attack power.  I also added some basic RPG-Style flying numbers, although they're pretty much all '1's at this point, but the systems are coming together.

Orange world!  A practice 360Ed picked up from Valve that I'm applying to this project.

This should help me skip over the programmer art stage and get more features in quicker, but it should also prevent any of this stuff from slipping in to a final game.

Early this week I added the ability to pause the game, and alter the flow of time for different actors.  To demonstrate this, I went with the obvious parody route of giving the hero slow-motion cool shades.

Then I spent a while trying to get a basic inventory and equipment UI system going.  It's very placeholder, but it seems to be working so far.



Oh wow that's orange.

After the success with shoes, I moved on to try and re-integrate the basic enemies from the XNA Platformer example back in under my 'Character' umbrella.  The enemies now use a movement system much more similar to the player character, and they obey the law of Gravity, amongst other things.

They still just wander back and forth for now, but that was all I needed to go ahead with player versus enemy collision detection and response.

To do this, I added the concept of 'conditions' to the game characters.  Conditions act after equipment and further alter the actions and movement of Characters.  In this case, the condition I added was 'HitStun' which causes the guy to throw up his hands and move with very little friction for a short time.

With this came a few minor additions like robbing the player of control and adding a temporary invulnerability to prevent stun-lock.

Then, to fight back, I added another piece of equipment, a little blue gun.  'Guns' over-ride the normal asset loading when they find a 'bullet' amongst their children.  Rather than adding it to the hierarchy, they store it off in a hidden place and then clone it and attach it to the active room when fired.

This should allow for a wide variety of data-driven guns that shoot various things.

Finally, this afternoon I looked into the XNA particle effects sample and quickly integrated it into my engine so that the enemies could explode when hit with bullets.

Double video post today.  Since the last time I've spent a while working on the collision detection.  I wanted to keep things simple for now, but I ran into some edge cases and other wackiness that it took me longer than I would have liked to hammer out.

Also, I was frustrated by my efforts to get cross-platform save data working due to my failure to convince the XBox to ignore certain items during serialization.  Eventually I would up creating a stripped-down version of my property object for saved data.

So once that was over with, I decided it was time to add some Parallax backgrounds, and what I stumbled on to was the whole issue of the draw order.

The current solution is not as elegant as I'd like.  There's pass that traverses the actor hierarchy and demands that everyone line up their renderables into one of several different rendering layers, then the actual draw calls are made after that.

This will probably need serious optimization later since the whole "everybody, get in here" happens every frame.  However, for now, it does allow different tiles in the room tileset to be drawn on different layers, while still respecting the actor hierarchy for things on the same layer. 

Also present today, doors!  The blue spaceship that isn't a parallax object is a door that the player activates with a button press, taking them to another 'door' in another 'room'.

Today's second video is a very simple sample of the idea of 'equipment', special children of the player and certain other actors that modify and respond to their actions.

In this case, we have gear that modifies the player's physics when equipped, allowing him to jump higher.

These test boots also caused me to realize that I had completely forgotten to cause children to render and detect collision relative to their parent.  I quickly added that in, so now the hero's boots will remain with him.

So I spent a while yesterday getting a variety of 'camera' options in play.  Eventually I decided for now to just stick with a constant-speed following of the hero for this sample, since my various attempts to add more complicated physics would require too much polish to look right.

The 'zoom' on it can be set via the same asset properties as everything else, either on the camera asset or in the world that calls in a generic camera.

This camera is also tracking not the hero directly, but an offset point set by a property on the hero, who, as you may notice, is an old retro hero from an unfinished project of mine that pre-dates my FIEA adventure.

He is also scaled up from his original sprites, which, while it looks rather fuzzy, is another fun-filled feature added in the past day.   The bounding box also scales with the sprite and remains tied to the sprite's origin.

I'm going to have to find some sound effects and music in the public domain for future demos.  For today's Youtube demo, I hope no one objects to my briefly stealing from Kirby.

Progress is being made in the world of XNA.  I spent a while figuring out the right way to load in the assets and properties mentioned before in a hierarchical format.

I've spent a lot of time gutting the sample platformer game of most of its' game-specific code.  I was going to toss out the whole system of 'tiles' for the background until I looked closer at how they worked.

At first I thought having such a large number of collidable objects would be a horrible drain on performance for anything larger than one screen, but then I realized that the grid was more than just a way to lay out levels, it was also a convenient way to sort things for collision detection, since we know where on the grid the relevant actors are.

I did, however, disconnect the collision and graphics elements of the grid.  As it stood, the collision type and texture were wired together.  I also added in a data-driven 'tile set' xml, which brings back memories of RPG Maker already.

I'm still going to support colliding actors who don't fit nicely into a series of cubes, but I'll be keeping this grid around for now to help lay the foundation for platforming adventure.

Today's screenshot still uses the sample assets, but it was screen-grabbed from my own XBox, so that's exciting.

Now that the website is fairly stable and the initial volley of resumes as been fired, it's time to keep the programming and game-design skills sharpened with some side projects.

During my FIEA adventure, we looked into XNA and C# during the programming class when we were learning to develop networked tools that could modify a game on the fly.

I picked it back up to try and devise a reasonably-scoped side-project to undertake.  Much like in the case of my first game at FIEA, I began by looking at a simple sample platformer and I began to think of how to modify it.  

I made a few basic changes and felt like I had a good feel for it, but then I decided that after everything I had learned at FIEA and 360Ed, I should actually set up a versatile and well thought-out class structure rather than just jumping in to making the little hero do different, amusing things.

It wasn't long before I ran head-first into the various ins and outs of the XNA content pipeline, which was explained surprisingly well in a number of places, but my desire to leap headlong into gameplay lead to my getting tangled up in the series of tubes.

Once I was freed from the maze of pipes and I had my xml files resulting in asset data, I found myself desiring and rebuilding a number of old, familiar digital friends from the Conspiracy Code games, such as 'asset' and 'property'.

While such classes would be rather different for a one-man 2D C# game than a 3D team effort in C++, it was still sort of odd and nostalgic to see a somewhat familiar structure taking shape.

Well, the tubes are becoming decidedly less frustrating, so hopefully I should be getting some of my own wacky programming art into this game soon.  When I do, this will be the place to see it.