Okay, enough being coy. Money talk.
Since Robot Legion’s November 28, 2012 release on Xbox Live Indie Games, I’ve had 2824 downloads of the trial with 751 purchases. At 70 cents a pop (the purchase price is $1 of which 30% goes to Microsoft), that comes out to $525.70 to date. That amount I then split with the original creator of Robot Legions.

Broken down by month, the numbers come out as follows:

So, that’s not a lot of money, but then again I wasn’t really expecting that much. Of course, I wouldn’t mind making more money but I’m mostly thankful to have a hobby that doesn’t cost me money and allows me to keep my gamedev skills sharp.

Still, it is worth noting that the conversion rate (purchase over trials) for the game comes out to 26.59%. Compared to old-school shareware numbers (which generally had a conversion rate of < 10%) that number is pretty good. For Xbox Live Indie Games however, that’s a fairly average number (and low compared to successful XBLIG titles.) The Xbox Live Indie Games market may be small but it is abnormally focused. The people who actually go there are primed to buy games and it shows in the conversion rates.

As a side note, my 2010 Xbox Live Indie Games release Legend of the Rune Lords is pulling in around 25 purchases a month. Since December 2011, it’s managed to total about 376 purchases. So, the long tail is there on XBLIG, it’s just really, really thin.

Before that though, a few words about why I’m doing #OneGameAMonth (#1GAM for short) in the first place. Here is the mission statement from my #OneGameAMonth profile page:

My biggest hope in joining #OneGameAMonth is to use it as a chance to challenge all my assumptions about how games should be made. By holding to the seemingly impossible goal of One Game a Month, I hope to find what I need to change (and what I’m unwilling to sacrifice) in order to make more, better games. Also, making friends and becoming AWESOME!

My main goal is to challenge myself to approach game development in ways that I haven’t before. So, this is how am I doing so far:

For my first #OneGameAMonth project, I decided to start with an easy warm-up: an update of an existing game. In this case, an update for my latest XBLIG game, Robot Legions. Be sure to check it out to see how it went.

For my next trick, I’m going to try for a real challenge and make a new game.

Naturally, making a new game from scratch takes time so I’m leveraging as much of my previous projects as possible. I’m even going so far as copying my last released game’s code wholesale and then replacing the parts I need to make my new game. While I am spending some time cleaning up and excising code I don’t need, I expect this approach to pay dividends once I start having to implement menus and such. If I can get away with just re-skinning and adjusting the flow of my previous title’s menu code, I can spend that much more time focused on the gameplay itself.

The other weapon in my time-saving arsenal is an almost single-minded focus on the game’s concept. I want to do ONE THING with this game and that is replicate the feeling of an Itano Circus. The Itano Circus (or “Macross Missile Massacre”) refers to the wild flurries of missiles that occur in anime dogfights like those in Macross. Check out the video below if you want to see what I mean:

While making a game, it’s easy to have feature creep set in and blow the scope of the project. As much as possible, I’m trying to stay aware of that phenomenon and stop myself went it starts to take place. Whenever I have a new idea for the game, I ask myself: “Does this help the Itano Circus feel?” If not, I cut it. Then and there.

Here are screenshots of what I have so far.

(It’s probably not coincidental that every choice I make to bring out the Itano Circus-ness of the game seems to take it closer to Afterburner II. I imagine the creators of that game drew inspiration from many of the same sources I’m now using.)

So far, I’m managing to keep focused on my goal. Hopefully I can keep it up and finish this game this month. After all, I have a new project waiting for me next month because, well you know, #OneGameAMonth.

This update improves upon the original with new graphical effects and an added ability for the player to toggle their firing modes. Now you can switch between synced and alternating fire modes allowing you to choose between accuracy and rate-of-fire as best fits the situation.

New visual effects in this version are bullet trails, smoke from explosions and a new vignette shader effect. These new effects can be toggled on or off in the options menu for people who prefer the original look of the game.

Check out these screenshots for a taste of what the new Robot Legions has to offer:

Robot Legions, available now on Xbox Live Indie Games.

Yuck.

So, in the interest of helping other XNA devs out there, let me tell you about what I screwed up and how I fixed it.

So, let’s get to the meat. Let me show you how I screwed up my save data handling.

First, this is how I read my save data:

// Deserialization
XmlSerializer s = new XmlSerializer(typeof(T));
if (container.FileExists(filename))
{
    TextReader r = new StreamReader(container.OpenFile(filename, FileMode.Open));
    saveDataItem = (T)s.Deserialize(r);
    r.Close();
}
container.Dispose();

And this is how I wrote it:

// Serialization
XmlSerializer s = new XmlSerializer(saveDataItem.GetType());
TextWriter w = new StreamWriter(container.OpenFile(filename, FileMode.OpenOrCreate));
s.Serialize(w, saveDataItem);
w.Close();

See the bug? Yeah, well, neither did I. You see, there was this little problem with how I wrote my save data. The code above would work in most cases, but if I wrote data that was shorter than the previous file’s save data, the old save data would only be partially overwritten. Any bytes of the old save data not explicitly overwritten by the new save data would remain appended to the end of the new save data. Thus potentially turning data like this:

<RobotSaveData><Cash>12345</Cash></RobotSaveData>

Into data like this:

<RobotSaveData><Cash>123</Cash></RobotSaveData>a>

And totally confounding the XML deserializer. Voila! Broken save data and unhappy customers. To top it off, as far as I can tell, this behavior doesn’t replicate on Windows, only on the Xbox 360. You can imagine my consternation.

Enough about what went wrong. Here’s how I went about fixing it. I changed the way I opened a file for writing my save data:

// Serialization
XmlSerializer s = new XmlSerializer(saveDataItem.GetType());
TextWriter w = new StreamWriter(
    container.FileExists(filename) ?
    container.OpenFile(filename, FileMode.Truncate) :
    container.OpenFile(filename, FileMode.Create)
);
s.Serialize(w, saveDataItem);
w.Close();

This big difference here is that I use FileMode.Truncate when opening the file for writing save data. By doing this, I’m able to dispose of the old contents and completely overwrite them with my new save data.

EDIT: I was recently informed by one of the fine members of the XBLIG community that simply using FileMode.Create when I open a file is sufficient for my purposes since it’s behavior when a file exists is the same as FileMode.Truncate.

But wait, there’s more! I’m not the only one posting on YouTube about Robot Legions. Here are a few picks from other folks talking about and playing Robot Legions on their Xbox 360s:

Lets Play Indie Games: Robot Legions XBLIG by SecretSuperHer0:

Fun with 80 MSPs: Robot Legions (XBLA Indie Game) by pjdaddelgreis:

Robot Legions 20 Minute XBLIG Gameplay by aaronthesplazer:

Robot Legions on Xbox Live Indie Games: Get it now!

Click here to see the Robot Legions product page on Xbox.com.

About Robot Legions
Blast your way through the legions of robots to liberate your homeplanet! Robot Legions is a twin-stick arena shooter that features several different enemy types, each with unique behavior. As players defeat enemies, they will collect cash that they can use to upgrade their defense and firepower. The game also features several special feats to accomplish for players who want an extra challenge.

Screenshots

Gameplay Movies(Courtesy of AaronTheSplazer)

A 5 minute video starting in the game’s free trial mode:

An extended 20 minute video of the full version of the game. You can see some of the enemy variety that shows up as you progress:

Robot Legions, available now on Xbox Live Indie Games. Get it now!

Fixing Problem #1: Structs as Dictionary Keys
So, according to the CLRProfiler, I’m creating ActorStates via Generic.ObjectEqualityComparer::Equals() during my ChooseTargetNode() function. Looking at that code, it simple looks like I’m checking against a Dictionary that uses ActorState as a key. A quick Google search turns up this tidbit on XNA Wikia. The article talks about how Enums cause memory allocations when used as keys in Dictionaries. It’s fair to assume that structs would have similar behavior and cause garbage to be created when used by the Dictionary’s internal comparison functions. Luckily, the fix for this is easy. If a struct implements IEquatable, Dictionary won’t allocate instances of that struct during comparisons. Since my ActorState struct already implemented comparison functions, I just needed to add IEquatable as a part of its declaration.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace EstrellaLib.Actor
{
    public struct ActorState : IEquatable<ActorState>
    {
        string _stateName;

        public ActorState(string stateName)
        {
            _stateName = stateName.ToUpperInvariant();
        }

        public string StateName
        {
            get
            {
                return _stateName;
            }
            set
            {
                _stateName = value.ToUpperInvariant();
            }
        }

        public override bool Equals(object obj)
        {
            if (obj is ActorState)
            {
                return this.Equals((ActorState)obj);
            }
            return false;
        }

        public bool Equals(ActorState p)
        {
            return _stateName == p._stateName;
        }

        public override int GetHashCode()
        {
            return _stateName.GetHashCode();
        }

        public static bool operator ==(ActorState lhs, ActorState rhs)
        {
            return lhs.Equals(rhs);
        }

        public static bool operator !=(ActorState lhs, ActorState rhs)
        {
            return !(lhs.Equals(rhs));
        }

        public static ActorState None = new ActorState("NONE");
    }
}

Once I did that, ActorState disappeared from my allocation list on a second CLRProfiler run.

Fixing Problem #2: Value Type Boxing with PropertyInfos
While the boxing problem caused by my code is relatively straight-forward:

        public override void ApplyToActor(Actor targetActor)
        {
            if (_targetProperty == null)
            {
                _targetProperty = targetActor.GetType().GetProperty(_targetName);
                _targetActor = targetActor;
            }
            System.Diagnostics.Debug.Assert(_targetActor == targetActor);

            //PropertyInfo.SetValue(object obj, object value, object[] index)'s second parameter
            // causes any value types I pass to it to be boxed in a temporary System.Object
            _targetProperty.SetValue(targetActor, _targetValue, null);
        }

Fixing it, is not quite as easy as simply implementing a particular interface. I need to find a way to avoid calling SetValue(). Thankfully, PropertyInfo provides a way for me to get a delegate for setting the properties value that is typed to the value I’m trying to set. This means that, if I go through the setter delegate, I can avoid implicitly casting my value type to a System.Object and creating garbage. With a bit of work, I modify my code and end up with something like this:

        public override void ApplyToActor(Actor targetActor)
        {
            if (_targetActor == null)
            {
                PropertyInfo targetProperty = targetActor.GetType().GetProperty(_targetName);
                _targetActor = targetActor;

                MethodInfo setter = targetProperty.GetSetMethod();
                System.Diagnostics.Debug.Assert(setter != null);
                _propertySetter = (Action<T>)Delegate.CreateDelegate(typeof(Action<T>), targetActor, setter);
            }
            System.Diagnostics.Debug.Assert(_targetActor == targetActor);
            System.Diagnostics.Debug.Assert(_propertySetter != null);
            _propertySetter(_targetValue);
        }

It’s not as easy to read as the version using SetValue, but it doesn’t produce any garbage. For a function that will be called multiple times a frame, it’s totally worth it.

Enjoying the Fruits of my Labor
With my code changes in place, I fire up CLRProfiler again to make sure I get the expected effect. The GC Timeline ends up looking something like this.

There we go! A few GCs occurring when the game starts up, but once we get to the Title screen: nothing. Just a flat plane of constant memory use. My garbage collection problems are solved! At least in this part of the game.

As cutesy as it may be, I’m growing rather fond of my garbage collection count display. I’m especially fond of it because it helped me find garbage collections occuring in places I never expected them to happen. Such as my title screen for example:

Ack! Look at all those garbage cans, I mean recycling bins (reduce, reuse, recycle, folks!)

That’s a lot of garbage collections for a “static” title screen. Now, how to find out what’s causing all that garbage to be created… That’s where Microsoft’s CLRProfiler comes into play.

Running CLRProfiler
CLRProfiler is a great tool for profiling your XNA game’s memory usage. It can produce graphs and tables that tell you exactly when your game is allocating what classes. It’s also a bit rough around the edges and hard to use. Even installing it eschews the oh-so-common installer for a zip file (a rarity in Windows tools nowadays.)

So, once I get my hands on the tool, the first thing I have to do is get my game running with CLRProfiler. Pressing the Start Application button seems like a good place to start, but first I need to set my working directory or else my game won’t be able to find its data while it’s being run. To do that, I click on File->Set Parameters then set the working directory to the directory where my game’s executable lives.

Next, to make sure I get all the information I need, I enable both Allocations and Calls in the Profile section. With those settings done, I’m ready to hit the Start Application button and select my game’s executable for profiling.

Diagnosing the Problem
At this point, I let my game run to the title screen so I can gather data on memory applications. After a few seconds, I shut down my game and let CLRProfiler chew on the data and present it to me.

Since I’m worried about garbage collection, I’ll take a look at the GC Timeline. Clicking the “Time Line” button gives me a graph of memory at various GC generations like this one:

See that sawtooth pattern on the bottom timeline there? Those are garbage collections. Memory builds up until it hits a threshold then garbage collection kicks in and drops the total memory usage. After that memory begins to build up again until it hits the threshold and triggers another collection and so on. Now that I know how I’m allocating memory, it’s time to find out what I’m allocating. Box-selecting one of the sawtooths, I produce a report of what is in memory at that point.

The list on the right shows me all objects instantiated during the period I box-selected. Lots of System.Objects and lots of ActorStates. The ActorState structs are definitely being produced by my code and the System.Objects are probably being produced by the way I’m using .NET. Right-clicking on the list of allocated objects, I produce a graph of which function calls allocated which objects.

All the way on the right are my System.Object and ActorState allocations. Tracking back to the left, I can follow the function calls to find out where these allocations are happening.

Aha, looks like ActorStates are being allocated when they are being compared. As for the System.Objects, it looks like my calls into the .NET’s Reflection code are responsible. Considering that RuntimePropertyInfo.SetValue() takes a System.Object as a parameter and my code is generally passing in value types, this looks like a textbook case of boxing.

Now, thanks to CLRProfiler, I know where my garbage collection problems are coming from. Next week, I’ll go into what I can do to fix them.

Okay, so enough being coy, what did I actually do? Basically, I replaced my frametime and memory displays with icons. I retain the original text-based display as an option when I need more detail, but most of the time, I can use the icon-based display to keep me aware of my basic performance profile. You can see the new frametime display in action in this screenshot from work-in-progress Robot Legions (upper-left corner):

There are 2 major elements to this new, memory-allocation-free frametime display. One is the stopwatch whose neighboring smiley face changes color and expression depending on how high the frametime is. If my frametime grows to a level where I would start dropping frames, the face icon becomes an angry red. The other element is the row of garbage cans (actually recycling bins because we’re eco-friendly around here) that show the number of recent garbage collections. It’s not a lot of information but it’s just enough to let me know when I should start using my heavier-duty profiling tools to dig into a problem.

In case you want to use this sort of display in your own project, you can grab the icon spritesheet here.

The icons are originally from the public domain Tango Icon Library. You can go there to find icons suitable for a variety of purposes.

The latest code for my frametime display code is below:

#if DEBUG
using System;
using System.Collections.Generic;
using System.Linq;
using System.Diagnostics;
using System.Text;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Audio;
using Microsoft.Xna.Framework.Content;
using Microsoft.Xna.Framework.GamerServices;
using Microsoft.Xna.Framework.Graphics;
using Microsoft.Xna.Framework.Input;
using Microsoft.Xna.Framework.Media;


namespace EstrellaLib.Debug
{
    /// <summary>
    /// This is a game component that implements IUpdateable.
    /// </summary>
    public class FrametimeCounterComponent : Microsoft.Xna.Framework.DrawableGameComponent
    {
        enum PerfIconType
        {
            Stopwatch,
            GarbageBin,
            HappyFace,
            NeutralFace,
            SadFace
        }

        Stopwatch FrametimeStopwatch;

        const int PERF_ICON_WIDTH = 32;
        Texture2D PerfIconSheet;
        SpriteFont FrametimeDisplayFont;
        SpriteBatch FrametimeDisplayBatch;

        bool ShowFrametimeText;

        public Vector2 FrametimeDisplayPosition;
        public Color FrametimeDisplayColor;

        const double FRAMETIME_DANGER_THRESHOLD = 1000.0f / 60.0f;      //If averaged frametime goes over this threshold...
        const float DANGER_COLOR_DISPLAY_SECONDS = 2.0f;                //... the frametime display will change color for this many seconds.
        
        float DangerTimer;
        public Color FrametimeDangerDisplayColor;
        float AveragedFrameTime;

        public bool ShowAveragedFrametime;

        WeakReference GcDetectionReference;
        long TotalMemoryKB;

        float RecentGarbageCollections;

        public FrametimeCounterComponent(Game game, bool showFrametimeText)
            : base(game)
        {
            ShowAveragedFrametime = true;
            FrametimeDisplayPosition = Vector2.One * 10.0f;
            FrametimeDisplayColor = Color.Green;
            FrametimeDangerDisplayColor = Color.Magenta;
            GcDetectionReference = new WeakReference(null);
            RecentGarbageCollections = 0;
            ShowFrametimeText = showFrametimeText;
        }

        /// <summary>
        /// Allows the game component to perform any initialization it needs to before starting
        /// to run.  This is where it can query for any required services and load content.
        /// </summary>
        public override void Initialize()
        {
            FrametimeStopwatch = new Stopwatch();
            FrametimeStopwatch.Start();
            base.Initialize();
        }

        protected override void LoadContent()
        {
            FrametimeDisplayBatch = new SpriteBatch(Game.GraphicsDevice);
            PerfIconSheet = Game.Content.Load<Texture2D>("Textures/PerfIconSheet");
            FrametimeDisplayFont = Game.Content.Load<SpriteFont>("Debug/Fonts/Default");
            base.LoadContent();
        }

        /// <summary>
        /// Allows the game component to update itself.
        /// </summary>
        /// <param name="gameTime">Provides a snapshot of timing values.</param>
        public override void Update(GameTime gameTime)
        {
            base.Update(gameTime);
        }

        public override void Draw(GameTime gameTime)
        {
            float deltaSeconds = (float)gameTime.ElapsedGameTime.TotalSeconds;
            TimeSpan frameTime = FrametimeStopwatch.Elapsed;
            FrametimeStopwatch.Reset();
            FrametimeStopwatch.Start();

            RecentGarbageCollections = MathHelper.Max(0.0f, RecentGarbageCollections - deltaSeconds * 0.1f);        //Subtract 1 RecentGC every 10 seconds
            if (!GcDetectionReference.IsAlive)
            {
                GcDetectionReference = new WeakReference(new Object());
                TotalMemoryKB = GC.GetTotalMemory(false) / 1024;
                RecentGarbageCollections+=1.0f;
            }
           

            AveragedFrameTime = AveragedFrameTime * 0.9f + (float)frameTime.TotalMilliseconds * 0.1f;
            DangerTimer = MathHelper.Clamp(DangerTimer - deltaSeconds, 0.0f, DANGER_COLOR_DISPLAY_SECONDS);
            if (AveragedFrameTime > FRAMETIME_DANGER_THRESHOLD)
            {
                DangerTimer = DANGER_COLOR_DISPLAY_SECONDS;
            }

            int displayItemCount = 0;
            FrametimeDisplayBatch.Begin();
           
            if (ShowFrametimeText)
            {
                FrametimeDisplayBatch.DrawString(FrametimeDisplayFont, "Frame Time: " + (ShowAveragedFrametime ? AveragedFrameTime : frameTime.TotalMilliseconds) + "ms", FrametimeDisplayPosition + Vector2.UnitY * (FrametimeDisplayFont.LineSpacing * displayItemCount++), DangerTimer > 0.0f ? FrametimeDangerDisplayColor : FrametimeDisplayColor);
                FrametimeDisplayBatch.DrawString(FrametimeDisplayFont, "Total Memory: " + TotalMemoryKB + "KB", FrametimeDisplayPosition + Vector2.UnitY * (FrametimeDisplayFont.LineSpacing * displayItemCount++), FrametimeDisplayColor);
                FrametimeDisplayBatch.DrawString(FrametimeDisplayFont, "Recent GCs: " + (int)RecentGarbageCollections, FrametimeDisplayPosition + Vector2.UnitY * (FrametimeDisplayFont.LineSpacing * displayItemCount++), FrametimeDisplayColor);
            }

            DrawIcon(PerfIconType.Stopwatch, FrametimeDisplayPosition + Vector2.UnitY * (FrametimeDisplayFont.LineSpacing * displayItemCount));
            DrawIcon(FrametimeToPerfIcon(ShowAveragedFrametime ? AveragedFrameTime : (float)frameTime.TotalMilliseconds), FrametimeDisplayPosition + Vector2.UnitX * PERF_ICON_WIDTH + Vector2.UnitY * (FrametimeDisplayFont.LineSpacing * displayItemCount));
            displayItemCount++;

            int garbageX = 0;
            int garbageY = 0;
            for (int i = 0; i < (int)RecentGarbageCollections; ++i)
            {
                DrawIcon(PerfIconType.GarbageBin, FrametimeDisplayPosition + Vector2.UnitX * PERF_ICON_WIDTH * garbageX + Vector2.UnitY * (FrametimeDisplayFont.LineSpacing * displayItemCount) + Vector2.UnitY * (FrametimeDisplayFont.LineSpacing * garbageY));
                garbageX++;
                if (garbageX > 10)
                {
                    garbageY++;
                    garbageX = 0;
                }
            }
            displayItemCount++;

            FrametimeDisplayBatch.End();

            base.Draw(gameTime);
        }

        private void DrawIcon(PerfIconType iconType, Vector2 position)
        {
            FrametimeDisplayBatch.Draw(PerfIconSheet, position, new Rectangle((int)iconType * PERF_ICON_WIDTH, 0, PERF_ICON_WIDTH, PERF_ICON_WIDTH), Color.White);
        }

        private PerfIconType FrametimeToPerfIcon(float frameTime)
        {
            if (frameTime < FRAMETIME_DANGER_THRESHOLD * 0.75f )
            {
                return PerfIconType.HappyFace;
            }
            else if (frameTime < FRAMETIME_DANGER_THRESHOLD * 1.5f)
            {
                return PerfIconType.NeutralFace;
            }

            return PerfIconType.SadFace;
        }
    }
}
#endif

Robot Legions is a new twin-stick arena shooter for the Xbox 360. It features several different enemy types, each with unique behavior. As players defeat enemies, they will collect cash that they can use to upgrade their defense and firepower. The game also features several special feats to accomplish for players who want an extra challenge.

This game is a port of the original Robot Legions flash game developed by Sentry Games. Naturally, I’ll be updating the game a bit to take advantage of the Xbox 360’s horsepower. If you’d like to play the original, you can find it here on Kongregate.

As the XBLIG version of Robot Legions nears completion, I plan on posting it for play-testing on the Xbox Live Indie Games site. If you happen to be a member, drop me a line and I will let you know once the game hits playtest.

So, yeah.
Robot Legions.
For Xbox Live Indie Games.
Coming soon to an Xbox near you!

Boo-yah!