     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Indie Postmortem: Reflexive Entertainment's During 2003 the successful Reflexive Arcade website was created, and by the end of that year the development and publishing of downloadable games became its primary business. With a staff of 11 full-time employees; Reflexive now focuses on the staggered development of two self-funded projects at a time, with a team dedicated to further the development of Reflexive Arcade. The roots of Wik began with what we at Reflexive call a "one-day-quick" prototype, where we regularly invest time in exploring new game ideas and mechanics by building a working, playable prototype. The prototype in question was called "BugEater", written by James C. Smith, and inspired by the arcade classic Missile Command. In "BugEater" the player controls several gecko-like creatures stationed on a rock border down the left and right edges of the screen. The object is to protect your grubs from thieving flying bugs by clicking on them causing your gecko to jump in a straight line across the screen and eat the offending bug thus freeing your grub:
What made "BugEater" a lot of fun was a multi-player mode that we termed a MouseParty™. We had eight people crowded around a single PC, with mice plugged into every USB port on every USB hub that we could find laying around the office, resulting in a crazy click-fest where everybody fought to rescue the most grubs before the level finished; it was complete mayhem and a lot of fun! Out of the six or so quick prototypes we short-listed at the time, "BugEater" was chosen for full development. What Went Right The Story. One area of the game that remained almost constant from initial conception to the final product was the back story. Originally conceived by myself, the back story revolves around a bunch of cute little grubs that appeared scattered throughout the land one night, each possessing the hypnotic ability to compel other creatures into taking it home and nurturing it. Once back at the creature's home, however, the parasitic grubs would jab its antenna into its heretofore unsuspecting host and steal its life before entering a chrysalis stage. The grub would then emerge from its chrysalis a monstrous creature and instinctively rampage its way back to its own home. Originally, these grubs fed upon themselves with the new generation literally taking the place of the old, but the older generation found that by sneaking their offspring to some far off place immediately after their once-every-decade mass communal birthing saved their skin by putting the gruesome burden upon others. The hero of the story is Wik, a forest dweller who lost his family to the marauding transformed grubs as they worked their way back home after the last birthing. Wik is not about to let the grubs repeat their destruction and so he comes up with a cunning plan. He decides to collect as many grubs as he can find, keeping them all in the magical backpack that he has strapped to his faithful mule Slotham, and journey to return them to their natural home where he plans to release them and restore their cyclical cannibalism. The story was meant to be told orally in a fairytale style from early in the product's development, but since we could not afford the download space required to ship with an audio narrative, we had to rely on the art and music being something extra special to pull the player along with the text of the story. About halfway through development of the project, writer Eric Dellaire was contracted to take the existing story and re-write it as a number of short poems/verses, the final cut of which was not approved until just a few days before the product shipped but we loved the dark and humorous style that Eric came up with, so that all in all, the story element turned out to be a great success. Composition of Background Art and Foreground Play Elements. Because of several factors including a six month compressed development cycle and 15MB download size limit, we decided the game would take place on a single non-scrolling background frame. Once this decision was made, we began experimenting with art styles for the three environment types that the story called for: a forest, some underground caves, and dark creepy vines. We figured 70 unique game play levels would be enough to tell the story, and we had plans for another game mode called "challenge mode" which would require about 50 more levels. There was not enough time in our schedule or space in our maximum 15MB download for 120 uniquely painted levels, so we set about developing techniques and tools that would allow us to compose our game play frame from a palette of pre-rendered art pieces. During pre-production, the lead artist on the project, Jeff McAteer, would take hand-painted elements and models rendered using 3D Studio Max into Photoshop and compose them with filters and effects, building atmospheric concept images. The programming team took note of this and began developing an in-game level editing system that allowed entities called props to be easily placed, rotated, scaled and colored on multiple layers, with basic filters and effects that could be applied as required. When
the game was in full production, the lead artist delegated creation
of the final rendered props for level construction to Chung Ho Kan
and Zach Young (who also wrote all the music for the game). Level
designers Ion Hardie (who also created all the sound effects in
the game) and Ernie Ramirez used these art pieces and the new level
editing system to create every level in the game. Within the final
two weeks of the project, the lead artist took two days going over
each level with its respective designer, making minor artistic changes
to improve its look. From the initial conception of the environment
types through to their final tuning and approval, the process was
a smooth one, thanks to good planning up-front and a tool set that
performed admirably.
User Interface Development Tools. Building the user interface in Reflexive games in the past involved our interface designer (Zach Young) creating a mock up in Photoshop to illustrate the overall design and placement of individual interface components. The programmer would then take this mockup and implement it, a process which might take days, while the designer moved on to other tasks. Once implemented, the designer would suggest modifications or sometimes completely re-design the interface once they were finished with whatever task they had been working on in the meantime, and again hand off to the programmer for implementation. While this process worked, it was hardly efficient and often disjointed. Since our level builder/editing system was turning out to be a great success, it seemed like a natural evolutionary step in its development to create more specialized 'props', and a powerful visual scripting system that would allow us to use this same system to build the games entire user interface. By giving the interface designer the power to place components and add script commands to the various events that would be triggered by them, we essentially took the programmer out of the loop, freeing the two bottlenecks that existed in our previous method. There were still times when the designer requested a new component or feature and had to wait for it to be implemented, but the designer was still free to develop other aspects of the interface. Building the user interface in this way allowed the artists and designers to get closer to the interface implementation process than they had been able to before. It also allowed them to use all the props, effects and features that exist within the main game on the interface in unexpected ways without tying up limited programming resources nearly as much as in past products. The Main Player Character. Design of the main character was initially driven by two things -the way he moved in the "BugEater" prototype, and the first draft of the back story. In our story the character had been through a pretty rough time. We wanted to communicate that fact and hoped that people would empathize a little as they read the story, so it was clear that we should try to avoid the reptilian look that the prototypes player character had, since most people have a hard time identifying feelings with reptiles. We figured that trying to meld the look of a small human frame with that of a frog would be an interesting direction, and our lead artist sketched literally hundreds of possible design ideas, some with subtle changes, and others more radical. The end product was a character we called 'Wik', who we felt was a step in the right direction. The first draft of the back story was basically a tale of revenge, featuring the player character having gone slightly crazy while dealing with the loss of his family, which twisted his character into something of an antihero. As such, many of the early sketches of Wik have a mischievous, some might even call wicked, edge to them. It was not until several months into the games development that Wik's story changed from one of revenge into him searching for the trapped souls of his family, and the softening of his earlier dark intent is reflected in the later visual design of his character. Well into the third month of development, there were serious concerns about the basic play mechanic; it was simply not fun enough as the foundation for the entire game. As in the original prototype, clicking on a bug somewhere on the screen made Wik jump across the entire screen in a straight line, intersecting the point where the player had clicked and snatching the bug along the way. We experimented with obstacles that would force the player to make several jumps around the screen to get to an intended target; we tried automatically grabbing bugs anywhere along Wik's jump path, there were experiments with Wik's long tongue, using it to snatch a bug from the air if it was within a pre-determined maximum range instead of him jumping, and a few other things that didn't seem to hit the mark either. It was Brian Fisher, programmer and physics guru, who came up with the idea of applying gravity to Wik's movement. The producer was initially unconvinced that gravity was the answer -it was interesting placing platforms around a level and jumping around, but it seemed like too radical a change to make given the limited development time remaining, and by itself it didn't add the extra spark of something we were looking for. After a couple of days experimenting and hopping around though, we struck upon the idea of seeing what would happen if Wik's long tongue stuck to platforms in a way that would allow him to dangle and swing, latching onto things mid jump. Even though the first version of this was implemented quite roughly, it was immediately apparent that we had hit upon something special. The addition of gravity marked a monumental turning point in Wik's development.
Changing the existing game to take advantage of this new jump and swing play mechanic would clearly take extra time to develop properly and balance; it would also mean that every level the designers had built to date would need to be scrapped. Deciding to commit to this new direction was not something to be taken lightly, but the game was clearly much more fun than everything else we had tried, and the jump-swinging introduced an element of skill that players could learn and improve over time. It took almost six weeks to get Wik and a small set of reference game levels balanced with the jumping and swinging play mechanic, but by the end of this period we had added other features, such as the ability to control Wik dangling from his tongue as though he is on a playground swing, simply by moving the mouse from left to right. His latched tongue also now collected bugs that flew into it like fly paper, and once those bugs were pulled back in his mouth Wik could spit them out shotgun style at great velocity, knocking other bugs out of the air. To tune and control all of Wik's new abilities, we created something called the "Wik style sheet", which is a list of 86 easily modifiable in-game editable property fields. This addition meant that we no longer had to re-compile the project source code each time we made a change to Wik's behavior. Mouse-Only Controls. A primary goal for any Reflexive game released into the current downloadable game space is that it should be possible to control every aspect of the game using only the mouse. We learned that a large percentage of downloadable game players are immediately turned off from any game where they are forced to learn which keys control various actions. To that end, the mouse is used to control every aspect of Wik's user interface, and also, to control the movement of Wik himself. While Wik's player control model may seem obvious to most of the people who play the game, a great deal of thought and care went into its design. The player directly controls the position of a fairly standard looking mouse cursor while playing, something which all Windows-based computer users are very familiar with, as in Windows, the left mouse button performs the primary action, which in this case means Wik either launching his tongue out as closely to the current mouse cursor position as possible, or him spitting whatever is currently in his mouth. The right Mouse button performs the secondary action, which follows the model used in many console games where the secondary action is to jump, here Wik will attempt to jump as close to the mouse cursor as he can reach. But what does jumping, or spitting, or latching Wik's tongue as closely to the "current mouse cursor position" really mean when he can only jump horizontally about as far as he is tall, or launch his tongue less than 1/3 the full height of the screen, or spit multiple objects of differing masses? Well, it means that there is a lot more internal calculation and prediction happening than people generally realize, all of which is designed to make Wik feel like he is doing 'the right thing' from the players perspective. For example, when the player clicks the jump button, Wik will normally calculate a jump trajectory that has the center of his mass traveling through the center of the mouse cursor, but when he is stood on a platform and the player clicks for a jump anywhere close to the edge of that platform, Wik does just about everything in his power to jump without falling off the edge of that platform. Another example of the interpretation of what the player "probably wants to do" includes tongue latch click positions, where the literal player input may be heavily modified so that as Wik jumps through the air, he searches for an optimum swing position around the click location rather than risk missing a latch altogether and possibly falling to a place where he loses a level because he fell into a pit of scorpions. The game is designed to do as much as it can to help the player have a positive experience, erring on the side of helping perform an action successfully rather than blindly accepting that the player must have meant to fall to his doom when he clicked just 4 pixels outside of a tongue latch area. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Features
|
|
|