September 29, 2008


It's about time I start writing about my latest project. I had intended to get started with 3D stuff, but the idea behind Meridian came to me just a few days before returning to school, and I was excited enough about it that I couldn't wait.

Meridian is a turn-based strategy game with a space combat theme (obviously, my favorite setting). The majority of the game takes place moving fleets around on a hex grid board. When two fleets meet they trade attacks until one side is destroyed or decides to retreat (which salvages almost all ships). Larger fleets will typically have the offensive advantage, but small fleets can conduct hit-and-run attacks.

Each player also has a set of solar systems. Conquering the other player's is the game's ultimate goal. Each system produces a certain number of ships every 5 turns. However, players may sacrifice 1 ship-per-turn in exchange for a large one-time bonus of ships. Therefore a player can get the advantage in the early game but be repulsed by a swarm of new ships. The natural response might be to create an equal number of ships, but this would cede the hard-earned production advantage.

Meridian is being programmed in C# using XNA. I've found it to be quite clean, and I'm loving Visual Studio. I don't much miss Java. I'm a bit more than halfway done right now. Fleets can move around and attack each other, and most of the graphics stuff is where it needs to be (though some of the art will be getting an update). Interstellar travel and capuring of solar systems has yet to be added, and getting a decent AI running may be a challenge.

Further updates to come...

September 23, 2008


I'm pleased to announce my latest game to the throngs that have undoubtedly been waiting for it. Doublecross is a card game that's designed to set up a constantly uneven battlefield between the players. The game rules set up a web of relationships that attempts to keep everyone scheming and negotiating.

Each player starts with all the cards of one suit. Each card is worth a value equal to its number (face cards are 10) that can be played, once a turn, against any one other player. The goal of the game is to have the fewest points played against you after all cards have been played.

It gets interesting with the addition of a card-trading phase between each turn. Players can exchange one card a turn, and playing certain suits against certain players counts double against them. The game is set up such that the one player who has the most valuable cards (to you) can't trade with you; you have to get his cards through the other players. The result is that every player is constantly balancing his relationships with two others.

I only got the chance to playtest Doublecross once, with a group of friends at my summer camp. A single round of the game took the better part of an hour to play, surprisingly. That's mostly because there was plenty of scheming, as I had hoped. After about 8 cards had been played per player, the two sides were mostly set in stone and it was simply a matter of playing the rest of the cards. Reviews from the players were divided. Two of us loved it and two of us were ambivalent. One of them stated that I had obviously designed the game for myself, since I so love deceit in games (see Balderdash and the diplomacy in Risk). It's true, and I take that comment for a good sign.

I'd love to playtest Doublecross some more and continue to iterate, but it's proven difficult to get together three other people to play a card game that none of them know. I'll work on it.

September 13, 2008

Asp Evaluation

Asp offers a new type of tactical core gameplay. It's easy to use, well-constructed, and pretty enough. Now for the negatives.

The art is primitive and shows it.

The tutorial is nice, but I'm ashamed that such a small game requires one.

The randomized skirmishes are usually imbalanced, since the initial placement of forces is random and it's difficult to account for RPS-style strengths and weaknesses of each side.

There's no sound.

And worst of all:

The interest curve is messed up. Action is highest on the first turn, then rapidly decreases. By the end, the player might spend half a minute or more watching his ships turn in circles trying to kill that one last enemy ship.

September 12, 2008

Asp Design Retrospective

Thanks to a summer spent at a wilderness camp with little access to computers, this post is coming quite late. I'll recall the best I can.

The core gameplay from Asp had previously been tested in the game's older prototype, Squadron. This prototype had been quite popular in the ol' high school computer lab, so I was excited to finally flesh it out.

I knew that it would be important to offer very different types of ships in order to give the game tactical depth. Fighters formed a core of the fleet, a base by which to compare other ships. Bombers were an obvious choice; they would be weak, but extremely powerful. Small, fast ships (which were referred to as "scramblers" inside the code) seemed like a cool idea, and they turned out to be useful in-game for their mobility.

As I played the earliest builds of the game, the general tactical approach that I could offer started to emerge. Distract and attack is the basic formula. The Carapace creatures (internally called "Resilient" ships) were included almost entirely to facilitate this strategy.

I made balancing the game easier for me by making the two sides' ships unequal. Since I didn't have to rely on an AI to be as good as a player, I could set up the enemy to whatever strength or configuration was fun. The human forces are thus more powerful offensively, but the AI dictates that they aggressively pursue closer targets and ignore the ones that might be doing more damage.

Since the AI's behavior is mostly dictated by the initial proximity of the player's ships, I discovered that the layout of the levels (i.e. which squads started where) was exceptionally important. A level could change from trivial to impossible just from the movement of a squad's starting position by a hundred pixels. This turned out to be a blessing; the campaign levels could be adjusted such that a smaller player force could destroy increasingly large enemy fleets.

When setting up the campaign missions, I did a lot of testing on my own. I developed a series of requirements that I employed before I even considered using a level: Could I win without giving any orders? Could I win by ordering all of my units to attack the enemy at one spot? Could I win by having each of my squads attack each of theirs one-on-one? Is it possible to win by using a planned, thoughtful strategy? While these tests ensured that the levels were winnable and not trivial, I worried that they only offered one solution (the one that I tested).

This worry abated when I started playtesting and found players discovering wholly new solutions to the missions I had set out. However, some players had a tendency to create elaborate 40-waypoint formations each turn that inevitably backfired, and all complained of performance and UI issues (e.g. not being able to right click to select a squad).

Aside from the usual minor changes, I made one major revision to the otherwise finished game in which I fixed the performance problems (see the Engineering Overview), added new UI elements, and replaced a terribly cluttered Help screen (see below) with an interactive tutorial that discussed basic tactics. I'm satisfied with the final result, but that's not to say that I don't see any flaws. I'll discuss those next.