Continue reading »]]> Project Goal:
Entering the semester, the goal for this student-pitched project was to expand upon an existing game concept, Radar, which was created in one week as a Fall 2010 Building Virtual Worlds project. The game would be adapted to a touch-screen device, the iPad, utilizing its interface and functionality to develop innovative gameplay that built upon the original concept. The deliverable was to be a shipped game, submitted to the Apple App Store, consisting of 10-25 solid levels that introduced new features that took the existing Radar concept and expanded it in a compelling single-player experience with an appeal to a wide range of audiences, from adult casual to school-age children.

Background:
Radar was an arcade-style multiplayer game on the proprietary Jam-O-Drum platform. The screen featured a circular playing space that filled with dots representing the players’ health. Each player had an antenna that rotated around the circle at a fixed rate, and the player manipulated a small bar along the length of the antenna. The goal was to line up the bar with opponents’ health dots and tap the Jam-O-Drum to eliminate those health dots. The last player with health remaining was the winner. Radar proved to be a fun BVW world, largely due to the inherent triangularity of its multiplayer competition. The game’s core mechanic and circular playing space were novel features, convincing the team that there was great potential to expand the concept.

Getting Started:
Early responsibilities included constructing a web presence and engaging in outreach with mobile game developers and reviewers. Research done prior to the semester had suggested that game marketing was one area many developers wished they had concentrated on more for their first game. The team resolved not to overlook this aspect of the development process.

Many plans for gameplay mechanics were drafted prior to the semester, and the intended path to achieve the vision of this project seemed clear. The first quarter of the semester was to be a period of translating the base game to the iPad, devising a compelling control system, and completing a “Level One” by quarter walkarounds. From there, the team expected to spend four days a week iterating on a design for a level, testing it on the fifth and prototyping/brainstorming plans for the next level.

Initial Challenges:
However, things did not go as planned. The initial task of mapping Radar’s controls to the iPad proved to be much greater a challenge than anticipated. Due to issues such as obfuscation of the play space and finger-fatigue due to the constant action, playing the game proved to be more of an ordeal than a fun experience. The team tried to iterate through this problem, optimistic that a solution could be found, and confident in what made Radar a great game originally. The team’s strategy was to continue to add features, such as a larger touch-area, an exaggerated area of touch detection, and a tow-cable feature that allowed players to control the speed of the previously constant rotation of the antenna.

But the design was indeed married to its Jam-O-Drum controls, and what was fun in that context simply was not nearly as fun on a touch-screen device. Furthermore, the loss of inherent triangularity in moving from multiplayer to single-player also detracted from the fun-factor. The added features proved to be only “band-aids;” they did not solve the overarching issues of the game. It was then clear that the Radar design had gone as far as it could on the iPad.

By this time in the semester, the team had learned several valuable lessons. First, a crucial mistake had been made in assuming that the Radar concept would remain fun on a different platform with a fundamentally different form of interacting with the device. Fun can certainly be platform-dependent. Along these same lines, the team had learned that iteration does not solve all problems; one cannot simply iterate through a problem if the concept being built upon is a flawed foundation. Additionally, though marketing is not something to forget about, it should not be done before a concept is proven to be successful. Time and effort had been spent on marketing an idea that had not yet been executed, and this time should have been spent on ensuring a strong design.

New Directions:
Thus, shortly before quarters, the team, under faculty advisement, shifted direction dramatically from the original Radar concept, instead attempting to center the design around the most fun feature of the most recent build. This marked the beginning of a series of iterations in an attempt to find the fun. The first attempt was to center a new concept around the most appealing feature of what had already been created. The tow-cable was fun to watch and a fun toy to play with, so the team sought to build a game around that toy.

The tow-cable behavior seemed evocative of a “tag” interaction, so the mechanic was mapped to a form of gameplay in which the player controlled a shrimp being chased by a predator around the center of the screen. The player could speed up and sneak up behind the predator to pick up the orbs it dropped before they faded away, which was a somewhat fun “pushing-your-luck” mechanic. However, the remaining problems of finger fatigue overshadowed any improvement in fun.

At this point, the team recognized the need to move beyond the circular game space, towards a paradigm that better reinforced the game’s desired theme of exploration and discovery. It was difficult to explore and discover within a limited, stagnant space. Furthermore, it became apparent that the gameplay model of perpetual action was not meeting the needs of the casual gamer who would be playing this iPad game. Instead, a model of a period of action and a period of rest was adopted. Many successful casual touch-screen games incorporate a player action followed by an opportunity to rest and view the results of that action. Coupled with the team’s exploration with physics-based interactions, a node-to-node system of travel was developed. Throughout this period, the team learned that it is very important to be open to change.

Faculty feedback from quarters had strongly encouraged the use of touch-based actions, such as flicking, that are inherently fun, and particularly suited to the touch interaction. This suggestion spurred the exploration of physics, and the team iterated on this raw idea, experimenting to find out what fun behaviors could be performed within it. It was determined that some constraints needed to be applied to the movement of the shrimp character within the space, and so the construct of nodes from which to launch was developed. It was originally thought that there would be many smaller circular areas mimicking the original circular game space. These circles began as whirlpools, and the player launched between them, using the gravity wells to stick to the centers. These nodes were shortly re-themed as bubbles, which were more logically consistent with the interaction.

Playing the Game Into Existence:
By the midpoint of the semester, the team had decided to move forward with this node-to-node based exploration game. A handful of prototypes had been built, but the major question was what the goal of the game was to be. The team’s plan for solving this question was to “play the game into existence,” creating and playtesting experimental levels and finding out what emergent goals develop for players. In the following weeks, the team held at least one playtest per week with ETC colleagues, also taking the game outside the school to test with younger and older participants at coffee shops and museums. The many design questions were mostly answered as the process went on, and the game shaped into a platformer-like point A to point B travel experience, with a primary goal of surviving and reaching the end of each level, and a secondary goal of collecting as many gems as possible along the way.

Attempts at devising a scoring system were made, incorporating elements such as player time, number of bounces, collected gems, number of deaths, and number of bubbles used, but ultimately all players cared about was reaching the end with as many gems as possible. Evaluating players based on time contradicted the desirable interruptible aspect of the game and its node-to-node travel, and thus was ruled out as a possible scoring metric. Players enjoyed bouncing and using angles to make trick shots, but explicitly scoring them so felt strange, and so it made more sense to simply design levels inherently requiring such shots to progress through. The team adopted the design strategy of making it challenging and rewarding to reach the endpoint of each level.

Once the basic goals of the game were clear, and the scope of features had become relatively finalized, the primary challenge was crafting a compelling interest curve and progression of challenge for the sequence of levels. From playtests, it was clear that players could pick up the controls quickly, but the goals still needed to be communicated clearly. The team created a series of levels that served to incrementally introduce each feature, from the basic goal to the ways in which the space could be navigated, and tested the sequence on a wide range of demographics. For more naïve players, it was apparent that a clearer UI system would be required, but that once the core mechanic was understood, nearly any player would pick up the basic tactics within minutes.

The level progression consisted of a series of six short tutorial levels, each introducing incrementally one new base concept, and then three levels each centered around a different type of terrain, such as bouncier sponges, propelling currents, and slick ice blocks. Each group of levels built cumulatively upon previous levels. The beta build presented at ETC Finals consisted of 17 levels, and the goal for a January launch is 25 levels.

Polish:
The team polished the game in the weeks between Soft Opening and Finals, adding more art and sound assets, implementing additional forms of feedback for player accomplishments, and addressing some of the many helpful suggestions received from faculty at Soft Opening. Key additions included a more celebratory level-complete screen, more animations, music tracks for different environments, and a revamped gem-collection metaphor.

The team had tried equating gems to retries, subtracting from the player’s total for each failed launch, but this proved dissatisfying. Instead, retries were tallied and gems collected were not taken away on deaths. Upon completion of the level, the player’s collected gems and retries used were counted. Badges were presented for collecting lots of gems, using few retries, and completing a perfect run of the level.

One final addition was a simple narrative. Throughout playtests, players expressed some confusion as to their objectives because of the lack of a game story. By including an introductory slide sequence presenting a scenario in which the shrimp protagonist’s mission of finding gems was explained, players had greater context for their actions and were more satisfied.

Conclusions:
The team’s future goals are to ship a finished product with 25 levels by the end of January, available for purchase at $0.99 on the Apple App Store, adding level packs over time to support the game. Thanks to the framework created this semester, it will be quite feasible to maintain this level of support. And as a result of these past few months of work developing seAker, the team has learned a handful of priceless lessons.

For one, marketing, while important, should only be focused on when the game is ready, and no earlier. The strength of the design should be the top priority. Second, fun is platform-dependent, and one must always keep in mind the strengths, weaknesses, and applications of a particular platform when developing a game for it. Objectivity is key to this, as growing too attached to ideas can blind developers to the flaws holding back a design’s potential. To successfully iterate, one must prototype ideas. By actually building something, not just discussing theory, and presenting the build to players, developers can discover what goals emerge, and what structure feels right for the game. Additionally, it is important to nail down the core of the game, creating something small that is strong, because it is easier to add quantity to an idea of good quality, but very difficult to do the reverse. And finally, having goals, whether they are a final ship date or intermediary deadlines for playtests, really helps a team maintain its focus and continue to push ahead. Team seAker has definitely benefitted from this experience of developing for a full semester, and hopes to build on this foundation in the future.

Continue reading »]]> (VIEW AS PDF)

UPDATES

End of Semester Presentations:

As the semester draws to a close, the team is making its final preparations to present to the faculty this coming Wednesday. The presentation will not only demonstrate the product, but also discuss the story of the team’s process. From the initial planning stages, to the shift in direction, to the iteration of a new concept, the team will walk the faculty through the twists and turns of their journey this semester. Lessons learned will be a crucial part of the discussion, as the team has certainly learned a lot throughout its work on seAker.

As for the product, the finishing touches are being put on the art, sound, and “polish” features. The level set is also being reviewed, and minor kinks in the level design are being addressed. The game will be shown at Finals with 17 levels that demonstrate well the incremental introduction of features, the progression of challenge, and the exposition of many gameplay elements. Following the conclusion of the semester, the team will continue to work to create more levels, aiming at a total of 25 for a January App Store release.

ACCOMPLISHMENTS

• Produced additional art assets
• Held meetings to discuss preparations for finals
• Demonstrated game for guests at BVW Show Reception

Continue reading »]]> (VIEW AS PDF)

UPDATES

Pulling It All Together:

The week began with Soft Opening presentations, and the team demonstrated the beta product to the faculty, receiving plenty of helpful feedback. While the game generally was received quite positively, suggestions for improvements included the use of a dual economy (gems and a retry item that serves as a buffer), improved storytelling throughout the experience, and more polished visual and audio feedback.

In the coming two weeks prior to final presentations, the team will be working to add such bells and whistles as new animations, more level decorations, more music with a lighthearted mood, an improved title screen, an improved tutorial experience, more dynamic background art, improved UI, victory celebrations, and other details that will help to create a more complete experience. The team will also be tweaking the levels and playtesting to determine the effectiveness of the revised gem economy.

ACCOMPLISHMENTS:

• Presented at Soft Opening; reviewed and prioritized feedback
• Produced art assets for revised menu screens and UI elements
• Implemented a “go back one bubble” button and revised UI/menu functions
• Bug fixes
• Began creating additional music tracks

Continue reading »]]> (VIEW AS PDF)

UPDATES

Beta Build 2/Preparation for Soft Opening:

The team has been working hard to implement all features and levels for soft opening on Monday. Levels are currently being adapted to a new plist format, and the version presented at softs will include 17 levels. The early levels introduce the game’s goals and mechanics incrementally, and intermediate and later levels are feature-length with greater challenge, also introducing the special features such as sponges, currents, and ice. The framework of the game is complete, as user data can be saved and erased, and intro and outro sequences play at the appropriate times. Additionally, the team has shot footage for the demo videos and is preparing the archives for soft opening.

ACCOMPLISHMENTS:

Designed and implemented 17 levels – Save data functional, all other infrastructure implemented – Implemented animations and particle effects – Created intro and outro story slides – Finalized art assets, including new screens for intro, credits, and options – Bug fixes

Continue reading »]]> (VIEW AS PDF)

UPDATES

Beta Build 1:

With features locked, the team focused this week on implementation and level construction. The levels presented at last week’s ETC playtest were shown to children and seniors in coordination with a Makeshop playtest at the Children’s Museum, providing valuable feedback regarding how clear and playable the game is for members of other age demographics. Art asset production and feature implementation are ongoing tasks, and the team has mapped out the progression for levels and begun designing later levels introducing special features, such as sponges, currents, and ice.

ACCOMPLISHMENTS:

Playtested at Children’s Museum – Designed level progression – Implemented Levels 12 and 13 – Improved UI Feedback for Gem Loss – New art style defined – Level select system implemented

Continue reading »]]> Playtested Build #13 with six (6) subjects ages 10-75 at the Children’s Museum.

1. Prioritized Next Steps
1. Add: Better tutorial with more showing, less words. Remove from title screen
2. Add: More gem feedback, both when you collect gems and lose them
3. Add: Make “Go Back to Bubble” button more obvious. Remove it from view when shrimp is already in a bubble
4. Add: More intermediary levels to ease difficulty curve of levels
5. Update: “Restart Level” button should disappear when shrimp is in flight. Restart level button needs to be more visual. Should be consistent with Victory Screen symbols
6. Remove: “Next Level” button from the in-game UI. Only have this button on the Victory Screen
7. Add: Level select screen
8. Add: feedback for when shrimp is touched
9. Update: goal graphic/metaphor
10. Add: Story/goal explanation
2. What Went Well
1. Generally picked up mechanic quickly
2. All playtesters appeared to want to keep playing even after being told they could leave at any time
3. Gem collection needs to be more obvious
4. Gameplay described as mini golf, billiards, and pinball
5. Go Back to Bubble button very useful to playtesters once they understood what it did
6. Understood the spiky guys were bad (may have taken 1 death to determine this)
3. What Needs Improvement
1. What objects that you interact with. ie: the shrimp on the first level is what you touch.
2. Remove title screen “How to Play” to avoid confusion. Instead show through pop up graphics (perhaps animated) how to play as the player goes through each level
3. Emphasize that gems are good and the player should want to collect them
4. Add a few more intermediate levels. First levels we so easy, but quickly got harder so this might help smooth out the difficulty curve
5. Add indicator of when to use the “Go Back to Bubble” button when shrimp is going very slowly or at rest
6. Confusing to playtesters: UI for retry level and “Go back to Bubble” was sometimes
7. Kept pulling finger TOWARD the direction they were aiming, instead of the reverse direction. Perhaps a stronger tutorial would fix this issue? Playtesters perhaps thought it was more of a flick rather than a slingshot
8. All playtesters tried to flick shrimp when he was stuck
9. Need level select screen
10. Need narrative/story to give players a reason to get the the goal
11. Need clearer goal target area. The gold spiral bubble is out of place.
12. Sponges need a springy animation and color change. They look to much like seaweed. Sponges seem to have a low margin of error. They are very unforgiving
4. Experiments
1. “Playground” level where there might be a few gems, just to show players how the physics work
2. Possible feature: Automatically make shrimp go back one bubble if he stops