Jeremy's Blog

We’ve been giving a lot of thought to our choice in Programming Language for Journey of Souls. For a while, it was starting to look like we were going to end up writing everything in PHP or Python. I think we’ve made our decision (or at least are very close). It ended up coming down to a few things that PHP and Python just don’t have any out of the box support for. Things that it would be extremely stupid for us to roll our own implementations, when another language offers the feature up really well. The first of these being Events and Event Handling. The second being a way to write game scripts in a way that they can be replaced on the fly while the game is still running. Here’s some of the details from our research and decisions.

Event-driven Programming

A topic of discussion that came up during tonight’s book club pseudo-session was using a more event-driven process to control the flow of the game. We believe we would prefer a lot of interactions to be based on events, as that’s how we conceptually see them. That brought us to a head with our language choices. PHP and Python currently have no built-in way to handle events. We would have to roll our own implementation. Considering the scale of the project we’re planning to put together, those are resources and cycles that we just can’t afford to give up. We just didn’t believe that either language would be capable of managing a full-on userland Event Management implementation as well as everything we actually wanted to do in the game itself. The two languages were already fighting an uphill battle to stay on our radar, but tonight’s realization pretty much doomed them. Sort of.

C#, IronPython, and the Dynamic Language Runtime

That sort of brought us down to the two options that we were sort of avoiding up to this point. Not because we’re not capable in either or because we have any particular gripe against them, just simply because we believed we could get more done faster in PHP or Python. The two options I speak of are C# are Java. Well, the heading above this section sort of gives it away, but we didn’t pick Java. Not having any experience with it personally, I’ve heard a lot of bad things about Java’s event model. While I have personal experience with C#’s event model, and have heard a lot of good things about it. Not to mention the fact that I have some good things to say about it, but that’s sort of beyond the scope of this post.

That solved one of our two problems, but C# is a compiled language. If we need to make changes to the game, that’s going to require a recompiling and stopping the game to drop in the new binaries and … wait a minute. I remembered the DLR. Not only did I remember the DLR, I remembered that the languages (IronPython, specifically) can be embedded. Meaning, we can do our scripting for the game in IronPython, and it offers us up the opportunity to do nifty things like reload game scripts at runtime. This is absolutely amazing because it minimizes downtime for the game, in the long run, and allows us to immediately add new features and such to the game without a restart. It also still lets us do a lot of stuff in one of our preferred languages, while still being able to utilize C# for any heavy lifting that needs to be done.

In my mind, this seems like a very win-win scenario. We’re going to be future-looking, so I’ve already been considering the use of things like C# 4.0’s dynamic keyword for making interacting with IronPython that much easier. It also helps that I’ve already been using the Visual Studio 2010 and .NET 4.0 Betas. We still have a long way to go before we get something usable, but locking down our language choice is a huge milestone and an issue that’s been bothering us for a long time now. With that gorilla off of our back, we can start working more on the actual design of the game and how we want the core pieces to interact, knowing that we have an Event model that’s built-in to the language we’ll be developing in.

I’ll keep the updates coming as we have more things to share.