Jan 2013

Scourge, Part II: The Project Gets Personal

new opportunities present new challenges

So Scourge had this hiatus, during which I just didn’t have the chutzpah to tackle the problem of designing a game with AI and network play features. Briefly in late 2011 I looked into writing a new View for the prototype, which simplified the GUI considerably and made interaction on touch devices more straightforward, but I put that work on hold as I started to scope out the rest of the project. Let’s face it– views are interesting, but for a game like Scourge, their design needs to take a back seat to the core functionality. I’d have plenty of time to design a view later, when the rest of the game was functional.

So I started asking some deep questions. Why was I even doing this project? Obviously it’s one of those side projects I regularly work on for the sake of revitalizing an old idea; some pretty game or application from a simpler time is no longer widely available, and I have the skills to bring it back. Classic Jeremian time-waster.

Aside from that, though, Scourge is a chance for me to build something new and creative on top of something familiar. Even if you’ve never played Fungus before, I have faith that you’ll like the core gameplay, once there are opponents to play against. That gives me a platform to propose further design challenges and to pursue really ambitious goals, which I can learn a lot from. I’ve boiled those ambitions down to this list here:

Cross-platform implementation
This is crucial. In case you weren’t aware, there’s a war on; my career, and the careers of a lot of other programmers, now depend on platforms that are locked in a kind of deathmatch.

Doesn’t sound stable, does it? Most devs are content to choose a favorite platform, and to focus their efforts on producing solutions for users of that platform, ignoring all others; that sort of narrow-mindedness leads inevitably to wasted effort and lost insight when that platform loses its support. Fortunately, I’ve found Haxe, a powerful, free language with a strong community that compiles to many different target platforms, with more targets being added year by year. As long as I can identify and manage the areas where each platform’s API diverges from the others– not a simple task, but an interesting one– Scourge’s codebase shouldn’t be affected by major platform upheaval.

Hardware accelerated graphics

When Haxe was first developed, most of its target platforms had no support for hardware-accelerated graphics. This is one area where the conflict between platforms has benefitted programmers– in order to remain viable, lots of platforms have been innovating like crazy to keep up with one another, which includes the introduction of OpenGL-like hardware accelerated graphics APIs. I mean, before WebGL was taken seriously, 3D graphics on the Flash platform were kind of a joke– it was all done in software, and as soon as you tried doing anything ambitious, the framerate would plummet on all but the fastest machines. Compared to the Flash’s 3D API today, we were practically living in the dark ages.

Nevertheless, plenty of work remains to be done in order to get Scourge up and running with these APIs. Each platform’s OpenGL-like API is slightly different, but Nicolas Cannasse, the main programmer behind Haxe, is working on a library that should unify those APIs. Since I’m only using hardware acceleration for rendering views, this aspect of my project can bide its time.


Or, as I like to call it, “opting for a stick up one’s ass”.

Free and open source software is a neat idea, and if you want a FOSS license, there are a lot of options to choose from. If I wrote my own license, it would probably look like MIT’s– straightforward, permissive and generally friendly. GNU’s GPL3, though, has teeth: if you distribute a program that uses software that’s GPL’d, you have to release that software’s source code, licensed under GPL. It’s a license designed to spread as extensively as the ideas licensed under it, and it comes across as a clever hack of copyright law.

That’s pretty neat, but it makes me uneasy; after all, the medium that the license spreads through is programmers’ choice of license. The GPL can be imagined as an advancing wall of restriction; you are either outside of it, using a license incompatible with the GPL, or you are inside of it, free to use the rest of the GPL’d software but inaccessible to those outside. Add to that the fanatical tendencies most GNUsers express regarding the “evil” inherent in all software projects not licensed under GNU, and you’ve got yourself an ideologically charged, infectious software movement.

And yet I’m licensing Scourge (for now, at least) under GPL3.

The way I see it, as a game platform developer I have a lot to benefit from the enforced reciprocity of derivative works. Whoever writes Scourge-Prime will probably have some neat ideas that hadn’t occurred to me, and I’ll be free to absorb them into later versions of Scourge. Furthermore, the platforms I’ll be building on, being free and all, could probably benefit from the publicity resulting from releasing Scourge’s source code. There are probably many other benefits that I haven’t considered, but those are the two that I’m most interested in. Besides, the disadvantages of GPL3 that I’ve mentioned don’t have much of an effect on Scourge-sized projects- I’m not exactly engineering an operating system here.

Network play

Most of the Fungus clones released after 1992 support multiplayer gaming over a network. After all, it’s a lot easier to face the wrath of your frustrated opponent when they’re miles away! For Scourge, I’ll be building a server app that’s capable of supporting multiple games at once, validating the input and chat messages from a myriad of players and spectators, storing logs of their games and maintaining a high score. For some compile targets, the server can be integrated into the same executable as the client, which will help establish small multiplayer groups; however, it’s more sensible to offer a main Scourge server that most players will use when they play against each other. This prevents cheating, and gives players more meaningful rankings in the high scores lists. Maintaining that server will be an interesting challenge.

For the server code, I also have the option of using HTTP or RTMP messaging protocols. While HTTP is simpler, its design goals are to request and receive web pages, not real-time game data. RTMP allows the server to push information directly to the client, so I don’t have to regularly poll the server for updates during a game. I’ve only barely scratched the surface of this protocol stuff, but I’ve got a solid Haxe solution for each one.

Story mode

All the previous Fungus clones pick an obvious backstory– that you’re a specimen in a lab that must compete for nutrients, and will one day overrun the entire planet. I always felt that this premise was just a stapled-on backdrop, and that here was a chance to tell a unique story about clever, ruthless creatures placed in a desperate situation, with little to no knowledge of the world and all the ambition they’d require to conquer it.

One of the first things I did after prototyping Scourge was to keep a small document detailing story ideas. There’s no guarantee that I’ll use any of it, but working with a narrative while programming has given me a kind of rough target for the requirements of the system upon which Scourge is based- a system I’ll go into further detail about in my next post. Without giving away any spoilers, I’ve decided that adding a few new game mechanics (which deserve another future blog post) will give whatever narrative I settle on a little more leeway.

Software opponents

The main reason why I stopped work on the prototype in 2011 was because it wasn’t adequately prepared for AI, and neither was I. The basic architecture of a game can make AI slightly easier or significantly harder to layer on top, and only once I gained familiarity with entity systems at work did I have any sort of strategy for an AI-accommodating design.

Lots of what a software opponent does in strategy games like Scourge is to dig into the “probability space” of the game, searching future possible game states for an optimal course of action. Functional programming languages such as Haskell can easily express recursive processes like a Scourge AI, but there is no obvious way to target the platforms I intend to target from Haskell. Furthermore, Haxe is a language that I feel more people would be willing to work with if Scourge gains any attention from the open source community. And while Haxe is technically a functional programming language, the runtimes it targets often pay a high penalty for allocating and deallocating objects in a small timeframe (which most FP implementations rely on).

Instead, I’ve opted for a mutable, rewindable game history that an AI can use to explore the probability space without major side effects. As each player has a perfect copy of the rules, the AI can use them to transform their internal game history and probe the outcome without affecting the state of the actual game.

A flexible rule system

Inspired by entity systems I was exposed to at work, Scourge’s rule system encapsulates each rule of the game, so that complex changes to the game’s state are reduced in their extent as much as possible. After all, it is much easier to work with two small rules of medium complexity that operate sequentially than to debug a large rule composed of both rules’ functionality. Their modular nature also makes it trivial to add new rules to the game. I’ll discuss this system extensively in my next post.

Unorthodox level geometry

Fungus is essentially a digital board game. It can be played with a physical board, but it would be tedious to move all the pieces around. But it’s still basically a bunch of rules that apply to a square grid.

I didn’t want to impose this same limit on Scourge. While the game does require a grid, it isn’t necessarily Euclidean. I intend to design game levels whose grids overlap, curve or twist; therefore, it made more sense to represent the grid as a series of interconnected nodes, rather than as a continuous surface. By providing utility functions for traversing such a graph of nodes, I’ve been able to keep geometry-specific logic out of the rules that operate on the grid.


Most of these challenges have already sprung up, and I’ve taken them head-on. Scourge’s underlying game rule engine, the ROPES, is a Haxe tour de force, providing cross-platform, AI-friendly gameplay for grid-based games. I’m about to build my first view, which will use a text interface, but will help me scope out the complexities of the more ambitious forthcoming UI. The story is waiting in the wings. And the code is entirely under GPL3. And this is only the beginning!

You can leave a response, or trackback from your own site.

Leave a Reply