Last night I launched my (in my mind) long awaited update to http://xblcg.info: XboxIndies.com. XboxIndies.com takes over being a full catalog of the now Xbox LIVE Indie Games channel, as well as incorporating new browsing features, better searching, a full newsblog, and commenting directly on games.
If you haven’t checked it out, please do. I’ve got a small team of writers as well, so our newsblog is sure to keep you up to date on the world of Xbox LIVE Indie Games.
Edit (6/21/2009 9:53pm): Looks like Destructoid has pulled the article. The link now just takes you to a blank page that says “This post is not live and only visible to editors”. Not sure if this is related to my blog post or something, but we’ll see if the article comes back up in some form later.
Edit (6/21/2009 10:06pm): The article is back up and the rest of my quotes have been edited back in. While I’m still a little upset at what was originally cherry picked out of my interview, I am glad to see the writer or editor decided to put the full of my ideas into the article.
Edit (6/21/2009 10:51pm): I’ve been talking to the author a bit in emails and wanted to clarify a little what this post is about.
First I want to state that I’m not angry at the author. After speaking with him it’s clear that he wasn’t trying to misrepresent what I said; I just personally feel that the full of what I wrote gave a very different tone to what was given in the article. Ben and I both agree on some major points in that article such as the discoverability and sales of Xbox LIVE Community/Indie Games and I think that this article will help in driving towards a solution.
Second I want to state that I want people to be a little more considerate of the author. Some of the comments on his article attacking him are unacceptable. It’s one thing to state one’s disagreement with an article, but the personal attacks and accusations aren’t needed. Please try to be more respectful in the future.
I’ve decided to strike out some of my article to convey my change of perception on the issue. I want everyone to know that Ben didn’t intentionally take quotes out of context or try to misuse my quotes. This post is simply my personal interpretation of how my quotes, in the context used in the article, seem to me.
Destructoid posted an article earlier today talking about the state of Xbox LIVE Indie Games, specifically focusing on the “app” angle of the system. I was interviewed for this article some time ago and am a little upset by the quotes they took from me. As probably expected, they only really used pieces of my response that implied that I agree that apps are ruining the system which is definitely not my belief. So here I am, revealing more of my response so that people get a more clear picture of what I think.
Let’s take the first bit they used from me:
Nick Gravelyn, who runs Xbox Live Community Games Catalogue (a meta-critic of sorts for the Indie Games), is well aware of the situation. He is both a developer of games, as well as someone deeply entrenched in the Indie Games community. “I know a lot of developers are upset that these apps are “stealing” their money and feel the apps should be banned from the system.”
So what did I really say about that?
I know a lot of developers are upset that these apps are “stealing” their money and feel the apps should be banned from the system. My take is that those developers complaining are free to make their own apps if they feel it’s a more lucrative market. I don’t see the apps as competition to me because ultimately someone looking for a virtual fireplace is not likely to spend that money on a puzzle/shooter like Bloc. Or maybe they saw the fireplace and then found my game and bought my game or both my game and the app. So I consider us two inhabitants of the same ecosystem. If they are drawing new consumers into the channel it can only be a good thing.
As you can see, if you only take that first sentence it gives a much different opinion to the whole of the paragraph. Let’s take a look at the finale of their article, again with a quote from me:
In the end, I believe that Gravelyn sums this whole situation nicely. “Ultimately this is exactly what was bound to happen with such an open system,” he said, “I’m not sure Microsoft expected to see massage games or a calculator, but that’s the beauty of opening up a closed platform.”
And my full response:
Ultimately this is exactly what was bound to happen with such an open system. I’m not sure Microsoft expected to see massage games or a calculator, but that’s the beauty of opening up a closed platform. Lots of people want to make games for XBLCG, but some people just see the Xbox 360 as another platform on which they can make and sell their apps and I say good for them.
So there you go.
In the end I think apps are perfectly fine on Xbox LIVE Indie Games, but it seems that Destructoid was only going to pull quotes that made it seem that the world thinks apps are ruining the system. I guess I probably could have seen that coming, but it’s still a bit annoying to see quotes from me that feel like they misrepresent my feelings on the subject.
For me, E3 might as well just be the press briefings given by Nintendo, Sony, and Microsoft. Sure, I’ll hear about other things and like other announcements, but the presentations these guys give set the stage for the show and the next year in my book. So I figured I’d just give my take on all the stuff that was announced.
First, the good:
In addition, I think Natal could be used to supplement more traditional games as well. Since I just got done writing a post on GameDev.net on the subject, I’ll just let you read it there: http://bit.ly/1KeTSU
Sony seems to be the only one that’s really targeting traditional gamers in a big way with their motion controls. It’s definitely an interesting take on it and they seem to have the tech to back it. I was skeptical at first (and was in the “it’s just a WiiMote rip off” camp), but after they showed the demos I was sold hook, line, and sinker that this brings something substantial to the table.
The “WTF?”:
I’m not even sure I have to say anything more.
The Bad:
So that’s basically it. There are probably some things I missed, but that’s bound to happen when trying to recap six hours of press conferences from three companies showing dozens of games all by memory. It’s definitely a good year for games and now I can’t wait to get my hands on some of these games this fall. Now the usual problem of finding the money for all of them…
It seems that for one reason or another I was never able to make a good base class for singletons in C#. They usually wound up with requiring that the derived class call some method to set itself as the static instance. Today, while working on building a fresh new library that I’m going to build a 3D “engine” on top of, I wound up stumbling upon a really nice solution. I realized that I can cast the ‘this’ reference to the type of the singleton. So I wound up with this base class:
public abstract class Singleton<T> where T : class, new()
{
private static T instance;
public static T Instance
{
get { return instance ?? (instance = new T()); }
}
protected Singleton()
{
// make sure we only have one instance
Debug.Assert(
instance == null,
string.Format(
"Singleton of type {0} already instantiated.",
typeof(T)));
instance = this as T;
// validate that the cast worked
Debug.Assert(
instance != null,
string.Format(
"Singleton of type {0} failed to be instantiated.",
GetType()));
}
}
With that laid out my singleton classes don’t have to do anything at all to take advantage of it. The trick is that to make type A a singleton, it simply derives from Singleton<A>. A little confusing initially, but it works quite well in practice. For instance, here’s a simple singleton Log class:
public class Log : Singleton<Log>
{
}
Yep, that’s it. I wanted to illustrate that this base class removes any and all singleton-related code from derived classes. So now to instantiate our single Log we have three options (technically two, but they’re written differently):
var log = new Log(); // manually instantiate // or use property which instantiates if needed. // we can use the Log class itself or the base // Singleton<Log> class to reference it. var log = Log.Instance; var log = Singleton<Log>.Instance;
I generally recommend using the Instance properties to make the code more explicit that the object is a singleton, but all three work just fine. If you are manually calling the constructor, the Debug.Assert will fail if you call it multiple times like this:
var a = new Log(); var b = new Log(); // Debug.Assert fails
I’m sure I’m not the first to think up this exact implementation, but since it seems to be a really nice way to stop writing the same singleton boiler plate over and over, I figured I’d share.
I love my iPhone. I like playing games on the iPhone (well, at least the few ones that I have). I like making games. One would assume I’d have given up on XNA GS for good and stayed with the iPhone. Well, there’s one problem with making games for the iPhone.
The customers.
For some reason I have yet to understand, the gamers on the App Store don’t just appreciate, but expect an endless amount of updates that implement their ideas. We’re talking games that are $1 or $2. They pay practically nothing for a game (some even really good games) and then feel entitled to more content for free.
Well screw you.
Here’s a review for Zombieville USA that I stumbled upon while looking for new games to try out that illustrates what my complaint:
That’s right. On a $2 game that has had not one, but two free updates already, this customer feels like the developer is “giving [them] the shaft” because the developer has decided to move on and work on a new game. The customer is also upset that the developer didn’t take the ideas of the users’ ideas and implement them (ideas like new weapons, enemies, and adding bosses into the levels, all things that are more than just minor tweaks).
This drives me insane. Remember The Sims? $50. If you wanted that night club update? Another $20-$30. Want some holiday junk for you house? Another $20-$30. How did we go from every update costing more than $20 to users feeling they should get infinite free updates on something they paid only $2 for?
That is why I have such a hard time going back to the App Store. I don’t really feel like developers are appreciated like they should be. These gamers are getting some really quality pieces of entertainment for less than a coffee at Starbucks and yet they’re so ready to call developers names and accuse them of hating their customers just because they want to move on and make a new game.
It’s just a sad, sad environment and I really hope that it doesn’t start happening on XBLCG. I love making customers happy, but at a certain point they do need to realize that developers move on. Whether it’s because they need more income or they’re just tired of working on a game they may have worked on for months and months, customers should let developers move on and make the next awesome game instead of trying to chain them to updating the existing ones.
</rant>
The best part of playing with other APIs and platforms is finding all the little gems you can bring back to your preferred platform. In this post, I’m bringing some of the NSTimer functionality found in the iPhone (and regular OS X) Cocoa Framework to the XNA Framework.
The NSTimer class is basically like any other timer, but it integrates so nicely given the run-loop mechanism used in Cocoa. Basically you could call a single static method and it would create a timer and add it to some mysterious list where it would be managed and updated without you having to care. In other words, fire and forget timers.
This is something I really wanted for myself when I came back to the XNA Framework so I hammered out my own replacement today and, like usual, I feel like sharing. Before I get into the implementation, let me just show you a quick example of what my Timer API looks like to use.
Let’s say I have a variable defined as “Color clearColor” in my main game class. This variable is used when clearing the screen. Now, let’s say I want it to change to red after the game runs for five seconds. Well, with the Timer API we just do this in our Initialize method:
Timer.CreateTimer(5f, () => clearColor = Color.Red);
And that’s it. Now there is one small caveat which is that you have a Timer.Update(GameTime) static method that you need to call in your game’s update method which will drive every timer. However you never need to explicitly add any of these timers to the list nor manage updating each one individually. Heck, even though the CreateTimer method returns a Timer, you don’t even need to hold onto it if you don’t want.
So let me just show you the implementation. It’s pretty long, so I just uploaded the .cs file for you to look at: Timer.cs. It’s pretty well commented so it shouldn’t be hard to figure out. I provide a lot of overloads of CreateTimer to take in different Action types as well as shortcutting for timers that don’t repeat since that is a common scenario.
If you do have a timer that repeats, you can simply hold on to the Timer reference from CreateTimer and call Invalidate on it whenever you want it to stop updating. Then just null out your reference and you’re all set.
Another nice thing the Timer class does is recycle timers. Given that most timers will be used in a fire and forget manner, it makes sense to just hold onto ever Timer object created and reuse them as they become expired. This lets you create timers as much as you want and never have an issue with the garbage collector.
To top it off, you can actually make some pretty fun and complex timer scenarios without doing much work. Take for instance a scenario I came up with (which actually inspired me to make this class) which is a logo screen at the start of a game. I wanted the game to start, wait one second, display a logo for two seconds, wait another second, and then move on to the next screen. If I were doing this by hand, I’d have all sorts of state variables and other things to track to make sure each timer was handled in order. But with the Timer API I can simply nest a bunch of CreateTimer methods like this:
Timer.CreateTimer(
1f,
() =>
{
titleVisible = true;
Timer.CreateTimer(
2f,
() =>
{
titleVisible = false;
Timer.CreateTimer(1f, () => ScreenManager.RemoveScreen(this));
});
});
And that’s that. No states to manage, no individual objects to update, and no worrying about garbage collections here.
Hopefully others will enjoy the Timer API. It makes life so much easier when you have events you want fired at specific times or intervals, but don’t want to be hassled into tracking and updating a whole bunch of individual timer objects.
One thing that I like to do is keep my unread posts down to 0 on the XNA forums. But it got really annoying to have to ctrl-click every link to get them all open in new tabs, read them (or just let them load), and then close them. Then repeat for the other pages.
I starting thinking and realized that I can use a Javascript bookmark to help me out. So I wrote up this bit of JavaScript here that uses some regex to find all the “Last Post” links on the current page you’re on and open them in new windows/tabs.
javascript:
var myreg = /\<a href="(.+?)"\>Last Post\<\/a\>/g;
var i = 0;
for (i = 0; i < 20; i++)
{
var match = myreg.exec(document.documentElement.innerHTML);
if (match.length == 2)
window.open(match[1], '', '');
}
void(0);
So you can just copy/paste this into the URL bar of your browser while on the Not Read page, but the real beauty is making this a bookmark so you can just click it and have all the posts come up. In fact, you can drag and drop this link to your bookmarks bar and have it easy access. Just like that. 
I figure one of the larger areas of confusion and trouble is around XML serialization. Lots of people don’t realize the power that can be had or get tripped up by little problems, so hopefully I can do a few of these and try to show some cool stuff that can be done.
The first big misconception about the XmlSerializer is the idea that it cannot handle generic lists with derived classes. I’ve been told by people that the XML doesn’t contain type information and won’t work, or that they get an error while trying to serialize. The funny part is that it would only take one little line of code to fix it.
So first, let’s set up the issue. Here’s a bunch of code to show a basic example of XML serialization:
public class Root
{
public float Foo { get; set; }
}
public class Derived : Root
{
public bool Bar { get; set; }
}
public class MainObject
{
public List<Root> Stuff { get; set; }
public MainObject()
{
Stuff = new List<Root>();
}
}
class Program
{
static void Main(string[] args)
{
MainObject obj = new MainObject();
for (int i = 0; i < 10; i++)
{
obj.Stuff.Add(new Derived
{
Bar = i % 2 == 0,
Foo = (float)Math.Sin(i)
});
}
XmlSerializer serializer = new XmlSerializer(typeof(MainObject));
string path = Path.Combine(
Environment.GetFolderPath(Environment.SpecialFolder.Desktop),
"Test.xml");
using (StreamWriter writer = new StreamWriter(path))
serializer.Serialize(writer, obj);
}
}
If you were to run this code, you will get an InvalidOperationException on the serializer.Serialize method call. To most people this means that obviously we can’t use the Derived type in the list because the XmlSerializer can’t handle it. But rather than assume that, let’s just fix our problem by attaching an attribute to the MainObject class:
[XmlInclude(typeof(Derived))]
public class MainObject
{...}
By doing that, we’ve now instructed the serializer to include the reflection information for that type when serializing so it can be used. If we run this again, you’ll find an XML document on your desktop filled with the information. Contrary to what some may say, you’ll see each item in the list has an xsi:type attribute added onto it so that the serializer will know what type to create when you later deserialize the list.
This error occurs because the XmlSerializer cannot possibly know every subclass of our Root class. It would have to search all currently loaded assemblies and that’s just not an efficient way to go about things. So instead the serializer requires that you manually include the types that might be in use in your object. You can have as many of the XmlInclude attributes as you need, so just keep adding them on for every new subclass you have.
This is a little mini-series I’ve wanted to do for a while. I wanted to go through some common misconceptions about the way things work in .NET in order to help people get through problems instead of working around them. I have a few parts planned, but we’ll see how many I can come up with.
So this first one is about garbage, the most overrated fear of a lot of game developers. The big misconception for this post is the idea that you can’t use an enum as the key in a Dictionary<TKey, TValue> without generating garbage each time you index in. This leads a lot of people to do ugly hacks like casting the enum to an int or short (possibly even with a subclass or wrapper to do it for them). This is ugly and hacky and ruins the type safety that generics bring because you have allowed the key to be any integer or any short.
Instead of this silly work around that leads to ugly code that is harder to write and annoying to read, just pass an IEqualityComparer<T> to the dictionary’s constructor, where T is the same type as the dictionary key (and yes, it will enforce this at compile time so you can’t pass any other kind of IEqualityComparer<T> in even if you wanted to).
So as an example, let’s say I want to store my own dictionary of GamePadStates so that way I can always grab them but only update from the gamepad’s themselves once per frame. The first thing we’ll do is just make up a static class to contain this functionality for us:
public static class InputManager
{
public static readonly Dictionary<PlayerIndex, GamePadState> CurrentStates;
static InputManager()
{
// instantiate the dictionary
CurrentStates = new Dictionary<PlayerIndex, GamePadState>();
// add the empty values to ensure all keys are present
CurrentStates.Add(PlayerIndex.One, new GamePadState());
CurrentStates.Add(PlayerIndex.Two, new GamePadState());
CurrentStates.Add(PlayerIndex.Three, new GamePadState());
CurrentStates.Add(PlayerIndex.Four, new GamePadState());
}
public static void Poll()
{
CurrentStates[PlayerIndex.One] = GamePad.GetState(PlayerIndex.One);
CurrentStates[PlayerIndex.Two] = GamePad.GetState(PlayerIndex.Two);
CurrentStates[PlayerIndex.Three] = GamePad.GetState(PlayerIndex.Three);
CurrentStates[PlayerIndex.Four] = GamePad.GetState(PlayerIndex.Four);
}
}
It’s a simple class but suits the purpose. We have a dictionary of the states and a Poll method that takes care of polling the input. We would then set this up to Poll once per frame (at the start of our Update method) and then simply reference the CurrentStates dictionary everywhere else.
At this point, many people would start screaming “But those enums are going to cause garbage!!1!”. Sure, right now they definitely are. But we can fix that. Let’s make a new class real quick:
public class PlayerIndexEqualityComparer
: IEqualityComparer<PlayerIndex>
{
private static PlayerIndexEqualityComparer defaultInstance;
public static PlayerIndexEqualityComparer Default
{
get
{
if (defaultInstance == null)
defaultInstance = new PlayerIndexEqualityComparer();
return defaultInstance;
}
}
public bool Equals(PlayerIndex x, PlayerIndex y)
{
return x == y;
}
public int GetHashCode(PlayerIndex obj)
{
return obj.GetHashCode();
}
}
This is a pretty simple class that just implements IEqualityComparer<T> for the PlayerIndex type. The static stuff is just a little extra I tossed on so that we can just reuse the same object if you want to have lots of dictionaries or other types that use IEqualityComparer<T> for the PlayerIndex type.
Anyway, let’s go back to the InputManager and alter the instantiation of the dictionary to this:
CurrentStates = new Dictionary<PlayerIndex, GamePadState>( PlayerIndexEqualityComparer.Default);
And now we no longer have garbage.
That’s really all it takes. You can make an IEqualityComparer<T> for any enum you want to use as a key in a dictionary and never worry about boxing and garbage ever again. Just please stop casting enums to ints/shorts as keys. That’s ugly.
Edit: For a bit more clarification on why you get boxing to begin with and why this fixes it, please see my first comment below (comment #2).
After one of those suggestions you hear and think “That’s just brilliant!”, I decided to make dependency injection in my Apollo entities a nearly invisible process. The idea is that I search over all of a component’s properties when it is added to an entity and any property whose type inherets from EntityComponent is assumed to be desired for dependency injection. So I can now have these two classes:
[Unique]
public class MyComp1 : EntityComponent
{
public float A { get; set; }
public float B { get; set; }
}
public class MyComp2 : EntityComponent
{
public MyComp1 Comp1 { get; set; }
}
And when I add MyComp2 to the entity, it’s Comp1 property will automatically be set to the instance of MyComp1. There are a couple caveats, however:
1) Order of adding is important. The system no longer tries to instantiate components that aren’t added and instead throws an exception. So with my example, I’d have to add a MyComp1 object to an entity before a MyComp2 object or else it’ll throw an exception.
2) Components still need a UniqueAttribute on them if they’re to be used for dependency injection. At this point I’m not sure of a situation where you need multiple components of the same type, so I may move away from this in the future and simply enforce a mandatory uniqueness rule.
I also have an OptionalAttribute that can be placed on a property if that dependency injection is optional. If a property has the OptionalAttribute and a matching component can’t be found, it simply leaves the property alone rather than throwing an exception.
All in all I’m pretty happy with it. Still more work to do, but it’s certainly getting there. One thing I’m planning to work on is an “Entity Editor”, which is going to be some sort of WinForm app (or Visual Studio add-on if I ever get learn how those are done) that lets you visually design components and entity blueprints that you can then use in game.
As with all my code these days, the entity stuff can be found in my Apollo repository. Again, the code is under the “do whatever with it, but don’t blame me if it breaks and it’d also be nice if you credit me” license. And again, there are classes in there that are very much works-in-progress so if you see something that looks like it doesn’t do anything, isn’t used, or doesn’t work that’s probably why.
