Game-a-Day Journal Archive

Only one tiny (important) difference from UnicornSlaughter

I recently received the following Game-At-Request from our friend Bezman: “I’d really like to play a version of the unicorn-slaughter game that is a perfect square, with dots hitting the ‘cross’ we can touch at regular intervals. I’m just curious to see if I could survive with ease in such a game.”

As was mentioned in the Gravibox entry, any change to a game’s systems or environment, however small, can have ripple effects across the game’s overall design. I have been learning the hard way lately as to just how those kinds of minute differences can affect a first-time player’s impressions. This last Wednesday, for example, I failed to mention the word “Shadow” in the 1-line title screen instructions for ManipuLie’ted, and I believe that omission cost me about 500 needlessly confused first impressions. Players wound up being offended for the wrong reason.

In the original UnicornSlaughter, the playing field was a rectangle, meaning that the horizontal and vertical crossing times rapidly fell out of sync, forcing the player to play two separate games at once. Within the context of this journal entry, I will be referring to that feature as rhythmically-disconnected-simultaneous-action, or RDSA for short.

Averaging the dimensions for UnicornSlaughter^2 into a square (from 600×440 to 520×520) - with absolutely no other changes to the game mechanics - severely affected the way that the game is played. The square playing field enforces consistent crossing rhythm, and allows attention to be focused on one task at a time instead of trying to keep track of both separately. In other words, UnicornSlaughter^2 does not utilize RDSA.

This high-level concept rarely sees mention, however it plays a very important part in how accessible (non-RDSA) or deep (RDSA` the mechanics are for many real-time games.

The enemy A.I. in id Software’s classic Doom is not as “smart” as A.I. in games since (including Doom 3), but it is much better designed than A.I. in most games since (also, unfortunately, including Doom 3). The difference has to do with the type of difficulty layering that separates UnicornSlaughter^2 from UnicornSlaughter.

In Doom, different enemies posed different kinds of threats to the player. Zombies with guns fired at regular intervals based on line of sight, and rarely missed. Imps threw slow moving fireballs - slow enough to dodge - and scratched the player if nearby. Demons had no ranged attack but ran quickly, and caused a great deal of damage up close.

Each enemy type, on its own, presented very little threat to the player. The tactical depth in the game was derived from recombinations of the AI enemies in different numbers within a variety of environments (claustrophobic, columns-ridden, winding, near lava…). The difficulty did not come from making any one enemy stronger, faster, more accurate, or more aggressive - it came from trying to do several otherwise simple tasks in RDSA.

UnicornSlaughter uses RDSA. In Doom terms, you’re stuck in a room with both a Demon and an Imp, which is challenging to a degree that it’s hard for a new player to ramp up to it.

Again to use the Doom comparison, UnicornSlaughter^2 is more like an early mission, in which one room presents a single enemy type, the next contains only one enemy type, and so on, ensuring that the player doesn’t have to juggle both types at once. By taking place in a square field, UnicornSlaughter^2 binds the horizontal and vertical challenges to a shared rhythmic clock, such that the player is doing one single task with two possible actions (easy), instead of tackling two tasks each with a single possible action (difficult).

In terms of effective teaching, UnicornSlaughter^2 is considerably better at giving a new player a chance to learn. Classic UnicornSlaughter, by comparison, just throws a new player right into the deep end. As the game’s creator, I found that the latter helped keep me challenged, but it yielded a difficulty curve unfairly steep for many first-time players.

Many of my Game-a-Day projects so far have included RDSA. A mostly complete enumeration of which games to date use some form of RDSA:

1. StellaBreakout - Two independent games of breakout that share a common control paddle. (I can’t take credit for this particular mechanic; this project was a close port of Game Mode 3 from the Atari 2600 game Super Breakout.)
2. UnicornSlaughter - Two overlapping games that each have different timing, again caused by world width being different from world height even though pieces enter at an evenly-paced global interval.
3. DarkPlace - The player’s two objectives at any given moment are (A.) kill nearest zombies (and B.) scan playing field to reassess which zombies are nearest. One underlying game involves orienting the slowly moving field-of-view to scan the area, while the other underlying game consists of maintaining the same field-of-view while trying to mouse directly over enemies.
4. SkyBubbles - Two distinct worlds of obstacles sharing the same physical space.
5. Tank - Player can only navigate or attack one at a time, and gameplay here demands both.
6. Cannonz - Moving the central cursor left/right trades off control fidelity from one cannon in favor of having raising precision with the other, and the two cannons are being used to clear two distinct spaces. Note that this form of control duality does not come up in UnicornSlaughter^2, because there the paddles are 100% orthagonal and thus independent of how the other is manipulated.
7. RecoilRocks - Navigation and firing are coupled to the same input action, forcing the player to think in terms of both needs at once.
8. HopNPop - Angels draw the player to point away from their current trajectory, increasingly vulnerability to the otherwise easily dodged balloon enemies.
9. Roots - Player has two visible metrics, one based on time and one based on number of roots destroyed. Although playing in a sustainable manner will grow both numbers, it highlights that there are really two overlapping mini-games facing the player: destroy roots, and don’t let roots touch the edge.
10. HotLavaMonkey - Slippery walls cause the player to slide toward the lava, forcing the player to jump frequently and stay high. Meanwhile, the unpredictability of where enemies will spawn into the world makes it unwise to linger near the top. The two games are: (1) jump to stay out of lava (and 2) avoid LavaJaw monsters. Each underlying game forces the other, and at the same time, frustrates attempts to succeed in either.
11. DodgeBall - Asymmetric coupling between navigation and attack; same as Tank.
12. NinjaVsPirates - Another navigation/attack coupling.
13. ManipuLie’ted - Perhaps the most blatant case to date: the above ground game’s objectives conflicts with the below ground game’s threats.
14. LaserLock - A unique case to Game-a-Day so far, in that this game (A.) preserves a detailed world state between player interactions, amounting to a living history of player moves (and B.) punishes every discrete move, but does not punish time between moves, making it important and feasible for the player to think ahead. Underlying game #1 is “destroy at least one of the existing cannons”, and game #2 is “don’t ruin future moves by creating a mess”. This project exhibits a chronolical case of what many of these other games did through spatial or input relationships.

To be perfectly clear: I am not proposing that the inclusion or absence of RDSA in a game is not inheriently a good or bad thing. UnicornSlaughter^2 is a more accessible game than UnicornSlaughter precisely because it doesn’t use RDSA, and for what I intended to accomplish with these games, sans-RDSA was a smarter choice. SkyBubbles had RDSA, and did not turn out very well, and the same can be said for NinjaVsPirates. Meanwhile, RDSA is at the heart of what makes some of my best releases work: DarkPlace, Tank, HopNPop, Roots, HotLavaMonkey, and LaserLock wouldn’t have been the same had they been designed without their respective RDSA elements.

Some games are well-suited for the tactical depth that RSDA affords, and others may be made too complicated by it. All I intended to accomplish with today’s journal entry was identify and communicate this concept, and provide local examples to clarify some of the many different ways that RDSA can exist within otherwise different games.

Square unicorns are happiest in a square field.

This entry was posted on Saturday, December 22nd, 2007 at 5:45 am and is filed under Abstract, Cognitive Psychology, Cross-Referencing, Free Flash Games, Funky Input Mapping, G-a-D Variation, Game Design, Game-at-Request, Retro Design. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.