Jeff On Games

Today I realized another thing that went wrong with our GGJ product, that I felt needed sharing.

1. Starting At the End: This one is twofold. First, we spent a lot of time working on the end boss battle of the game, which, while awesome, had to be integrated with the rest of the game at the end of the jam, mostly in the last hour. The core mechanic of the game, the destruction and rebuilding of objects, suffered as a result. Second, when the game was pitched, I included a portion "at the end" where it turns out you're a horrible person for destroying the world. We never got to this because the game took precedence.

Basically, I've found that almost any game jam game that has the words "and at the end of the game" never gets to that point because developing the core mechanic and building gets in the way. And if you need the end of the game to keep with the theme of the jam, you're going to end up breaking theme.

I will say in defense of my team that it was mostly me talking about the "end of game" theme. Amanda pretty much spent the entire time telling me we wouldn't get to it, so this rest squarely on my shoulders.

In the end, I don't think Quest For Stick fit the main theme of the Jam (deception), but I think the core mechanic was awesome, and I'm happy we decided to make it instead of making something that would obviously fit with theme.

Last weekend, I took part in the Global Game Jam, like I did last year and let me say it was just as fun, if not MORE fun this year than last. Our game, Quest for Stick, was really, really awesome this year, and you can learn more about it from the GGJ page and from our Twitter account. We even have a video of a complete play through of the game. The game is super pretty, only a little bit buggy, and generally I think accomplished everything we wanted.

But this year I went in knowing what to expect. How'd I do this year? What did I learn?

What Went Right

1. The Team. Last year, I said one of the things that went right was having a team. This year, that was even more so. We had a total of 7 people working full time on the game, which, initially, I thought was way too many. So much so that I actually asked people to leave the team and considered leaving the team myself to reduce the number of people. But, when it came down to it, I decided I wanted to work on the game idea and went with the other 6 people to create the game. Honestly, 7 people may still have been too many, as communication and tasking did get hard near the end of the project, but there's no way the game would have been anything near what it was if we didn't have at least that many people. Everyone was basically tasked the whole time, and the game came out great because of it.
   
2. Getting Down To Business: We spent very little time talking design this time, which worked out to our advantage. Although we spent a lot of time later arguing about how exactly the game was going to play, it didn't take away from everyone working, which was good. We got down to making something playable quickly, and didn't try to design too much stuff up front.
   
3. Tools choice: Last year, I was super happy with XNA. This year, the team used AngelXNA, even though I was the only one familiar at all with it, and I was the really the only one well versed in XNA. Even though I spent a lot of time helping people understand Angel / XNA, it was still, by far, better than attempting to use only XNA. It performed a lot of the heavy lifting for us in terms of doing animations, placing and managing actors, and, surprisingly, editing levels, though this is its own bullet point.
   

What Went Wrong

1. Unclear tasking: Occasionally, we got duplicated work or weird moments of down time because, like most game jams, people just shouted out things they needed. Kate was really the only person keeping track of most of these tasks, and really only for herself. For the artists, no one was really in charge of knowing what art was still needed and who was doing what. For a team this large, what we needed to create and consult a list on a whiteboard or cork board that had any asset requests, who was potentially doing them, what was in progress and what was up for grabs. This would have avoided duplicated work and would have given us an idea of how much work was left.
2. Late Playable: Despite my work to prevent this (more on this later), we still didn't end up with an actual playable game until mid day on the last day. Just having *SOMETHING* sometime on Saturday to hand to the artists and designers to make levels on would have helped. We did have lots of pieces that worked, essentially, but didn't get them integrated together fast enough.
3. Encapsulation problems: We had three programmers working together on individual parts of the game, which helped not only keep them tasked without stomping on each other, but made it so people were in charge of very small systems. However, some of the systems were weirdly encapsulated, and required copying and pasting over when we actually got to the point of integrating. Though this actually ended up *helping* at the very end, I would have liked fewer instances where I had to copy and paste the code from one class to another in order to integrate a new system into the main game.

What Didn't Work

So, these things really didn't go wrong, but they were things I was hoping would help us during the jam, but didn't.

1. The Simple CI: Before the Jam, I wrote a simple python script that would query a mercurial repository, pull down new code, build it, copy it up to a network location, then message everyone over gchat. This was awesome in theory, but not so much in practice for a few reasons. First, it didn't work so well. If anyone was signed out of gchat when it went to message them, the CI would get stuck in an endless loop. Second, the network drive would occasionally flake out and not be able to take the new build. Third, we didn't have anything the team could play until Sunday, so the CI ended up being useless until then.
   
2. The Angel Editor: The editor in Angel was an awesome idea, but when we got to the Jam, it was buggy and untested. It didn't save out things correctly, crashed, spawned items in weird places, and didn't work at all with our custom actors. In addition, the editor saved all levels out to the build directory, which was great for everyone but the people who were using it. Besides fixing the other editor bugs, in the future, the editor will probably need to detect whether a debugger is attached, and figure out where to put the levels from there, or create a custom levels folder that can be easily moved back and forth and through to an integratable build.
   

All and all, an awesome Jam. Please play Quest for Stick, and let me know what you think. I'm super proud of it.

I just pushed a new feature to AngelXNA which integrates a very simple (and currently fairly dirty and incorrect) lexer / parser into the console. The nice thing about this lexer / parser is that it allows the Angel console to now track C# objects, instead of just strings. In addition, you can bind various properties and methods of those C# objects to be console callable, which has made actor and level definition pretty easy to do in the new versions.

Here's an example of the old Angel adf files:

ActorFactoryInitializeActorClass PhysicsActor
 
ActorFactorySetColor 0.5 0.5 0.8 1.0
ActorFactorySetSize 3 3
ActorFactorySetDensity 0
ActorFactoryAddTag maze_wall

Each of these was marked with the [ConsoleMethod] attribute bound to their singleton via reflection. It was cool, and it worked, but here's the new system:

ActorFactory.InitializeActor(PhysicsActor.Create())
 
Color = Color(0.5, 0.5, 0.8, 1.0)
Size = Vector2(3, 3)
Density = 0
Tag("maze_wall")

In the back end, ActorFactor.InitializeActor and PhysicsActor.Create are static methods on C# classes, marked with [ConsoleMethod], and the Console class automatically finds them. Initialize actor has an implicit "Using" which means that the object passed to it is the subject of any calls until an EndUsing (or EndActor). So, in reality, the new adfs are shortcuts for console scripts that would look like this:

ewActor = PhysicsActor.Create()
 
newActor.Color = Color(0.5, 0.5, 0.8, 1.0)
newActor.Size = Vector2(3, 3)
newActor.Density = 0
newActor.Tag("maze_wall")
 
World.Add(newActor)

Each of the calls to set actor properties (Color, Size, Density, etc.) are all just properties on the C# Actor object, marked with [ConsoleProperty].

What all of this means is that if you want a class that's accessible from the console and has properties and methods you can call here's what you do. First, create a class that has methods and properties that you want console accessible tagged appropriately, like so:

public class MyConsoleClass
{
     public MyConsoleClass()
     {
 
     }
 
    [ConsoleProperty]
    public string Name
    {
        get; set;
    }
 
    [ConsoleProperty]
    public string Value
    {
        get; set;
    }
 
    [ConsoleMethod]
    public string GetMyInfo()
    {
        return String.Format("{0}:{1}", Name, Value);
    }
 
    [ConsoleMethod]
    public static MyConsoleClass Create()
    {
        return new MyConsoleClass();
    }
}

Second, compile and run you AngelXNA application. It will automatically detect your new class and allow you to now issue the following commands in the console:

myVar = MyConsoleClass.Create()
myVar.Name = "My Name"
myVar.Value = "My Value"
Echo(myVar.GetMyInfo())

So, that's pretty cool! The whole system needs work, as it's fairly dirty. The execution / parse tree can't handle chaining right now, so commands like myVar.Actor.PerformAction() won't work. In addition, there's a lot of boxing / unboxing of values going on, and some wonkyness where the console works mostly in floats. I'm not sure how much of this I'll have a chance to correct, but hopefully much of it as we move forward.

In addition, this whole system needs documentation on our wiki. If you want to help out please let me know.

Lastly, Ian Bogost and Borut Pfeifer have pointed out (via twitter) that AngelXNA definitely needs to be more user friendly to start with. As Ian said, we need things that " will help people get started' and "help them get up and running" quickly. Borut pointed out we may need more screens for the Intro game to explore a lot of the features, but I'm thinking we need more than that. For people that have tried Angel / AngelXNA, what keeps you from starting work quickly? What's confusing? How can we improve the experience and get you working on prototypes quickly and efficiently?

Thanks to a lot of help from Darren, today we're officially announcing the release of AngelXNA 1.0. For those that don't know, AngelXNA is a port of the Angel prototyping engine made by EALA and released open source not too long ago. The justification for making a C#/XNA version is that I, personally, like working with C# more than I like working with C++, at least when I'm trying to do prototypes. C# allows me to program faster and worry less about things like memory leaks, memory trashing, and weird side effects. By utilizing XNA, we get a lot of stuff for free, including input handling, sound, and music handling, along with the possibility (though it has not been tested) or running prototypes on the 360.

The interesting thing about creating / porting Angel was a question Darius posed to me while we were working on it, which is this: were there any decisions we'd made about the design of Angel that favored simplicity of creating games over speed / efficiency? Did we do anything that we wouldn't do in an actual game engine, just because it made programming games simpler? It\'s a pretty good question. Certainly, neither Angel nor AngelXNA take advantage of memory optimizations like object recycling or pooling, and there's no inline optimizations in AngelXNA. In addition, we didn't optimize any of the rendering or animation systems by doing things like pooling similar objects together, and AngelXNA ends up opening SpriteBatch blocks a bit more often than it should. But the question is could either version of Angel be optimized this way and still keep the same interface? It's a pretty good question, and right now I'm not sure. Regardless, I think AngelXNA is pretty easy to develop on and runs fast enough to make it a pretty nifty prototyping system, so at least that part is a success.

If you'd like you can grab the v1.0 tag from our bitbucket site (zip direct link), and Darren did a great job of creating some initial documentation on the wiki, so please check it out and tell us what you think! Darren and I (and anyone else who\'d like to contribute?) will be looking at moving on to version 1.1 soon, which should include some simple pathing using A* (something that\'s in the original Angel) and some other simple AI.