saviors-dev

[saviors-dev]

A Full Update about the Last Year

It was a super long time since the last post, but the game has never stopped development. I figured I had to talk about the things I have worked on in the past year aside from bug fixes and lots of minor improvements.

UI, Fix and Improvements

The months following a major change on the strategy part were spent on various UI and fixes. Turned out as the project goes big, the time on trivial parts increases and becomes non-negligible. Until March 2017, I was making new loadout window, mission screens, windows in the mothership, map generation, ... and a lot of refactoring.

Solo Mode

Then I was redoing the solo mode of the game. To keep players around, there has to be a solo mode, especially when the player base is not that large. For Signal Decay, you’ll need a bigger player base because each game is much longer than fast-paced PvP games.

The two functions of solo mode are to keep players around and to help players to develop a deeper understanding of co-op mode. So the constraint is that the levels should be the same. To buff the player in solo mode, I decided to add a special ability for her.

The first mechanic I came up with in 2016 was that at any time player can set up a mark, and she can teleport to it at any time. This sounds like Sombra’s ability in Overwatch, but it was before Sombra. But soon I discovered it makes the game much simpler for players can escape or ambush enemies with one tactic in any situation.

Then I added an assistant robot as the ability for the solo player, which is a variant of the mark-and-teleport ability. Players can order the assistant robot to move around and operate on mechanisms. The player may also teleport to its position, and the robot then will teleport to the player’s position.

The solo mode is a much slower experience than the multiplayer mode.

Networking

Network mode is a must-have because local multiplayer just doesn't sell. After some investigation, I decided to use uNet and P2P because of the ease of using it. It provides me a full framework and can reduce the work. As to Unity’s relay service problem, I found Photon Thunder as a replacement, which lets me use uNet’s API and Photon’s service at the same time.

It took me more than two months to make the networking basically work. 

Integration of Wwise

I decided to integrate Wwise into Signal Decay for audio management. Wwise provides a lot of essential functions that I don’t need to reinvent in Unity. I also tried FMOD, but it seems not as convenient as Wwise for frequently used functions.

Although the pricing of Wwise is a bit high, it’s worth it for me as a solo team which needs to save time as much as possible.

And also, I’ve got someone to make me some top-notch music! It’s awesome!

Build Content

To really test out the strategy layer and the overall sense of progression, I had to have enough content, mostly the techs that players unlock during a game. Without those, it’s hard to say if the experience is good.

So I spent a lot of time to build more equipment which players will unlock. A piece of equipment is a weapon, a gadget or a consumable item. For many of them, I need to create new interaction schemes.

I spent several months to finally have 10 weapons, 6 gadgets and 2 consumable items. And these are like half of the techs in the final game. I tried to arrange them in the current tech upgrade system, and it didn’t look good. Seems the tech tree system added too much constraint and players could not use their creativity to make interesting compositions of equipment. I was thinking about iterating the tech system again.

Tutorial

I tried to make a new single-player tutorial in which there is an NPC teammate with the player. It is single-player because multiplayer tutorial is basically undoable. An NPC player will quickly let the player realize this is a co-op game, and show the player the basic tactics to co-op.

It took me a while to make the tutorial. Right in the beginning, an alarm is raised so the player will realize it is a stealth game and enemies are dangerous. Then the NPC leaves the player behind so that the player will learn some basic interactions through a series of challenges. After a few challenges the player join the NPC and perform two ambush kills.

I spent a lot of time on gating players naturally, I just lock some doors and unlock them only after certain events. It is still not good enough and confuses players. I added some scripted camera movement later to guide the player. I haven’t playtested it yet but I believe this makes the player walk in the right direction. Also, recently I’ve come up with a way to constrain the camera to gate the player. Haven’t put it in yet.

It also took me a long time working on the fail state. What happens if the player is spotted by the enemy in a situation where he’s supposed to sneak by? Back to the previous checkpoint and set everything back? It’s a clear feedback that the player has failed but I tend not to interrupt the player’s experience -- and the checkpoint system will also be some work, which doesn’t exist elsewhere. So what I did was putting a warning mark at the position, hinting the player to get back with texts and letting the guard go for the player. However, until the player goes back to the previous room, the guard is paused on his way in a room that the player can’t see. So I did a lot of level design stuff for each challenge.

Some players may just want to rush to the goal door. I believe it’s because the feedbacks are not clear enough, and this will ultimately work out.

Simplification Of Strategy Layer

The final major problem haunting in my head was the strategy layer. The world system seems still too complicated, and the choice players make are insignificant. There are just too much going on in the world. There are 12 sites and each of them might be managing a contact to another, and there are even more channels and each has an individual state. And because the number is so big, the outcome of the system is so even that it doesn’t really matter for players to choose to go in for this mission or that. I put a positive feedback loop in but it seems not work well.

I need to make a prototype. Away from NYU Game Center, I don’t have quick access to paper-prototyping materials. Luckily I bought Tabletop Simulator, and it’s a great tool for me to create prototypes. I came up with some rules, and try to simulate the world a bit, to understand more about the system. And finally, I’ve got a system that requires a bit thinking, but not too overwhelming. It turned out to be a much simpler system than I thought.

The tech system is connected to the world/pilot system. Players have to take look at the current techs & resources they have to decide which site they are flying to. And this already makes the decision-making interesting if done right. So it’s better not to overwhelm players with a complex world.

But I still need to make a computer prototype. I had made some before, but they were just rudimentary and could not answer my questions. Then I had built enough content. I thought maybe I could just make the prototype inside the game so I could reuse a lot of code. So I built a full developer terminal to simulate the strategy layer. It turned out to be a right decision. I started to playtest and iterate the gameplay via the terminal.

In the end, the dynamics of the world is simplified to that every 12 hours, there is a site routinely raising its alert state, and a low rank alerted site might also affect a higher rank site. With this mechanic, players can easily get what will happen in a few hours and can plan out ahead to make a better decision.

I also changed the tech system a lot. I tried to remove the constraint of building tech modules so the players can try a lot more compositions. It’s not a “tree” anymore but more like a pool. There a lot of time management in the gameplay. To make early modules meaningful in later games, and to support more play styles, I introduced a new kind of resources, power. Each tech module generates one power, and a tech module spends 1~4 power if is in production. Power doesn’t accumulate. So in conclusion, I removed a constraint and added another at the same time. I playtested a lot and felt pretty good about the strategy part of the game.

Graphics Upgrade

I’ve got a contract artist helping me to remake the graphics. Now there are much more details and the world became vivid. I had to re-code the level editing tool to support various decorative tiles. Fortunately, Unity has released its tilemap system. It is a very good and extensible framework despite many glitches. I saved a lot of time. Now I am thinking about environmental storytelling through levels to enhance the player experience even more.

[saviors-dev]

Strategy & Tech System (WIP)

Signal Decay has two layers of gameplay. As the low-level gameplay (tactical combat/mission execution) had been iterated well, the high-level gameplay (strategy/tech system) needed to be redesigned to enhance the replayability, which we were working on in the recent months. It took much time to make it meaningful, replayable, minimal and fitting in the narrative as well.

Principles of Enhancing Replayability

Let’s talk about how to design the replayability in principle for roguelikes. As to my research, the replayability of roguelike games comes from three aspects: emergence of the gameplay, encounter randomness and input variance.

Emergence of the gameplay: the basis that produces the longevity of play. You may argue emergence is so generic that it includes everything. Here we refer to the emergence of the moment-to-moment interactions. The two other factors have to be built on top of it.

Encounter randomness: the randomized events/enemies that are intentionally hidden from players. Rewarding players by showing unpredictable content in progression. Keeping the experience different and avoid memorization.

Input variance: the visible part of randomness and visible set-up of game that will affect a player's decision on the same encounters, such as players’ equipment and levels, map set-up and characters. Makes players come up with a different strategy each time playing the game.

The input variance may caused by randomization, player’s choice in the beginning (selecting a ship first in FTL), or simply overall progression (unlocking new stuff in Rogue Legacy).

An encounter might turn to an input for the next encounter as the information turns to visible, as long as it will affect players’ decisions (in the rest of the game). For example, the player randomly acquires a skill on reaching level 2.

Longevity = Emergence * Encounter * Input (ideally)

Board Strategy

Players pilot an aircraft to decide the next mission to execute regarding the current technology and time. All the cities have an ever-escalating alarm level.

Less Options At a Time + Keep Harder Missions Later

According to the narrative of the game, the goal is to destroy the machines in all major cities.

The goal is not that usual in nonlinear strategy games. Most games are more like keeping a meter down or collecting resources to use and survive, with occasional enforced events. In Signal Decay, players is using an aircraft that can fly freely, so the question to our design is how to provide not too many options at a time. Compared with boardgames like PANDEMIC, each mission is a level rather than an action, so you have to keep it chanllenging and refreshing. That means we have to keep harder missions later, and the boss mission last.

The system should keep some missions unavailable first. In Invisible, Inc, most missions were hidden until players find site lists to reveal them, which is a good design for that game. We’ve come up with a few other designs. One is that you cannot enter an area unless having invaded the border cities. This mechanic can keep players complete missions in certain orders, thus to keep harder missions later.

From the idea above we come up a mechanic of less rules: each mind-control machine emits mine-control radio waves in a certain radius; a machine covered in 3 different waves cannot be located. The fallback is that a winnable map might feel artificial.

An alternative way is to make those cities need further steps to reach. For example, in PANDEMIC, there are lots of cities, but you can only go to a few cities in one turn, and a random event happens each turn so you don’t need to calculate too much.

I think it still takes more work to decide this mechanic.

Increase Replayability: Optional Missions

The world map will be procedurally generated but there overall progression is perhaps similar. To avoid repetition by increasing "input variance", randomized optional missions with rewards keep popping up to encourage players to use a different path.

Lose Conditions

Players should lose the game in action. It sucks if players use a bad strategy game and lose immediately. Bad strategy should just make the game harder, not making it impossible.

In Signal Decay, time is a resource. As time passes by, all the missions become harder. So players have to spend time deliberately. But a mission cannot be infinitely harder. if all the missions have reached the highest alarm level, “time” loses its meaning -- players can hang on forever, which is definitely unacceptable.

After all, as long as all alarm levels have maxium values, there has to be a trigger that makes the players lose the game when they have used too much time. The simple solution is that after a timer, players lose the game. It is not very good because the players should lose the game as soon as the game turns out to be impossible to beat. The lose condition above doesn’t met this requirement. We’ve come up with many solutions, but all of them fall into these two kinds:

In survival games, players lose when running out of resources.

Players lose when the time is up. The timer starts in some circumstance. (1) Doing major missions gets extra time/resets the timer. Or (2) doing a certain major missions resets the timer.

We also need to come up with a narrative for the design. However, those solutions don’t work very well for the narrative. Luckily, we found a solution at last and it is magically mathematically a combination of the two, which works very well with the narrative and will convey interesting experience. I’ll keep it as a secret.

Tech System

There are three design goals for tech system: 1. providing more play styles; 2. strategical to make a choice on unlocking techs; 3. as “input variance”, affecting other players’ decisions each game.

For the second goal, the player is able to choose a tech to unlock. There should be a system like tech tree. For the third goal, since there should be something different each time, the design is that player can get random tech in missions. This will affect other choice of techs.

As to the interactions of the tech system, we want to make it a co-op experience. We try to make the decision-making happen in the world space rather on the UI. As a result, players may build a lots of different tech consoles (modules) and each consoles have a few techs to develop. Player walk through rooms to make decisions.

You can use a tech module to develop a new tech module. So it works like a tech tree.

You can only assign one task to a module at time.

There will many modules. Unlike Civilization, in each game players can only research a small portion of the tech tree. The constraint keeps players finding the best combination for each game. Because of "input variance", the best combination is always different.

However, there are a few essential techs I hope to have them in every game, which are unlocked in different stages of the game. We might be able to make an intricate tech tree to achieve it, or make those essential techs be unlocked in other ways. For example, each 3 tech modules charge a big cell, in which players can construct something like a factory. We will experiment on that.

[saviors-dev]

Remade the AIs using NodeCanvas. This is the behavior tree of a regular guard.

[saviors-dev]

Renovated the Graphics

I was thinking the core for Signal Decay was the gameplay and the graphics was there to support the gameplay. So I learned from Teleglitch, and made a rough art to reduce my workload.

I was right. But it was hard to promote a game like this, especially nowadays as a debut game studio. I was hesitating to remake the graphics, and finally I did it.

It was one month ago I realized that Signal Decay has a critical difference from Teleglitch -- it is a slow-paced game. So there are less physical or mental interactions (for new players) happening in a certain period of time. Perceiving the details in the world will be a important part of the experience. The idea can be discussed further, and it turns out to be what is talked about here: https://www.jesperjuul.net/text/acertainlevel/. Since it takes longer for players to learn Signal Decay, it turns out to be harder for Signal Decay to keep players’ interest until they feel in control.

Also added some graphics. There are elevators to replace stairways. And there are scanners to replace the double-door puzzle. At the end of the mission, if the players are too slow, there will be crazier things happening. Haha

[saviors-dev]

Adding Gears

Recent two months ended up with adding more layers to the system and refining interactions. We also spent some time on teaching players better.

Refining System

At the end of January, alarm level was added to the game system. It turned out to work very well. As players kill people, the mission quickly escalate to be insanely difficult. It’s the increasing pressure that forces players to be cooperative all the time, both in combat and in exploring. An observation is, that although players kind of learned that, they still love to kill people together.

There were a few minor problems in the gameplay. One problem was that it was too easy to beat enemies on the fly when players are cooperative enough, so they do much less planning than improvisation. We don’t want recovering from bad situation to be hard, because it will significantly decrease the tolerance for mistakes — and it’s permadeath.

Once we had the reinforcement and alarm level mechanics, a good solution emerged: A stealth kill won’t trigger reinforcement and rise in alarm level, and imperfect kills will. A stealth kill is defined as killing idle enemies instantly. In this way, mistakes don't have instant impacts and players can still fix them, while killing enemies imperfectly is bound with a negative consequence in the future.

And dragging corpse becomes necessary then. If a guard notices the corpse, alarm level rises.

Narrative Meanings

How does a kill trigger reinforcement and rise of the alarm level? We have to solve the narrative meanings behind it.

A guard will uses radio to contact others. If he tell others about suspicious activity, others will know when he is killed. So the system raise the alarm level.

The same effect happens as well when a guard find a death that he doesn’t know before.

It is not ideally elegant though. A better design will be like this:

The relationship looks much cleaner. However, this might cause another problem — players killing guards intentionally in a bad way, waiting and snipering everyone that comes. So this design needs more playtests.

More Things In A Mission

Trying to adding more resource, healing kits and mechanisms. The observation for now is that as long as there are more options in a mission, the gameplay gets deeper and there are more tradeoffs for players to consider.

The design might benefit from more optional goals.

Misc

Refining the interactions and UI in the airship. Adding more features to the procedural generation algorithms. Adding log viewers as a supplement element to teach players.

We also tried to change the graphics totally to isometric one. But finally we decided not to. We’ll talk about it in the next post.

[saviors-dev]

Will Be Exhibited at Indie MEGABOOTH, PAX East 2016!

News in a row! Squad Of Saviors is finally renamed to Signal Decay, which implies the cyberpunk setting and the sense of stealth. And, it is selected in Indie MEGABOOTH and gonna be featured at PAX East 2016!!

Check out the line-up here.

The reason is that Squad Of Saviors is weird to Americans, especially to Christians. The sound is not good as well. I like the shorthand, SOS though.

My friends helped me with many options:

Martyr Squad, Equilibriium, Mesmer, TransGlitch..

There was a movie already called Equilibrium, and the feel was also too close. The final decision came to Signal Decay. My friend’s comment says, it sounds elegant fitting with the abstract and elegant design.

[saviors-dev]

Enriching gameplay

The game’s been added a lot of features since the vertical slice, which makes the game even more tense and kinda scary.

- Each city has an alive alarm level now. It increases in the world map, also in a mission. When you kill people when being exposed, not only more people will reinforce, but also the alarm level is increased.

- Now you can bring multiple weapons to the mission.

- Players need to drag and hide bodies, to avoid raising alarm levels.

The game is one step closer to the beta version. More content is coming!

[saviors-dev]

[saviors-dev]

Vertical Slice - Adding a strategy layer

The first vertical slice is finally done. In the new build players can pilot an airship and strategically find next city to infiltrate.

There was macro gameplay and micro gameplay when this project was initiated. The micro gameplay is stealth and combat, and the macro gameplay is choosing a city to infiltrate, with board strategy involved. The decisions made in the macro gameplay affect how hard a mission will be. The macro gameplay was never really started until the micro gameplay got solid enough. And recently I am finally able to do the first pass of the macro gameplay, replacing the placeholder.

The first pass of the strategy part is:

The game is REAL time. Every second the players spend will be real time that elapses in the game. 10 Seconds = 1 min.

In the ship, as time elapses players recover health slowly.

Every city has an alarm level. A saved city or a city of alarm level no less than 3 causes adjacent cities raise alarm levels over time.

Unsaved city increase the enemy reinforcement rates in adjacent cities.

Global Awareness raise alarm levels of all the cities. It increases when guards are killed in any city.

How alarm levels work:

When alarm level is N ( 1 <= N <= 3), N random patrolling guards are added when the mission starts.

When alarm level is 4, 3 random patrolling guards and 1 alarm robot are added.

When alarm level is 5 (max), 3 random patrolling guards and 1 alarm robot are added, and all guards start to patrol randomly.

[saviors-dev]

Return to refining the game from beginning

Except for the strategy gameplay part is missing, the gameplay is getting very solid and interesting. In order to shape the wanted experience, the game introduces a lot of mechanics to players at the beginning, and new players find it hard to pick up. According to the recent playtest, most players simply play it as a linear shooter, but once they regard the game as a sandboxed stealth game, they can do much better.

As I wrote in the last post. I planned to add some elements to scaffold players and I finished some. I remade the mission briefing screen, designed weaponless guards and upgraded the procedural generation algorithm. Each of them help players to have a little better experience in the beginning.

The mission briefing screen emphasizes the goal of the level at the beginning. (Maybe more information to setting up the stealth tone)

The weaponless guards have a yellow light on helmets, and no guns in their hands. It is not very distinguishable but it provides more tolerance for mistakes without being known by players in recent playtests.

The upgraded algorithm can ensure that a level always starts with a certain room, and has more balanced distribution of enemies.

And I also added details like these:

Adding flashing lights in the back of enemies’ heads to indicate their weakness. It seems not to work very well.

Adding indicators when players reach the stairways and the machine - guiding players. Working very well.

The problems that people don’t get the game as a stealth one still exists. Part of the reason is that the game didn’t teach the mechanic that guards can hear you. The solutions for now I think is to tweak the feelings (like it feel crappy when you awake guards), and log viewer I mentioned in the last post. Dispense pieces of information as a way to teach and tell a story. If these do not work perfectly, there will always a backup solution - hands-on teaching and taking players through one level.

However, there is one more thing to consider for a roguelike game. How to make the first level both easy for new players and interesting for power players? The answer of mine for now is, user-side negative feedback. This question will come up in later development.

[saviors-dev]

IGF China & Recent Progress

In the past month Squad Of Saviors honorably won the finalist of IGF China, and was shown in Shanghai. I went to China and showed the game there. It was a great convention and I got to know a lot of people. Meanwhile the game was moderately exposed to the market in China.

I was working on teaching players and trivial issues in the past month. The tutorial was further refined and turned out to do a good job in teaching players the basic interactions. Not very productive when I was in China due to the Great Fire Wall…

The ship was redesigned and much smaller than before, to make everything tighter. Now there are three floors in the ship, which are reception room, training and living rooms, and mission room from bottom to top.

More refinement was done on the graphic and visualization. A bloom fx makes the game more cyberpunky. The fog of war was changed to controversial green and some extra marks are made. Title background music was remade (still not finished yet). Procedural generation was refactored.

Enemies have indicators around to show the ranges they could hear, which is a little distracting and might not be necessary. Still figuring it out.

Production Plan For Near Future

The goal for now is to scaffold players using more preliminary elements and to enrich the experience on the other hand. A couple of things need to be taught or reinforced.

The goal of each level is to find and destroy a machine. However, players are too prone to kill enemies. So the goal needs to be shown clearly on the mission screen(1). Also, there should be some puzzle-solving (like unlocking doors) gameplay(2) which blocks player first - so players will treat it as a challenge and try hard to reach unknown areas. It also illuminates short-term goals and makes the level more logical.

Attacking enemies from behind is critical. I think introducing weaponless enemies(3) might be good, who will run to find weapons upon seeing players. This is also a tutorial for armed enemies. Another option is to have a log reader(4), which explains the mechanic.

Sneaking/Using environment. There are too much in the beginning for new players. Enemies that has only one function will help players to learn the gameplay easier, e.g. sound sensors(5) that only hear sound, cameras(6) that only watch players.

Pincer attack. Introduce something that forces players to separate. Like doors that only one man can pass(7). Still figuring out how to have it make sense narratively.

All these things need to change the algorithm of procedural generation so it can *inserts* certain elements into a level. So the priority is:

Improving the algorithm.

(3) & (1)

(5) & (6) since it’s relatively easy.

(7)

(2)

(4)

1~4 will take about one month. And 5.6 might be postponed.

[saviors-dev]

Designing End Of A Mission

The experience of the end is crucial to the whole exerience of the mission, to resolve all the emotions and complete the emotion arc. The idea is that the tension builds up during the mission, and reach the climax when destroying the machine. After the climax, players escape the level, killing everything in the way and resolve all the tension.

In the end of the mission the level will spawn a lot of enemies, to give pressure on the players. And the function is to complete the emotion arc. It is not aimed for throwing a challenge, so the players are not that likely to die in this part. I want to have crowd-control mechanics and a shoot-em-all feel, which can be commonly found in zombie shooting games.

The design of the end has to consider the level design as well. The level is designed for stealth gameplay, which is full of narrow spaces besides a few broad ones. Normally crowd control gameplay best fits with broader spaces. It is a question how to balance broad spaces and narrow ones, and how to make crowd control interesting in narrow spaces.

Given the constraints, there are some questions we need to answer.

What is the way enemies spawn? Thinking about my experience playing those kinds of games, it is the best when enemies have similar density in general so there will be a constant pressure and players are not stucked anywhere. In SOS, enemies should spawn at some certain places and run randomly. This will produces similar result if the places are well chosen.

Avoiding stealthy gameplay. Here we don’t want players to be deliberate as a resolution part. So for each enemy, on seeing players it becomes permanently awake and chases players forever.

The problem of crowd control in narrower spaces. Enemies tend to block in the ways of players. There are three possible solutions:

All enemies are flying enemies and will not collide with players.

All enemies have 1 hit points and are penetrable by shots, so players can easily clear a way out.

Enemies are not that dense. It is arguably “crowd”. Less enemies imply less emergent, and the gameplay rely more on individual AIs like Teleglitch.

Balance attack power. Since enemies are a lot, to keep the game balanced, the attack power should be enough to deal with all the enemies.

Increase (or be able to increase) fire rate. The first gun in SOS has a very low fire rate. There must be a reason narratively, like some ability is unlocked, charge the gun in some device, or players can use some items.

Enemies are penetrable by shots — one shot can kill many.

Ignitable bombs in the scene. Players can utilize the scene to destroy a large portion of enemies.

Keep players safe. The way we do it is to make enemies easier to kill when near players. We call it “negative effect” or “catch-up”. In this way, when players are in danger, they can quickly recover.

The aiming system already does that if enemies have approriate sizes, neither too big or too small.

Enemies receive more damage when near players.

Players do area attack. This is because when enemies are near players, they should be more crowded.

[saviors-dev]

Reinforcing Stealth Dynamics

This post is to explain the design decisions I made to reinforce the stealth part of SOS, which has been postponed until now.

The goal of the decisions, or the design problems the solutions trying to fix were:

Players can grind and win a level. They find and kill everything till the end, and it feels like assaulting instead of infiltrating.

Because players kill everything, upon the end the tension is totally gone and players behave less and less cooperative, which is not fun at all.

Players don’t make decisions when navigating the level. I want decision-making in players’ mind when navigating.

A game called CRYPTARK uses time limit. And after the time limit the player is constantly losing money instead of losing. This is a way to “soften” the limit. In this way, when the money reaches 0, the game is over. In CRYPTARK, the player consume money to buy any equipment, so in this game, amount of money is a measure of power, which seems to be the only way to be used together with the time limit. Otherwise if the money is used to unlock (instead of “buy") power, when players have no money, they still have the power to beat some levels and the timer loses the meaning. This design in CRYPTARK is still controversial and some players are frustrated by it.

The second idea is derived from the first one — how about time only moving when players move? This introduces the idea of energy. A player has an energy bar and consumes energy when moving. This will fix the anxiety issue but it will still will be frustrating when the energy exhausts.

Spending energy while walking might be too finicky. A workaround is spending energy when opening doors. Maybe different doors require different energy, and sometimes there are uncertain outcomes. This still does not answer the question what will happen after all energy exhausts. It is an interesting direction though.

The hypothesis is that in SOS, it is happy to die in a battle, but not happy to die peacefully. The idea is reinforcement. In Invisible, Inc, a turn-based game, enemy force constantly reinforces turn by turn, and the level just gets harder and harder. I chose a similar mechanic — after a guard is killed, another guard will reinforce after a relatively long time (20 seconds) and patrol randomly instead of along a fixed path. In this way the level just gets harder generally when players make non-stealth moves, forcing them to be stealthy.

This idea can be further refined. Maybe there is an alarm level and each kill or alarm will raise the level, and more enemies will reinforce. Maybe opening some doors will also raise the alarm level…

There will be more prototypes to explore this direction.

[saviors-dev]

Designing the Tutorials

Remade the tutorials recently, also with new introductory cutscenes, to help new players learn to play and understand the game.

I’ve made a lot of changes in the design of the tutorials, though the new tutorials are still not perfect yet for now.

Tutorials played by more than one player are actually much harder than a single player game. As long as players play games with others, they are less prone to read texts, and listen to voiceover carefully. I felt it impossible to learn Spelunky with others playing. Many online games, are essentially single player games in tutorial mode, like Heroes Of the Storm and MMOs. However, I still want to allow more than one player learns the game at a time. And I want to write a post for the design decisions made.

Separate Players

There are three set of things to learn for SOS:

Player-System Interactions

Player-Player Interactions

High-level Rules (e.g. goal)

I believe the first thing players should learn is Player-System Interactions after or before the goal of the game. In the old tutorial, players learned basic interactions together, which was not an effective one. Since SOS has stealth mechanics, players will disturb each other when making mistakes. On the other hand, a player might not understand anything after finishing the tutorials because the other is too helpful. A good tutorial should encourage player to explore and learn actively.

I don’t want to introduce a lot of new rules just for the tutorials. So the simplest solution to this problem is to separate players to do several very short challenges. After a challenge a player has to wait for the other finishing the same one to move on, so players can helping out without being disturbed. And there will also be a competitive dynamic naturally, which is good.

Minimize Texts

Given the fact that players tend to ignore texts in multiplayer games, I am trying to make the texts as short as possible. There are only 5~7 words at a time. I found images a much more powerful tool to explain something, and am trying to use images to say something with texts.

Some rules are still hard to explain with very short texts and images. It is also hard to design challenges for them. I think for some rules it is due to bad visual/aural communication.

Challenge Design

There are two ways to design a tutorial: let player learn passively or actively. It is always easier for player to learn a thing passively — just tell him/her what to do. Casual games and complex strategy games tend to explain every mechanic considering the audience and the complexity of game system.

Actively learning is learning in doing. Although those games explain a lot, they still ask player to take an action, like pushing a button, which can be seen as an active part in learning. So I want the player to be as active as possible. It is not only more interesting in this way, but also easier for player to learn.

“The best way to learn a thing is through failure.” A game designer said so. That reminded me to create challenges for players in tutorials. Failures keep player exploring strategies until he finds the right one and learns something new. Based on this, I think there is a good model for tutorial design:

The key is that players’ actions have binary outcomes, either good or bad. There are no others between, or players will be confused. Players explore until finding the right actions to do. Since a player might fail many times, we should minimize the penalty when he fails — a player can quickly get back to previous game state and try again.

There is always a naive way — setting up checkpoints and let the player restart. But interrupting the experience is not good, and we want the experience to be smoother. The perfect example would be Portal. One can say that almost the whole game are tutorials. In the game, there are only two outcomes in each challenge: reaching the gate or not. The level design of most levels allows the player to recover without restarting the game after failing a try. As a result, players are encouraged to experiment a lot.

It could be impossible to design those scenarios without setting up special rules when it comes to complex strategy games (In StarCraft, there is a challenge mode which is tutorials actually). As to SOS, it seems so just using mechanics in regular levels. So in order to teach basic interactions better, I have to specifically design some mechanics and visualize them in an intuitive way. I managed to make the mechanics as simple as possible. Visualization, however, is harder and I haven’t totally figured it out yet.

Player-Player Interactions

I think by good enemy/level design players will learn to coordinate, and a tutorial is not necessary for those interactions. The learning curve of SOS is still steep now, and I am going to design some even more elementary enemies as a scaffold to deeper gameplay.

High-Level Rules

High-level rules are not taught in the learning-in-doing tutorials. The goal of the game is introduced in intro cutscene and on the player HUD while playing. Other rules, are not taught anywhere for now. The player can only learn them by experimenting and reading the visualization.

It might be enough as long as the visualization is good. Think about Monaco:What’s Yours Is Mine. I didn’t know the goal of the game and I just followed the arrows on the floor, and somehow I just learned to play that game. I think it might be good for players to explore those high-level rules without knowing them in the first place.

There is other space I can teach something. On the loading screen I set up the tone and ask players to be stealthy. On the death sceen a random tip will come up and tell you some strategy. I am also thinking about having some collectable files in military bases and players can read them in the airship to learn more.

Now the game started with a mysterious flashback-like memory. Then the players start training. There are four challenges, teaching sneaking, crouching, shooting and advanced shooting respectively. I am trying to make the tutorials as short as possible. In theory, one challenge should only teach one thing, but I am trying to tell players that ambushing is more efficient kill as well in the last two challenges, which seems not working. I am going to tweak the last challenge or add another one.

[saviors-dev]

Migration from Boo to C#

Since Boo is no longer supported and the official site is down. I decided to migrate to C#. Boo is excellent on fast prototyping. However, it is a rough language when used in bigger projects.

There were nearly 10k lines of Boo code in my project. To accelerate the process, I wrote a program in TXL to automatically translate Boo grammar to C# grammar. You can find the project here. And I spent a whole day to fix all the errors manually. After I had done that, 12k lines of C# code were created.

The game then run like a miracle. There were no big issues. There were a lot of warnings on protection levels, which revealed Boo was rough on checking protection levels. In the later days, I fixed all the warnings. I also discovered some small bugs and fixed them quickly. The process was relatively not painful and the migration was probably a wise decision.

[saviors-dev]

Lua Local Script Editor

Made a local script editor plugin for SOS.

Features

Syntax Highlight

Grammar Check

Variable Assignment Via Unity Editor

Why Doing This

In SOS and probably every big project, there are many small things to program, like how a UI element moves after a event happens, how the sparks are animated and influence the environment, how is the light looks dynamically and what to display when player enters an area. They are all very small and slightly different from each other. It is hard to write a super generic thing to include all of them. Since I already have 200+ script files and a lot of prefabs, I don’t want to write a script for each little different mechanic and separately create a prefab which is the only place the script is used at. This would mess up the project folder quickly when I prototype a lot of small mechanics. I would rather make the prefab and the logic into one single file so I can easily organize them.

At first, I was using PlayMaker for this task, and it worked very well. You can attach the FSM to a prefab to prototype new mechanics. Later the drawback emerges: PlayMaker is very unwieldy on simple tasks with no FSMs. I also tried to write a plugin that is sort of like visual programming, but it was too much to work. Later, I used this idea: just use Lua.

Implementation

I looked for lua interpreter that is compatible with .NET. First I used a project called slua, which seems to be fastest solution of lua interpretation. However, the documentation is not that good and I can hardly extend it for future. I chose to use NLua, a pure .NET solution, which seems to be nicer.

Future Work

A lua REPL in Unity Editor might be good.

Conclusion

I already used this to make small mechanics. It also reduced the compilation time. I actually didn’t spend very long time on this and I think it will accelerate my workflow a lot!

[saviors-dev]

Great progress after graduating: I found the missing piece

I went to Playtest Thursday at NYU Game Center this week, to test the latest build of Saviors, which is renamed by Squad Of Saviors (SOS) now. It is the first build with procedural generating levels, and guard reinforcement when players kill a guard. I am so happy the new build works very well and it becomes a much better game. Now it just needs more balance.

I think I found the missing piece. After putting the mechanic that whenever player kills a guard, a new guard will enter the building in 20 seconds, the game feels much more stealthy and cooperative. The players are no longer able to kill everyone. They have to be cautious about every move and every kill. The game has a second-layer choice-making on top of sneaking and shooting.

The framework of procedural generation works very well. I thought about many different algorithms and I was lucky to choose the simplest and a good one. Players can separate and flank some rooms.

I was always thinking the game had a piece missing, and had many proposals in my head. The reinforcement idea was inspired by Leandro and Invisible, Inc, and was come up several months ago, but the details were not there yet. I also had other ideas like the players spending energy when running and opening doors, timers in some areas, increasing alarm level when opening some doors. There were many design-y ideas, and I did not know which one work the best.

“Try each of them.” Designers would say so. I think all of them will sort of work. But each of them requires a lot of work because each idea is not only one mechanic -- it has to introduce a dozen in order to be tested. I think foreseeing the result of ideas is really important.

I think in the end I found the best solution, which reduce my work a lot. And I think to think more and remove some design options before prototyping it is necessary.