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.


No comments: