As one would hope, development has been coming along nicely. The game just entered into balance testing last week, so we can put the finishing touches on it. The client team has finished their rewrite of the client code generation system we use to update clients with game logic, and can now focus on new language bindings. If you’d like to see a new binding, just specify that on the registration page. The server team is wrapping up a tournament module that will allow us to run most of the end-game tournament in parallel, making the tournament much faster.

A couple more announements:

• The framework we use for the game is now open source, and published. Snag the code here.
• We’ve recruited more people! With two sophomore and three freshman developers, we now have 9 devs!
• You should follow us on Twitter!

If you have any comments or questions, leave them in the comments below. We hope to see you on November 7th.

Returning to the development team include myself, Steven Wallace, Stephen Mues, and Kyle Steinert.

With so many strong developers returning, we’re focusing on providing the most interesting and enjoyable tournament to date. From our previous games we’ve been able to abstract out a (rough) framework for the AI competition, allowing us to focus more on the game mechanics. Because of this, we’ve decided to pursue a theme that is rather ambitious, and hopefully allows us to express lots of creativity in the resulting game. This theme is time travel.

Set the dials and get ready to travel.

While the game mechanics aren’t completely finalized (and we can’t exactly share details due to the nature of the competition), the competitors will have to travel through time to defeat their opponents. The goal of this is to allow for complex strategies, while maintaining a low entry barrier for competitors. I like to think we’ve learned from our previous mistakes (see hex grids), and can make a great game for our competitors.

We hope to see you this fall. To keep up-to-date on our latest news, follow us on twitter here.

To alleviate the lack of information, we’ve updated the official page for the Spring 2009 tournament to include more information about the game – hopefully this will give some of our 50ish Monday visitors the information they wanted to know before committing to the tournament. If there are more questions, you can leave comments on this post and we’ll see if it’s something we can reveal, then update the official page if it is.

Finally, if anyone needs assistance finding a team, comment on this post or send an email to acm@mst.edu and we’ll help you find a team.

-The Developers

• Ben Murrell – Leader, Visualizer, Client
• Steven Wallace – Client
• Andrew Schrader – PR
• Stephen Mues – Server, Arena
• Josh Bohde – Server
• Brian Goldman – Testing, Balancing
• Kyle Steinert – Testing, Balancing

Also, an update on the progress of the game: We’re done! The visualizer works, the server works, and there are working clients for C++, Java, and Python! We still need to do some balancing of the game rules to make things fair, and I’m still making the visualizer prettier… and we’re doing some fine tuning of the API for each language to make sure that competitors have an intuitive interface to work with. Compared to past semesters though, we’re doing great and we’ve got a lot more time to work on the little details that usually get overlooked until the night before.

Paypal doesn’t work yet (should work within a week), but you can register with the cash option (pay at the door).

Either click on the registration link in the sidebar, or click here .

Why real time? True real time strategy games are more fun to watch. They reward faster / better performing players – with human players, we may not necessarily want to reward the fastest player; but with an AI, we want to encourage the development of efficient AI. Real time games map into our brains easily because we live in a real time world – we don’t determine how far we can move in a turn, then determine how many actions we can perform during a turn, etc. We think of things in terms of rates. I can  move 2 meters/second, I can type 60 words / minute.

Unfortunately, creating a real time game API for an AI is hard. It’s not just technically hard – it’s also conceptually hard to  introduce to someone and expect them to make something cool with it within 24 hours. We considered a few ways of providing an API for a real time game: setting up Qt-like signals or giving each unit its own thread were a couple. Unfortunately, giving each unit a thread doesn’t scale well (and it forces all of the concurrency issues upon the API user). The signal method sounds nice, but we haven’t investigated it yet.

The downside of a turn based game is that it’s harder to reward faster and more efficient AI’s. Since the other AI doesn’t get to move while your AI is thinking, you can take all the time you want. There is no reward for thinking and acting quickly, so as game designers we have to come up with a penalty for underperforming AIs. What this usually means is that if your AI is taking 5 minutes to complete a turn, you forfeit. When we finish the implementation of the current Zombie Survival game, we’ll probably spend some more time on this problem and see if we can find a way to fairly reward faster AI.

In a turn based game, we can convert the rates of a real time game so they all use a common time unit – in one hour I can type 3600 words or I can move 7200 meters. The problem is that in the games we have created, we let all actions draw from an action pool – each turn, a unit gets X actions. Some actions may cost more than others, but the unit never has more than X actions, ever (if units accumulate actions, then it would be possible to perform a low-cost action hundreds of times in one turn – since we’re in favor of keeping a simple API, we’ve avoided making fixes to this particular problem by adding more limits). The problem with sharing a common time unit then is that it’s hard to include some more complicated game mechanics or long term actions into the game.

To solve this, we have created what we call a fine grain turn based game. Say we want to build a boat. In a turn based game, we might wait until we have enough actions, then tell our unit to build the boat. If our fine grain turn based game, we tell the unit to build the boat each turn. Each turn, a little progress is made on the construction of the boat. By doing this, we’ve captured the “fun to watch” part of the real time game, but we still get the simplified API of a turn based game (which is necessary since we only run our tournament for 24 hours).

We’ve finally settled on a specific date,time, and location!

Coding starts:  Saturday, April 18th at 1:oopm

Coding Ends: Sunday, April 19th at 1:00pm (A whole 24hrs!!!)

Where: Centennial Hall 105

Check back for updates!

Development updates that I know of: Steven and Bohde have been working on the protocol for next semester – something with Domain Specific Languages and automatic protocol generation is in the works. Stephen is working on the game logic implementation, and Ben is mulling over OpenGL books