Prototyping: Finding the Core Gameplay

Full text of the historical development log. Statements and links reflect the time of writing; text within the original figures is unchanged.

For such an experimental game, we knew from the outset that establishing the core gameplay would be difficult. We did not expect the journey to be quite so winding and demanding. Of the more than a year spent developing the game, over six months went into exploring and iterating on its core gameplay.

There were three of us at the beginning: me, Wuxia, our 3D artist, and Houge, our programmer. Wuxia was an extremely passionate core gamer, and Houge was an extraordinary gamer among programmers—his knowledge of games probably exceeded that of many designers. Why introduce the original team? Because the preferences of the people at a project's core can strongly influence its eventual direction.

If you remember the previous development log, we established three principles at the beginning:

1. Communicate through the language of player actions.

2. Build around a grown man and a young girl.

3. Use a toy-like, low-poly visual style.

Link: https://zhuanlan.zhihu.com/p/21270586

Those three points alone did not tell us how the game would play. Following an approach I had often used before, I felt we needed to quickly find a familiar core gameplay model to support the project.

Since the core team were all dedicated gamers, we quickly focused on The Binding of Isaac and Nuclear Throne. Both were exemplary top-down roguelike shooters on PC, with considerable replayability.

There were also mobile counterparts to top-down cartoon shooters. Examples were not numerous, but the Minigore series and the series cited in the Chinese original as Qihuan Sheji offered useful references.

Based on that reasoning, we quickly settled on two foundations: top-down shooting with a virtual joystick, and roguelike gameplay.

On roguelikes

People have long disagreed about what defines the genre. Our own working summary was: 1. Random elements.

2. Start over when you die.

3. Build up something over the course of a run.

That may be a blunt simplification, and many people might disagree, but it was our understanding.

Following that logic, we developed random maps, random item locations, random enemy spawning, and random ability choices on leveling up. These elements survived into the final version. A development aside: random maps in a 3D game took our programmer considerable time to investigate, including how to make object placement look good and how to handle enemy pathfinding on generated terrain. These were real challenges for a three-person team, but our remarkable programmer overcame them one by one. Random maps also cost us some visual quality: unpredictable arrangements were harder to art-direct, and randomly assembled tiles prevented us from using lightmaps, which weakened the lighting.

On top-down shooting

This was less troubling for me, because Qihuan Sheji and Minigore provided extensive references for the basic experience, including game feel, controls, and scale.

Automatic shooting raised a difficult question during prototyping. On a phone, we could not achieve the same coordination of shooting and movement as on PC. Both reference games used auto-aim, which substantially reduced the demands on direct control. Player skill shifted toward item timing, evasive movement, and distance management. The core gamers on our team were very unhappy about this. But actual testing showed how hard it was to accept dual-stick controls on a phone, given the limitations of virtual joysticks, and we eventually agreed on auto-aim.

We also initially used familiar weapons such as pistols, submachine guns, and shotguns. They felt out of place in our childlike, papercraft world. We redesigned them to look more like toys—water guns and similar objects—while preserving their basic gameplay roles.

On timeline-based interaction

This was the heart of MEET. Our earlier idea of interaction through player actions was abstract, and our budget ruled out the kind of interaction found in an online game. Journey was also exploring this territory. I wanted to work with the idea of a recording. People often ask why that interested me. There were several reasons.

1. As a Nintendo fan, I had never forgotten the ghost opponent in Mario Kart. The ghost never collided with me, but its cornering and acceleration provided important references for my own driving. Certain special stages with shadow versions of Mario in Super Mario Galaxy and other Super Mario games offered similar ideas.

2. The rise of game streaming also left a strong impression on me. Games were enjoyable not only to play but also to watch. Commentary in particular brought out a great deal of valuable information: when to join a team fight, when to farm the jungle, how much health a player had, or whether a Flash was well positioned. That information was both abundant and useful.

3. I had experimented with interacting with myself when making mods. In my spare time I had used UDK to make an FPS mod. A puzzle mod might require you to complete A, then B and C, and finally combine A with B and C to reach D. That kind of interaction with your own actions could itself be enjoyable.

Those three considerations led me to a gameplay concept based on recording your actions and cooperating with yourself.

Our first demo established only one thing: simply following the girl was not enjoyable in itself, and it undermined the gameplay we had designed for the man.

How to use that recording therefore became the focus of our design discussions.

The first debate concerned time. Did the girl and the man inhabit the same time and space, parallel universes, or a relationship between a ghost and the real world? This philosophical question kept us occupied for a whole year—laughs. It really did trouble us. Initially, we defined parallel universes: the man arrived at the same location and encountered an apparition of the girl, so her actions were happening in the present rather than belonging to the past. We later rejected this because it asked too much of the player. I would have needed to write three seasons of Fringe to explain it—laughs. A shared timeline felt easier to understand.

The second debate was how the girl and the man should interact. The obvious starting point was for the man to protect the girl. We quickly rejected that because following an uncontrollable, constantly moving character made the shooting experience unpleasant. We tried having the girl move in segments or pause, but the shooting rhythm still felt strange. Eventually we settled on interaction arising from movement itself, together with interaction through items. I will explain later how that evolved into wishing stars and wishing bottles.

On evasion and collection

From both a thematic and a game-design perspective, I wanted contrast: the man was strong and brave, while the girl was vulnerable and timid. That contrast led us toward evasion and collection for her gameplay. The Last Guy on PSN had impressed me with how well it conveyed escape and fearfulness. Kilo, who joined later, built on our earlier ideas to give the girl abilities such as flight—a short burst of fast movement—hiding in grass, and carrying stars. These additions made her gameplay much richer.

What we learned from the different prototypes

1. The girl's escape demo — June 9, 2015

It showed that moving with a virtual joystick could be enjoyable, but that movement alone was not enough.

2. Shooting, switching, and recording demo — June 26, 2015

We added basic movement and shooting for the man, as well as enemy health and attacks. It showed that recording-based gameplay was feasible, but that a route without interaction had no value on its own.

3. The explorer-and-digger demo — August 18, 2015

This demo divided the abilities between the characters. The girl could sense and explore, placing pinwheels to detect the positions of stars. The man could then dig up stars using the pinwheels she had placed in the recording, creating interaction between them. The aim was to let both characters work toward the same goal. Why did this design stop there? Houge, who had taken responsibility for the idea, left the MEET team around the end of December for personal reasons. The team itself had a difficult journey. Zhijie, Fanxing, Qiyuan, Kilo, and others who joined later made enormous contributions to completing the project.

4. The birth of wishing stars and wishing bottles

This idea was perhaps simply my own wishful thinking. I had always been drawn to folded paper wishing stars and the childhood belief that filling a bottle with them could make a wish come true. There was an innocent beauty to that, and I wanted to bring it into the game. We had never found a satisfying explanation for why the girl should leave items for the man. Having her make a wish and communicate it to him offered a way to express that relationship. Her wish was to meet him by entering the wishing pool.

It is difficult to say exactly where the inspiration came from. We started the project shortly after my daughter was born, when I was overflowing with feelings of fatherhood. The demands of game development meant that I came home late almost every night and could only see her asleep. Sometimes I imagined that she might wish to see me during the day, while I could only kiss her in her sleep at night and fight for her while she dreamed. Perhaps that is just the rambling of a father who makes games.

This log is somewhat loosely structured, but it records the small steps through which our core gameplay evolved.

By the way, our game is on Steam Greenlight. If you are interested, please consider voting for it.

http://steamcommunity.com/profiles/76561198262384914/home/

For Tokamak!