“Legato” Project Tech Postmortem

1. Document early, document as you code:

We have a event system for network communication, and usually the event sent in one platform is handled by another programmer who work on other platform. Therefore we create a google spreadsheet to track all event, whoever call the event should write down when they’re called, what are the data sent along, and how it should be handle. This is an easy and helpful way for documentation that we are seldom confused by those sixties events.

Some of the code is poor documented like the path editor I made. It supposed to be very easy but it end up having more communication cost as we start using.

2. Tech meeting for finding the “best practice”

If we do it again I wish we spend more time discussing the structure of the code before starting a task. Right now a lot of stuff are created in a hurry and their implementation are naive.

For example what’s the best way for enemy wave editor for a “shmup” game? Should it be procedurally generated? Or premade prefab? Right now the waves are arrays of enemies that procedurally generated them at certain time. This is totally make sense in our scenario. But when I was making the tutorial I have to not only make enemy waves but also add some scripted events. In this case I make the waves a link list of premade prefabs that I can add stuff in between events very easily, which I feel is more efficient. And maybe I’m wrong or maybe there are better solutions that I haven’t found.

Another example is whether that game should be in one single scene or separated to different ? It makes sense if we put the menu into different scenes, but then we may need to restructure a lot of things like making something class singleton.

3. Consider automated QA

We didn’t do it this project, but definitely consider in the future if there’s a team like ours. Since we have so many programmers, one small change in one’s code may cause an error in other’s. It would be nice if we have a way to find out if our latest code is bug free.

Another reason automated QA is important is that our device is super hard to test by one self. We already have debug keys to fast forward some login process, but it would be nice if it’s more structured and consistent and generated actual user input.

Also, at the end of semester we actually have no space on keyboard for “debug key”, so it would be nice to have a console system to send debug commands and automated test functions.

Organic QA tester is viable but not recommended in ETC.

4. Make Juicy Feedback. Polish Early?

This is just my random thought, but I think it make sense if we assign one artist and one programmer do the “polish” part early. Ex: We could actually start working on the on-hit feedback as soon as we decided our theme.

In fact this is about how you define your “minimal viable product”. For a battle oriented game like ours, I won’t call it a game (product) if it lacks of juicy feedback. Therefore I strongly recommend that programmers should implement this kind of features as early as possible.

Analyzing On-Hit Feedback in Action Games

Summarize on-hit feedback into 5 categories:

  1. Animation: Animation should be exaggerate, responsive.
    1. Responsiveness: The “preparation” of an attack should be minimize, much faster than real life.
    2. Exaggeration: Movement should be identifiable in any angle. Sometimes you can show only the ending frames to exaggerate high speed.
  2. Physic. Heavily related to animation, especially when using root motion.
    1. Newton 2nd Law: Should players knocked back, or punched airborne?
    2. Newton 3rd Law: “Lagging” effect on hit. Interestingly, Soul Calibur series completely ignore this effect to speed up the pacing of the game, while still deliver excellent feedback.
      1. Is it possible to do this effect in multiplayer games with more than 2 people?
  3. Particle Effect:
    1. Flare or lighting for exaggeration. Most game has a sparkle effect when something harmful hit someone.
    2. Shader: Distortion shader or somethings cooler.
  4. Camera:
    1. Camera Shake: Someone has said that “Camera shaking is the easiest way to make a game look polished” Note: League of Legend has no camera effect, but still have okay feedback which primary from particle and sound effect.
    2. Cut. In some fighting game when a player temporary lose control to the character (like performing grabbing), the camera will switch quickly between several cuts to make it looks more dramatic. EX: CQC in MGS 5, grab in Soul Calibur.
    3. Screen effect: Warping effect showing player is dizzy; Bloody effect showing heavy injury.
  5. Interface Highlighting:
    1. Flashing effect on the object getting hit.
    2. Text animation. (WOW critical hit; LOL gold earned animation…)
    3. Juicy GUI Effects. (Soul Calibur health bar animation)
  6. Sound:
    1. Dark Soul 2 has little visual effect when hitting enemies object, but has a very distinguish high frequency sound cue when hitting, and higher frequency sound when enemy dies. (Interestingly, it still has quite a lot particle, shader, camera shake effects when hitting environment. )

Notes of some Animation Tricks for Games

1. Squash / Stretch

2. Anticipation. Ex: Music before event; Facial expression before speaking; Fireball effects before boss.

3. Staging: Readibility (?) / Rule of Third / Frame within frame

4. Straight ahead  & Pose to pose

5. Follow through & Overlap (Inertia)

6. Arc: Every motion should be arc instead of line.

7. Secondary Action. EX: Do other things when talking.

8. Time: Different speed for every action

9. Exaggeration

10. Strong Drawing. Reversal between poses. Avoid twining

11. Think Process. Animate what character “think”.

Postmortem: Ocean Empire


The goal of this project was to make a game that showcases the capability of Roblox Studio, in addition to providing Roblox with the framework to expand the game on into the future. With this goal in mind, team Atlas created Ocean Empire. Ocean Empire is a multiplayer, ship building/battling game for iPad and PC. Players can customize their ship by adding various components with different attributes, allowing them to build a ship that fit their own particular play style. The players then use these ships to sail the high seas, gathering resources and battling up to 5 other players through the Roblox servers. The game has already been published to Roblox, and is in the process of being ported to an iPad application. Ads will also be posted on the Roblox website to generate further interest in the final release.

What went right

Choose the right theme

We chose the “Naval Ship Battle” theme as appeals to most audiences. Being a universally recognized theme, the player has some preconceived notions of how to play the game, while at the same time the game provided a new and exciting experience. Through research of AAA titles such as “Assassins Creed 4”, as well as casual games like “Seafight”, we realized that despite a considerable amount of naval combat games, there was a lack of games emphasizing the customization of your ship.

Building interface: Tool or Toy?

We struggled with different building interfaces at the beginning, requiring a great deal of iteration. At first we chose a building mechanic similar to Water +, an ETC’s project from last semester, requiring the player to click the item first then click again at the target location. Through play-testing we realized that this interaction was not at all intuitive on the iPad, requiring a great deal of verbal instruction so people could understand how the interface worked. This was resolved by instituting a drag and drop system, which further play-testing revealed to be more intuitive, allowing people to build their ships with no verbal instruction. Later, a removing/relocating mechanic was instituted, allowing them to freely move any items on the ship, changing the whole feel of the game. Since the building process has become so easy, the building interface is more like a “toy” than a “tool”, as a toy is something fun to play with, even without having a goal. In our latest playtest, we’ve seen some players spending a lot of time in the building mode, changing different components and layout even though they know it’s only half the game.

Follow the fun

Through our research, it was obvious that battle is the most intriguing part in most naval games, which prompted us to propose a combat-heavy game from the beginning. This worried the client, as they feared the Roblox engine might have difficulty handling large battles. We explored many other possible mechanics like exploration and treasure hunting, but none of them seemed to fit. We decided to put cannons on the ship regardless, and found that the gameplay suddenly became exciting. After discussing it with the client and working around the technical limitations, we implemented solutions that would allow for small, player vs. player naval combat. We now know that it is better to follow the fun, than to pursue some idea without the same potential.

Release the game on Roblox’s website early

We had published our game on the Roblox website one week before Soft. Occasionally there were random people visiting the game, some of whom left constructive comments, which we in turn answered. This became important because it was our first time developing a game for this demographic, and the website help us get close to our audience and understand their needs.

What went wrong?

Missed the Focus Groups Testing

Focus groups are sessions where potential players are interviewed about their likes or dislikes. We wasted a lot of time “guessing” what kind of game is better, but what we should really have done, is reach out to our target demographic and ask them what they’re most interested in directly. This is something we could have done on the Roblox forum, but we were too focusing on the traditional brainstorming process. One of the major pieces of feedback we got from many of our play-testers was that they felt they needed more weapons. This is a function that sounds very obvious in this kind of game, but one that we didn’t anticipate at the beginning. We were afraid the screen may become too crowded, making the buttons used to control the guns hard to control on iPad. However, our target audience seemed very excited about the combat, and after adding more weapons, it was apparent how much more interesting it made the gameplay. A system if shooting all of the guns at once allowed for a simple, multi-weapon setup.

Underestimate the Technical Difficulties

All of us were new to Roblox Studio. To get familiar with the tool, our programmers made a top-down shooter prototype in one week. Despite growing more comfortable with the program as we progressed, that progression was not without its difficulties. These problems were usually quickly solved by creative problem solving, and in the hardest of cases, through help from the Roblox team. Roblox provided us a technical question forum, which allowed their engineering team to answer our questions very quickly. When we made the name tag and health bar on your opponents’ ship, there was no built-in function that make a 2D GUI using screen coordinates to follow a 3D object in world space. We had been stuck on this problem for a whole day, at which time we reported our difficulty on the forum. The Roblox staff read our question and sent us some code to fix it, saving us a considerable amount of time. Despite a great deal of debugging, we still encounter some bugs that we don’t yet know how to fix. For example: the welding (a special function in Roblox that connects two objects) breaks occasionally when too many players are in a server; visible glitches appear when we shrink the hull; Some objects don’t appear on iPad, and we don’t yet know if that is caused while loading, or if it is an issue in our code.

Underestimated the Time Needed for Quality Assurance in a Multiplayer Game

The multiplayer is a built-in feature of Roblox Studio. Therefore, we didn’t need extra code for game matching or online performance. Knowing this caused us to underestimate the amount of time needed to test in multiplayer. Some systems in the game worked perfectly in single player, but caused problems when more players joined the server. It was hard to track these problems because we can’t access the built-in functionalities, leaving us to try and find the bugs early and fix them. To solve this problem, we had an “Ocean Empire Hour”, when all members in the team would play the game and report the bugs on a spreadsheet.

Aimed on physics heavy game early but it became even buggier

When we started researching games in Roblox, we found that some games used Roblox’s physics engine to create some excellent effects, for example, the destroyable objects and water physic. At first we wanted every component to affect the physic of the ship. For example, a ship may sink after setting sail because it had been overloaded, or may be toppled if the load is unbalanced. However, through testing and discussion with the Roblox team, we determined that the capability of the physic engine is actually very limited. It can’t specify the weight of an object, making it hard to give ship components different weights. The physics engine is also unrealistic in that a large object made of wood will still sink into the water, as the engine pays no attention to material. After halves, we decided to give up most elements related to physics, and use code to simulate the real-world effects.

A Game Concept that nobody have seen before.

One piece of feedbacks we got from those who played our game at soft, was that they were unsure of the goal. This may have been, in part, due to our use of an unorthodox game mechanic, requiring rules that most people had not seen before. The original pitch of this game was “Simcity meets Shipbuilding meets Naval Combat”. We wanted to make a persistent world set in an intriguing nautical theme, allowing players to explore the islands and make use of a complex trade mechanic. However, due to technical constrains and scope, the maps size is limited. This prompted us to create an arena-like level with randomly generated items. For the combat genre, the level and interface usually explain the goal of the game. The arena-like level leads people to believe it is a short-term experience, but as they progress, we want them to keep getting resources and upgrading their ship. It’s okay to have a tycoon game without an end state, allowing the player to keep expanding, and in the case of Ocean Empire, giving them the unerlying premise of arena combat as a purpose to build their ship. Our solution to reinforce a sense of purpose was to provide a back-story for this game. This backstory was then reinforced in the promo video, as well as tutorial. At the end of the tutorial, your captain’s dying words are “avenge my honor”, establishing a simple premise to further reinforce the gameplay.

Not enough background knowledge

We decided to make a shipbuilding game a little late, which force us to start designing the mechanics in a hurry. If we have time to research about how ships are actually being made and design based on reality, the game would be more intuitive and meaningful.

Auther: Chih-Wei (Jerry) Chen
Proof-Read, Edit: Joel Ogden

Research About Tower Defense + Shooter


Black OPS Orc Must Die!
Space Start from 5 rooms, extends over time up to 10 rooms Big dungen
Object Trap, Bar, Pickup ??
Action Shoot, Shoot, Placing trap, upgrade
Skill Shooting, Ammo managing, Escaping, level experience, Upgrade order, shooting, trap layout
Chance Zombie position
Rule Waves of Zombie until you die Waves of Orcs until you die

For a successful shooter game, we first have to fulfills the players’ needs of competence. That is, a good Flow curve.

The game can be very easy at the beginning, but at certain point, difficulty increase, something block the players. There are some obstacle ahead and force them to learn something in order to proceed. The subtle difference between shooter game, is the different things people learn in the game. In other word, the skill they need in the game.

In my interpretation of Self-Determination Theory, the reason why Competence is a intrinsic motivation for human is that people like to do something they’ve used to, something they spend a lot of time practice, and feel confident and comfortable to do it repetitively. But learning a new thing is always painful at the beginning, so a good game can pack the boring learning process to some engaging experience.

I’m try to find out why TD + Shooter is a good combination. Maybe the first thing is, you don’t have to learn anything to just have fun. Both game looks extremely stupid in the first few level, you just have to learn how to use mouse and keyboard.

But people still die in this game. Even they think the game is stupid, they’ll graduate realize they have to learn something to cross the barrier.

In Black OPS, they research their weapon to get the best DPS. They research the map about every trap and trigger that help them in battle. They also try to understand the enemy behavior, how they spawn, how they move and how they attack.

In Orc Must Die, player have more autonomy in action. They can customize their characters and place traps freely in the map. Obviously, that also means they have much more things to learn.

When making a new FPS game, think about what they should learn, and how to make them feel confident and willing to play repetitively. Remember that lots of successful titles in the game history don’t have much innovation.





Game Industry Prediction

Some quick thought about the topics mentioned in last lecture:

1. E-Sport will become be adapt by non-gamer audience and the business model will be more similar to NBA.

2. AR games won’t have much progress. The most useful AR function will be the map.

3. HMD will be the standard hardware for motion control games. Software is still the key. Facebook have a vision of how killer HMD software look likes, but can’t compete with major console companies.

4. The key of a successful VR device is a hardware that support 360 degree movement detection, which is not constrain by the screen in front of the player.



During this semester, we ran through a lot of brainstorming process. Sometimes an idea may sounds convincing at the beginning, but the result is frustrating. In one of the blog review, I saw another student mentioned on his blog that, unlike Human-Computer Interaction (HCI), game designers don’t have a “design pattern” that they can follow. At that time I don’t think it’s even possible to have a design pattern in game design since we have so many different genres. How is it possible to have a rule that fit for all genres? But in the GDC this year (2014), I was lucky to hear an insightful talk about system agency presented by Matthias Worch. The “Self-Determination Theory” he seems match my question quite well. I think it could be a useful tool to give designer a clear guideline of game design.

There are already many articles and books that touched the topics about “rules of good game design”. Some of them are very good, like Jesse Schell’s The Art of Game Design. In this book, there are a lot of lenses that help designer to exam if their current design choices are good. But sometimes the problem is, we don’t know what the problem is, therefore we don’t know which lenses we should refer to. For example, I may be very focus on combat of the game. But it’s possible that the art style is the reason of stopping player from buying the game. Most of the time, following one design rule can’t guarantee the game is fun. I’ve seen someone try to make a game that caters to all types of players in the Bartle’s players’ types, which is nearly impossible to achieve. And in fact, it is totally normal that a good game only cater to only one or two type of player in Bartle’ types. Therefore, we can’t use Bartle’s types to determine whether a game is good or not.

Experienced Game Designer always talks about “this feel interesting” or “I’m skeptical about this mechanic”. I think Self-Determination Theory might be a solution to clarify the instinct feeling, and turn it to a more standard process.

The basic concept of Self-Determination Theory (SDT) is that humans have three intrinsic needs: CompetentAutonomy and Relatedness. A good game should satisfy these needs. The need for competence and autonomy is the basis of intrinsic motivation and behavior. This is a link between people’s basic needs and their motivations.

Here are the reasons why SDT might be a good “design pattern” for game design. First, I found that almost all games I like provide players the three needs mentioned in SDT. I know it’s hard to proof reversely (in which the question becomes: Does following SDT make the game fun?), but still, it could be a requirement of good game. And having some requirements usually makes our lives easier. By checking the three intrinsic needs, you get a clear sense of what’s lacked in this game.  If a game obviously misses one of the intrinsic needs, it might be the weakness of the game. On the other hand, if the game meets all the needs, it probably in a pretty good shape even if it don’t have many innovation mechanics. This is a good way to evaluate a game at early stage, and find potential problem systematically.


Let’s see the explanation on Wikipedia first:

SDT is centered on the belief that human nature shows persistent positive features, that it repeatedly shows effort, agency and commitment in their lives that the theory calls “inherent growth tendencies.” People also have innate psychological needs that are the basis for self-motivation and personality integration.


SDT identifies three innate needs that, if satisfied, allow optimal function and growth:


Seek to control the outcome and experience mastery


Is the universal urge to be causal agents of one’s own life and act in harmony with one’s integrated self?


Is the universal want to interact, be connected to, and experience caring for others?



And below is how I would use SDT in game design.





“Seek to control the outcome and experience mastery.”

A game fulfill the need of competence means that player feel they are having progress in the game. To be more specific: how well is a game keep player in Flow state?

One good example is Monster Hunter. This game is designed to be very skill-base. When you first encounter a dragon in this game, you’re almost guaranteed to die. The only way to progress is to keep trying until you’re out-skill the AI monster. After you defeat the first dragon, you can clearly feel you become more proficient in the game.

The reason I take this game for example is that, in Monster Hunter, they force you to feel competence. In other word, if you don’t improve your skill, you’ll be stuck in a bottleneck forever. And here’s the secret of our brain: When one is master doing something, he/she will want to do it again and again. That’s why there are people in Asia spend hundreds even thousands of hours playing Monster Hunter. People like to stay in their “comfort zones”, and fulfilling the need of competence is like creating comfort zones for players. Players intrinsically feel it is fun because they’re good at doing it.

When designing a game, one specific way to make sure your game fulfill the need of competence is to design the skill-time diagram carefully. In other word, make the players stay in Flow state. You have to know at what specific point the player will be stuck, and how to help them improve their skill.


“Is the universal urge to be causal agents of one’s own life and act in harmony with one’s integrated self?”

A game fulfilling the players’ need of autonomy is a game with enough meaningful choices. A meaningful choice, in my definition, is a strategy that can be a dominant strategy in at least one circumstance.

Pokémon is a game that have crazy amount of meaningful choices. Even in early level, you can have different strategies like all-in attack or weaken the foe first; you can spend more time to train different Pokémon, or let the protagonist face the most challenges. You don’t need much controlling skill in Pokémon, but it is extremely satisfying that you know how freedom the world is, and you can choose what you want to do.

In Matt’s talk in GDC, he mentioned that Doom is a classic game that provides autonomy. In this case, the choices are taken in real-time. For example, you can choose to kill the closest imp because it’s the easiest target, or you can seek the zombie behind because it will be more threatening after getting closed.

As a game designer, it’s tempted to add a lot of choices in a game. I don’t know what to say here.

There are already many articles about meaningful choice.


“Is the universal want to interact, be connected to, and experience caring for others?”

Games fulfill the need of relatedness are games which have something people CARE about. It could be a story happened in the similar culture background, a city that player familiar with, or a character they love.

The reason why World of Warcraft succeeds is that it is a world people already know very much. For players familiar with Warcraft 3, visiting Thrall in Orgrimmar is like meeting with an old friend. WOW did a lot of good things to establish the standard of MMORPG nowadays, but its success model is more like Disney Land. The success of WOW is not because the gameplay is better than other, but being part of the transmedia world, and fulfilling the players’ fantasy of this world. After all, experiencing a believable world is why people play MMORPG.

For me, Tunnel Tail is a negative example of relatedness. In this game, you manage a mice colony. Although the mechanic and art is very attractive to me, I just couldn’t care much about the destiny of a mischief of mice. Children like animal because they don’t have much difference in intelligence yet. As we grown up, we gradually find out that we have little in common with animals, that’s probably why I have no relatedness with animal characters anymore. Therefore, most main stream games have to make human character to keep players related to the game.

Social game is a perfect way to provide relatedness. Because once your friends start playing, the whole game becomes related to you.

As a game designer, we have to keep in mind what’s your audience want to relate with. Social elements, user-generated contents are good ways to keep players caring about the game. In Taiwan, the localization team even adds some events and items about the Chinese festival, which create a cultural relatedness between players and the game.


When we have a new idea in mind, we can ask ourselves: “Does it provide the three intrinsic needs? If not, how can I improve it?” And then we can design the game like filling the checklist. Also, people are less possible to question your idea because these points are based on some psychology research. Using this method as a design pattern, designing game can be much easier.