Move Zig

Some Fudge Dice pngs for your pleasure:

The Art of Glass

My Stained Glass level editor is nearing phase 1 completion (phase 1 is having a saved level that the characters can interact with.  Additional phases will add additional features as the game needs them).  But my art assets are insufficient to create the lonely, haunted forest I want for my test place.

 A block of Stained Glass defined.

The collision data for the block.

Those pictures are fairly representative of the graphics I have so far.  I have grass.  I have leaves.  I have rocks.  But brooding, dead forests need random chunks of tree.  Otherwise they would be called brooding, dead fields.

So, as I make the tree bits, I'm gonna walk you through the process I use to make the graphics for Stained Glass.

My preferred tool for making 2D assets for videogames is Anime Studio Debut.  It lets you make some pretty nice vector graphics with varying line widths, then rig them up to deform them.  And it's fairly cheap, at forty bucks a pop.  It's the tool I used to make this animation of Sonic the Hedgehog walking.

But for Stained Glass, I shall be using Inkscape, partly because I intend to farm out some of the work and Inkscape is free, and partly because Inkscape is more suited to the kind of stiff look that works so well for stained glass.

That's enough intro!  Now the how!

Game state management

So, you need some way to manage your game states, like your menu screen and whatnot.  XNA's official samples include some fancy stuff.  XNA Game Programming Adventures has an excellent tutorial on doing a slightly more advanced state manager that riffs of the original samples.  It's in the first few episodes of their "How to make an RPG" series.  It involves all sorts of useful XNA mojo like XNA Game Components and Drawable Components, and some magic with collection classes like Stacks.

My way is simpler.  Less intrinsically flexible maybe (though I wouldn't put money on that), but you can have it up and running in ten minutes.

Here's how it works:

public abstract class State
{

   public virtual State Update(float s)
   {
       return this;
   }

   public virtual void Draw(float s)
   {
   }

}

Bam!  S is just the seconds elapsed since you last updated (more conscientious coders may want to use GameTime instead of a float).  So here's how you use it.

Suppose you've got a title screen which draws your company logo, then switches to your main menu.  Your title screen and your menu both inherit from State.  Your Title Screen looks like this:

public class TitleScreen : State
{
    float time;
    state next;

    public TitleScreen (State NextState, float Duration)
   {
       time = Duration;
       next = NextState;
   }

   public override State Update(float s)
   {
       time -= s;
       if (time <= 0) return next; else return base.Update(s);
   }

   public override void Draw(float s)
   {
       // Draw the screen here.
       base.Draw(s);
   }
}

Now, in the game class Microsoft so kindly gave us, just declare three objects:

TitleScreen title;
MainMenu menu;
State currentState;

In the Load method, initialize them.

menu = new MainMenu();
title = new TitleScreen(menu, 5);
currentState = title;

In Draw, do this:

currentState.Draw((float)gameTime.ElapsedGameTime.TotalSeconds);

And whichever state is current will draw itself.

In Update, do this:

currentState = currentState.Update((float)gameTime.ElapsedGameTime.TotalSeconds);

And whichever state is current will update, and pass back the state that should be current next.  In this example, the title screen will display for five seconds, then pass control to the menu!

Now, this may be a sloppy way of doing things -- I'm not some sort of super-guru.  But it is very fast to get up and running, and if you are an indie game developer, or even a hobbyist, you need to optimize your program not only for how fast it can run and how much memory it consumes, but also how much of your life it consumes.