09
09
Dec 2013

Scourge, Part V: And Miles To Go Before I Release

Wherein the pendulum analogy completely breaks down

Hello, I’ve returned. No, I didn’t forget to blog– I’ve just been busy. How busy, you ask? Well, Scourge now runs on Flash, HTML5 and on native targets, and on top of that it looks super great, so, pretty damn busy.

Scourge on Flash
Scourge on HTML5

It doesn’t look like much until you type in the “makeGame” command. If you follow it with a number, or with the word “circular“, you can see the game “running” with some slightly different parameters. I suggest this one:

makeGame 4 circular

Anyway. How exactly has Scourge changed in the past eight months? [ More ]

No Comments
03
03
Apr 2013

Scourge, Part IV: Kneel before Quad!

the pendulum has swung back to graphics

I’ve realized recently that Scourge’s client has many layers, and jotting down a list of those layers helps maintain my perspective of the work yet to do. Distinguishing layers is an easy activity – if System A connects to System B, and A can invalidate B, but B cannot invalidate A, then A is a layer above B. That’s helped me identify the following layers, each of which has its own problem space:

  • Server connection – are we online? (HTTP/UDP comms)
  • Session – are we authenticated and up to date? (user object)
  • Battle – who are we fighting and what actions can we take? (the ROPES)
  • UI Narrative – what action/data is the player considering? (narrative tree nodes)
  • View – What does each button and view component look like? (view objects)
  • Renderer – What does each particle look like? (glyph objects, model arrays)
  • Graphics – What does each pixel look like? (GPU buffers, write-only)

And that’s only the stuff that’s going into the demo! I left out the AI stuff from this list, because like the state of the human player, it interacts with this layer cake at some level. It’s just a higher level than the one human beings interact with.

Anyway, while I’ve spent a lot of time focusing on the Session and Battle layers in the past, for this post I will focus on the Renderer and Graphics layers, which I’ve been working on for the past three months. They’re only a piece of the puzzle, and currently the Graphics layer is dependent on Flash and Stage3D, but that’s a small price to pay for the ability to work this stuff out while I wait for Haxe 3, H3D and NME’s OpenGL features to stabilize. (As I’ve previously mentioned, Scourge should be able to target every platform that one can target through NME, which is quite a lot. The graphics pipeline just needs to mature a little. I will color your pixels!) [ More ]

No Comments
14
14
Jan 2013

Using Haxe to Solve Problems

it's not polite to point

The most fun thing about programming in Haxe is just messing with its power. Its compiler is fast, there’s support for some sweet macros, there’s compile-time types that dissolve at runtime, there’s Iterators and Enums, there’s inlining, there’s metadata… and let’s not forget that this language compiles to multiple targets, and does a damn good job at it!

Of course, you shouldn’t use these features for their own sake; you should only consider them when you have some problem that they solve. For instance, if you’re manipulating vertices on a 3D mesh, you might feel compelled to throw some helper functions into your Vertex class, but for the Flash target, this increases the memory footprint of a Vertex instance. With the using mixin, you can write a class of static utility functions that pretend they are methods on Vertex. That’s what using is for- separating sets of methods from the data they operate on, while keeping the syntax simple.

But don’t do that just because you can.

The ROPES recently presented me with an interesting problem: how can we represent memory addresses in Haxe? The ROPES’s internal data structure consists mostly of Arrays, and I wanted two objects to exchange a reference to an Int within an Array, rather than its value. Haxe belongs to a family of languages that don’t support references to primitive types; they are always passed by value. What to do? [ More ]

No Comments
13
13
Jan 2013

Scourge, Part III – the ROPES

Solid foundations

Scourge is a complex game, and programming its model involves accomplishing several tasks. Starting out, I wanted to separate the game concepts that are specific to Scourge from the concepts that form the underlying structure of a strategy board game.

So! What makes a good model for a strategy board game? By “good” I mean, “offers a representation of the system it’s modeling that best facilitates reasoning about that system”. I want views, net protocols and computer opponents to be relatively easy to map to this thing. So here’s the list of criteria that I came up with:

  1. Each player decision must be explicitly represented : rather than leaving it up to players to discover what options are available to them, the model should create options from the state that players may then evaluate, compare and choose from. This limits the role of an AI to purely strategizing, and reduces the amount of code that a player relies on to reason about a particular rule. (I could technically write a functioning AI that performs no rule-specific reasoning about its decisions, relying solely upon a coarse estimate of the board’s value. I think it makes for a good starting point!)
  2. A traversable decision tree : we can couple the aforementioned player decision generation with a rewindable history object, so that players can climb up and down the decision tree like a rock climber on a climbing wall, moving from handhold to handhold, trying to reach a goal position.
  3. Dynamic rules : there are games with many, many rules, with each one applying to a particular context. If the game is being played in a context where a rule never applies, then the game model should not represent that rule computationally– after all, it will never contribute to the available options to a player.

[ More ]

No Comments
05
05
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. [ More ]

No Comments
Older Posts