Upcoming Talks

Just to keep people in the know, I'm giving two talks in the coming months. The first will be at Games Forum Germany (site is in German, obviously, thought the talk will be in English) on either January 27th or 28th, I don't really know which. The talk is titled "Data Driven is Half the Battle" and will be talking about why just setting up data driven code isn't enough, and how (both from a high level and a low level) you can create a system for giving others on your team the ability to edit your data quickly and easily.

The second talk will be at GDC, as part of the Game Career Seminar, which takes place on the Friday of the conference and is focused at students. That talk is called "From College to Industry: 20 Lessons for Getting the Most out of your Early Career" and is about, well, getting the most out of your early career. It is basically a lessons learned talk about my 10 years attending GDC, and my 6 years in the game industry. While that isn't a really long time in the game industry (anymore), I feel that some of the lessons I've learned over that time will only really be apropos to students for a short time, and thus it is most useful for me to give the talk now, when it will be most useful to them. I will be practicing this talk twice in front of student groups around the Boston area, once at WPI and once at a local SIGGRAPH meeting, to make sure that the talks really hit all the right notes and lessons and are as useful as possible to the GDC student population.

Both talk's slides will be posted on line after the talks, and the GFG talk will probably be cross posted to the Toolsmiths, since it is a tools related talk.

Immigration Jam Post Mortem

This past weekend was the Boston Immigration Game Jam, and like previous Jams, I'm going to do a quick post mortem about my experiences, not only because I think it will help others, but because it will help me as I prepare for my next game jam. For this Jam I was in a team of 5 on day one, which included 3 musicians, which later went down to 4 when two of the musicians decided to not show up for day 2 and one new programmer joined the team.

The game we ended up making was called "Cultural Exchange" and was supposed to be about managing a country, trying to attract the "right" sort of people while keeping out undesirables. To do this, you would enact legislation to make your country more appealing to some people, and erect fences and the like to keep out undesirables. However, people in the country wouldn't like things being too restrictive, since they value their freedom, so it was a constant balancing act.

Now I know normally I start with what went right at the jam, but this time I feel what went wrong is more important. So here we go:

What Went Wrong

  1. Not having a clear idea: While the description is fairly clear, neither me nor Kevin had any idea how we were going to get it working. We didn't actually get anything designed until very late in the night, and even that was just kind of border-line. Since we didn't have a clear idea about how the game would play, we had no idea what our restrictions were.
  2. Using Flixel: Now, no offense to Flixel, but I was not impressed with my first outing with it. This is partially linked to not having a clear idea of what we wanted to do, and not having a clear understanding of the limitations of Flixel. I spent 90% of the first day fighting with ActionScript and Flixel, not only because I didn't understand Flixel's limitations, but because Flixel has some issues with transparency, some of which it inherits from Flash. I spent at least 3 hours trying to move some buttons off screen, only to throw up my hands in frustration. In addition, we were using FlashDevelop, which does not have a debugger included for Flash, which made dealing with all the problems that much worse.

    I took 3 learning points out of my Flixel experience, which don't actually relate to Flixel at all:

    1. Always use something you're familiar with for a game jam, even if it's not the best tool for the job.
    2. Constrain your idea to what you know is possible in the tool you're working with.
    3. Do not take platform into account. If you really like your game after the game jam, you can always port it to a different platform.
  3. Too big a scope: Out game had way to big a scope for our time frame. There was just no way it was getting done.

What Went Right

  1. Switching to AngelXNA: At about 10 on Saturday, I switched all of our code from ActionScript to C#, and all of our Flixel code to AngelXNA. I was too pissed with Flixel's limitations to deal with learning how to get around them, whereas I knew the limitations of Angel really really well, and I could get around them very quickly (see point 3a). Even though this meant losing a programmer on the project, it still ended up well (see the next point).If nothing else, Angel, I've realized, is EXTREMELY transparent. I find pretty much everything does what you'd expect. That said, getting started up in Angel is hard, and I do need to do some tutorials for it in the near future.
  2. Having a dedicated designer: The second day, Kevin ended up doing only design. This was the ONLY way we actually were able to finish at all. Kevin ran through turns on paper, and looked into how legislations would affect the population on each turn. Looking back at other Jams, I think we could have done better if we'd had someone we dedicated as "designer" to look into these problems earlier, rather than playing it by ear the whole time.

Generally this was a short Jam, and I went into it already tired, so I wasn't super psyched about it. But I think I learned a little bit more about jamming, and some things I really want to add to Angel for the next jam, so keep an eye out for that.

Angel, New Features, Documentation?

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:

  1. ActorFactoryInitializeActorClass PhysicsActor
  3. ActorFactorySetColor 0.5 0.5 0.8 1.0
  4. ActorFactorySetSize 3 3
  5. ActorFactorySetDensity 0
  6. 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:

  1. ActorFactory.InitializeActor(PhysicsActor.Create())
  3. Color = Color(0.5, 0.5, 0.8, 1.0)
  4. Size = Vector2(3, 3)
  5. Density = 0
  6. 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:

  1. ewActor = PhysicsActor.Create()
  3. newActor.Color = Color(0.5, 0.5, 0.8, 1.0)
  4. newActor.Size = Vector2(3, 3)
  5. newActor.Density = 0
  6. newActor.Tag("maze_wall")
  8. 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:

  1. public class MyConsoleClass
  2. {
  3. public MyConsoleClass()
  4. {
  6. }
  8. [ConsoleProperty]
  9. public string Name
  10. {
  11. get; set;
  12. }
  14. [ConsoleProperty]
  15. public string Value
  16. {
  17. get; set;
  18. }
  20. [ConsoleMethod]
  21. public string GetMyInfo()
  22. {
  23. return String.Format("{0}:{1}", Name, Value);
  24. }
  26. [ConsoleMethod]
  27. public static MyConsoleClass Create()
  28. {
  29. return new MyConsoleClass();
  30. }
  31. }

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:

  1. myVar = MyConsoleClass.Create()
  2. myVar.Name = "My Name"
  3. myVar.Value = "My Value"
  4. 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?

Introducing the Toolsmiths!

So, if you haven't noticed, this blog has been a little quiet recently.  It's not because I don't have a lot to say, but because I haven't had the time to say it.  One of those reasons for that is because I've been spending a lot of time working with the IGDA Tools SIG (which I've talked about before) to launch a new collaborative blog: The Toolsmiths!

The new blog has two other great authors, Geoff from Insomniac and Dan from Robotic Arm Software.  I'm really looking forward to the content we'll have over the next year or so, and I hope anyone interested in game tools will take some time out to read our posts.

My first post, on continous integration and build systems, will appear on Wednesday.  Hope you enjoy the new blog!

Tools of the Trade

I gave a talk at Becker last night on tools in the game industry, which I called "Tools of the Trade." The talk and its slides are available here, and the entire talk should be in the slide notes. Generally, I'm pretty happy with the talk itself, though if I had to give it again there are a few things I would change, including removing some of the LOLCats. In addition, I think some of the points that I make about the problems with debugging tools actually applies to all tools, but in an attempt to split the talk into three nice sections, I ended up muddling things up a bit.

What I really hope is that the students actually got something from the talk. I'm afraid some of it may have actually gone over their heads, and portions of the talk may need simplification or better explanation. Hopefully they did get something out of it (and if any Becker students have decided to read my blog, I'd love to hear your thoughts!)