# Sane Usage of Components and Entity Systems

With some discussion going in a previous article about how to actually implement some sort of component system for a game engine, without vague theory or dogma, a need for some higher level perspective was reached, and so this article arose.

In general an aggregation model is often useful when piecing together bits of functionality or data to create something new. The ability to do so is very useful for writing game-specific gameplay code due the flexibility of code granted by aggregation. However as of late there’s been tremendous talk about OOP, Entity Systems, Inheritance, and blah blah blah within the online indie development community. More and more buzzwords get tossed around by big name writers and the audience really just looks for some guidelines to follow in hopes of writing good code.

Sadly there isn’t going to be a set of step by step rules for writing a game engine or coming up with a good architecture. Like many of said before me, writing a game is a specific task requiring specific solutions. Why do you think game engine developers such as Epic or the Unity guys have so many people working on the product? Because a generic game engine is a huge piece of software that requires a lot of features. Some features exist simply to let users add in custom features easily.

Components, aggregation, Entity Component Systems, Entity systems, these are just words and have various definitions (depending on who you ask).

## Some Definitions

To hopefully avoid silly arguments and confusion lets define some terms. If you don’t like the definitions here feel free to express so, I’m all up for criticism and debate.

• Component Based Architecture
• A preference for aggregation over inheritance. Is just a concept and does not lead to a single specific implementation. A game object is a collection of components. A component defines data and/or functionality for a concept.
• Entity Component System (ECS)
• A specific implementation of Component Based Architecture. A game object would be an ID (an integer). The ID is used to form an aggregate. Usually an ECS implies an implementation similar to a database, where components are entries into a database that are looked up through some identifier. The main goals of this implementation are efficiency and simplicity. Often times the term “ECS” is used just to describe a Component Based Architecture, often leading to confusion.
• Aggregation
• I like to think of this as a “has-a” relationship over an “is-a” relationship. Aggregation refers to one object “having” another object, which implies an aggregate is a collection (data structure) of other objects.

## Some Truth and History

Aggregation is useful from a game design perspective. It frees functionality from arbitrary classification (classes and inheritance). Classes were originally created in C++ to let a programmer tie together a piece of data and some functionality to represent some sort of real-life concept. This is in simplest terms the essence of Object Oriented Programming (OOP). Over time more features were added to help engineer relationships between classes, one such feature came in the form of inheritance.

There’s nothing inherently wrong with OOP and it makes sense in a lot of code. Problems can arise when there’s a mis-application of OOP that has implications that aren’t fully understood at the time of implementation that cause negative affects down the road. I’m sure we’ve all seen the code migration and mega-class example so commonly thrown around in articles arguing against OOP and inheritance abuse.

In response to such an abuse a new paradigm became popularized which focused on aggregation of functionality to form an object. This might be called a “component based architecture”. In general aggregation can be considered an appropriate alternative to inheritance.

## OOP Diatribe

Usually when an article spews forth caustic attacks against OOP it’s directed at naive implementations that disregard implications of how memory is accessed. Perhaps in the past the bottleneck of most everything was processor speed, so a lot of literature focuses on this. Nowadays CPUs on the PC have an architecture that have ridiculous computational power with extremely limited memory access. In general one might consider accessing memory from RAM 300 times slower than multiplying two floats together. Of course this last statement is extremely anecdotal without any evidence, but exists just to give a rough perspective of reality in many current (2014) cases.

If objects with associated code (classes) are just allocated and deallocated on the heap at will then a performance bottleneck of memory access is going to rear its ugly face, likely long before other performance issues are even on the radar. This is where much of the diatribe comes from.

It should be noted that pretty much all code bases that make use of the C++ language use classes and structures in some form or another. As long as a programmer has an understanding of memory, how it’s accessed, and what implications arise from given implementations, nothing will go wrong. Alas, actually doing these things and writing good code is super hard. It doesn’t matter if a class has some implementation code within it, so long as that bit of code makes sense for the purposes it is serving.

## Implementing Components, a First Draft

The most immediate implementation would be to make use of multiple inheritance. This has a clear definition of where the data goes, and it all goes in one class -the derived class. Multiple inheritance itself can get a bit tricky when dealing with pointer typecasting between derived and base types, though the C++ language itself handles the details much of the time.

Inheritance alone doesn’t provide a good mechanism to query whether a base class is apart of a specific derived aggregation and so the dynamic cast operator is born. Since the dynamic cast is a branching operation, usually implemented (afaik) by inspecting the vtable, it is avoided in general.

Multiple inheritance also does all sorts of work to member function pointers, and is just a sad part of C++. Additionally there isn’t any language feature that allows for dynamic dispatch for combinations of base classes, so if the need arises a custom solution will need to be implemented anyway.

Memory accessing, although defined, isn’t ideal. Multiple inheritance forms a blob of different data, and usually only a single piece of the blob is needed at any given time, meaning locality of reference will be poor in general. This leads to the idea of inheriting from multiple interfaces in order to decouple memory aggregation from functionality aggregation, which leads to the next draft.

## Second Draft – Run-Time Aggregation

Instead of using multiple inheritance on interfaces, which is a compile-time feature, run-time support can be added. Object aggregates can be formed during run-time, and modified thereafter. This is appealing for data driven applications, and game-design friendly development iteration speed.

So lets assume that some programmer wants to implement components, but doesn’t think much about memory access patterns the implications therein. Using a vector of pointers an implementation of components becomes super simple. Each pointer can point to an interface exposing a few functions like Update, Init and Shutdown.

Searching for a particular component is as simple as linearly looping over each pointer until a matching type is found. If these pointers are ordered in some way a search can be performed, perhaps a binary search could suffice. If the identifier of a component is hashable a hash table lookup can be used.

The implementation so far is an excellent one except that there is no definition of how memory is allocated and accessed! In the most naive of implementation each game object and each component will be allocated on the heap with separate calls to malloc.

Despite having no clear memory definition there are some nice benefits that have arisen. Data driving the composition of an aggregate becomes quite trivial as each component of an aggregation can have an entirely isolated lifetime. Adding, removing, modifying, or even creating new components at run-time are all now possibilities. This dynamic aggregate architecture is great for improving game development and design iteration time!

## Aggregation and Components and the Entity System Paradigm (ES/ECS)

As stated in the definitions section, an ECS is just a specific implementation of a component based architecture. A component based architecture game engine architecture would be a custom implementation of multiple inheritance. A clearly defined ECS can impose restrictions on how a component architecture is implemented and used in hopes of avoided poor memory access patterns, or in hopes of keeping code simple and orderly.

If a component is designed as a piece of memory without any code, and a game object defined as an integer ID then performance specifications can be easily imposed. Rules about where in memory components lay, and how components are actually accessed can be clearly defined in simple terms. Code can be written that operates upon arrays of components, transforming arrays linearly. This idea is actually a type of Data Oriented Design (DOD), which makes sense as DOD is just an idea! ECS is an application of the idea of DOD.

So with this type of implementation the benefits of dynamic composition can be paired with well-defined memory layout and access patterns. Suddenly prefetching and parallelism become much simpler to support.

## Aggregatize all the Things!

There’s a problem. Blindly shoving the idea of an ECS implementation into every nook and cranny of an engine during development is just silly (or any complex system, not just game engines or libraries). Often times a particular system is not best implemented with a component or aggregate paradigm in mind.

An obvious case is that of a physics engine. Often times a physics engine developer is worried about collision detection, solving systems of linear equations, rigid body mechanics and allowing the engine to easily be integrated into existing code bases. These details involve a lot of math and good API design. A developer of a physics engine is going to have their focus employed in full force in solving problems specific to physics engines. This means that the engineer’s focus is finite, so the implementation that is best is one that the engineer can actually bring to completion. An implementation that can come to completion is one that makes sense for the specific details of whatever is going on inside the physics engine. The specific paradigms used are often not aggregation or component based!

In order for a physics engine to run fast it needs to have efficient memory access patterns and memory usage, on modern PC hardware, requires some form of DOD. Since this complex (often black boxed) physics engine will have it’s own specific implementation and optimization it doesn’t make sense to force a component based model to its very core with some sort of idealistic zeal. It gets really bad when strict rules are imposed (like banning all code from classes and structures that define components) on the component model (like with an ECS) and the rules start permeating the deep recesses of the entire code base.

The same thing goes for any sort of complex system. The core facilities of a game engine often times just don’t really care about components or aggregation. This means that an engine architecture that implements components will usually have to deal with middleware graphics/physics engines/libraries that don’t subscribe to a component based model (simply because it’s easier to use a library than to write your own custom things, especially if those custom things religiously follow some silly methodology like ECS or even OOP). In practice light wrapper components can be created to let the functionality of such systems be presented in a component format, ready to be used in an aggregate object.

## What does this all mean? What should we all do?

Use components where it makes sense in code. Use inheritance where it makes sense in code. Use databases where they make sense. Use all the things where they should. This is a pretty sad answer but it’s the right one. There is no silver bullet paradigm that solves all the problems in the game engine architecture world, and there are no steps to follow to achieve a result that works in all cases. Specific problems require specific solutions. Good code is hard to write, and will require a lot of judgement calls. In order to make good judgement calls a lot of experience and perspective is required.

I recommend using aggregation where it really matters. Dynamic aggregation is important for gameplay specific code. Gameplay specific code, in this article, would refer to code that would not easily apply or work at all in a different game. It’s code that is your game and doesn’t define an isolated system or functionality.

Dynamic aggregation and the component based model are extremely important for game and object editors. Game design flourishes best when iteration times are driven to zero, and the ability to create new things from a composition of fundamentals is very valuable! Clearly composition is useful, but how it’s to be used is the hard part.

## What Components to Make?

I recommend making components concerned with providing access to game-independent functionality to be quite large. Every 3D game engine has a concept of a mesh, and will usually have some sort of file format to associate with, like FBX. Every 2D game engine will have the concept of a sprite. Each game using Box2D will have colliders and rigid bodies, and possibly joints. These fundamental pieces of functionality don’t change very often, so static compile-time relationships aren’t a bad thing since iteration time isn’t really all that relevant.

A 3D game might have a single Mesh component for example. A Mesh component can have renderable vertices, and possibly all the skeletal and animation information as well. There may be a single Rigid Body component, which encapsulates the idea of colliders or shapes, as well as the functionality of rigid body mechanics. The Rigid Body component might even contain all necessary code and data to hold multiple joints! Or joints may be a component themselves.

For high level and gameplay related features components can become much more granular (or not if you so choose). Gameplay should be iterated, tested and changed frequently, so having small and decomposed components will probably make a lot of sense in a lot of cases. Large components that encompass more broad ideas will be useful in many cases too. Even in the gameplay world judgement calls are essential.

Usually efficiency isn’t so important for much gameplay code, so any implementation that is decently performant will suffice. Scripting languages, dynamic memory allocation and virtual dispatch, or what have you can all work. The decisions of what requires flexibility, what requires performance and all between can be difficult to make. Please see the references section for some concrete examples.

We live in a world of opinions and it takes time to sift through them! If you have recommendations please comment below :)

## Reference Source Code

The best reference I know of is an open source game engine in progress (stalled until I graduate) I myself am developing. Please do send me your recommendations on references!

Share

# Volgarr the Viking

Wicked Snake and Volgarr promotion Art by Kris Durschmidt

This article dedicates itself to sharing details about the most exciting game to release within the past DECADE. I’m a a gigantic fan of both SNES and Sega Genesis games. I’ve fallen on love with some Nintendo 64 games as well, but nothing really beats my early childhood experiences with the SNES.

That said, it only makes perfect sense as to why I’m now writing about Volgarr the Viking. As of now Volgarr the Viking doesn’t have a website dedicated purely to itself, so you’ll have to check out its KickStarter page in the meantime. In short Volgarr the Viking is “an arcade-style platformer that hearkens back to the golden era of arcades”, as summed in the aforementioned KickStarter video by artist Kris Durschmidt. Volgarr is the main character in Volgarr the Viking, and there never existed a viking so awesome and hardcore until now; even the name “Volgarr” resembles the word vulgar, and just leads one into feeling Volgarr is both vulgar and brutal.

Volgarr the Viking

Volgarr the Viking currently undergoes development by Kris Durschmidt and Taron Millet, two game development veterans who have worked on many big-name AAA titles. The last sentence alone should be enough to convince many that this game is going to warrant excitement. The two seemed to have left their well-paying positions in order to work on their own in order to create a game that they truly love and enjoy. Judging by the amazing KickStarter campaign, wonderful promotional art, and enticing Alpha gameplay display Volgarr the Viking will be a huge success.

Here a couple videos, inside of a clickable spoiler, recently put up on youtube displaying various players who have access to the Alpha development build:

Keep in mind that the above videos are of an unfinished game! There may be missing or strange artifacts and whatnot. In my opinion this game looks extremely polished, and can’t imagine what things will be like on release.

Lets start talking about some of the game mechanics present within Volgarr the Viking. The developers Taron and Kris both expressed how much deep thought was put into the creation of their core gameplay mechanics. Within the KickStarter video there were explanations of other various games that they drew inspiration from. They also seemed to have taken great care in placing their own unique style into Volgarr the Viking.

What stood out to myself most was the reminiscance to the game Super Ghouls’n Ghosts for the Super Nintendo. Lets talk briefly about Super Ghouls’n Ghosts (SGnG).

Screenshot of SGnG taken from a SNES Emulator

Released back in 1991, SGnG is a game of a knight who must venture through lands of zombies and demons in order to save his Princess, which was stolen in the game’s introductory cut-scene.

The gameplay consists of platforming and throwing various types of weapons. The armor of the knight can be upgraded up to three times, and when upgraded provides boosts to weapons, and other various abilities. When hit the player’s armor falls off, leaving the player to run around in mere undergarments.

Today still SGnG can be regarded as one of the toughest games ever made. Despite the difficulty of gameplay, the gameplay consistently stays at a very fair level of interaction with the player; no matter what happens, if something negative happens to the player (hit by enemy, losses a life) the player almost always feels like it entirely fair. SGnG was carefully designed so that a player can master the very mechanics of jumping and throwing, and play the game in a truly impressive manner. There are three main points here I want to make note of:

• Jumping in SGnG is unique.
• SGnG is highly difficult to master, yet incredibly fair (most of the time)
• Simple mechanics are expounded upon in many interesting ways

Starting with the first: jumping is unique. Whenever the player jumps the trajectory of the jump cannot be changed once in mid-air. This makes sense physically, but many games allow the player to influence their direction of travel after jumping. MegaMan games in particular are famous for allowing this. The ability to influence a mid-air jump allows the player have fine-grain control over their movements, and as such interesting interactions with platforms can arise. SGnG took a completely different route, and to great affect.

Careful planning and tight decision making are required in order to platform from place to place with the knightly character. The original game designers took great care in laying out their levels to accommodate such a unique jumping mechanic. Seeing a masterful player jump and dodge enemies and projectiles in SGnG is sight to behold. Mastering SGnG isn’t an easy task. The quirky jump mechanic along with the limitations of throwing projectiles make for a very difficult game to beat. However, this doesn’t deter a lot of players from continuing to try again and again to fight their way through the ghoulish levels. This is due to the fairness of play. Fairness of play in SGnG particularly seems to arise from careful level layout; rarely does the player encounter a situation they didn’t have a chance to learn about in a controlled environment.

For example in the first level of SGnG the player starts in a fairly flat area with no nearby enemies. Then some zombies start walking towards the player. After introducing jumping, weapon throwing and basic combat, the player then experiences a loud grumbling as the ground of the level itself heaves upward, changing the terrain in real-time. This terrain chance happens in an area where the player is pretty safe for their first experience. However soon thereafter the player is then hit with a barrage of enemies along with shifting ground, all at once. This is a great example of careful planning put into the level layouts that allow players to learn while playing. When a player is able to learn a game by playing meaningful and fun gameplay likely arises thereafter  and in SGnG the gameplay is definitely both meaningful and fun.

Lastly, simple mechanics are expounded upon in interesting ways. Jumping and throwing. These are about as complex as the game gets in terms of the fundamental inputs the player must perform in order to play. Simply listing “jumping and playing” really does not sound very interesting, however by mixing and matching various interactions with the player, interesting circumstances often arise. In this way a player can easily press buttons in order to both successfully jump and throw objects. However in order to jump, throw objects, dodge enemies, kill other enemies, all the while constantly planning what to do next can become highly complex. What I’m saying is that SGnG is comprised of easy-to-use mechanics and this allows anyone to immediately play without hardly any learning curve. However in order to master the use of such mechanics, one must be able to navigate complex interactions with multiple variations of many variables all at once. Easy to play and difficult to master.

As detailed in their KickStarter campaign the design of Volgarr the Viking withdrew some of the best aspects of SGnG and brought them to life within their own game. The unique jumping mechanic makes for a very interesting type of platforming. Armor falling off of the knight, as seen in SGnG, exists within Volgarr the Viking in a new reincarnation of barbaric awesomeness. I could go on and on about the similarities between Volgarr the Viking and: Castlevania; MegaMan; Rastan; Zelda. I’m sure you get the idea from all the explanations and references to SGnG. Volgarr’s iconic blue helmet, as well as a shield can be gained if gathered from various treasure chests placed around levels.

Once the player gathers one of these items special boosts are given to the player. The shield can deflect certain enemy attacks, for example. However, just as seen in SGnG, the armor falls off of the player in dramatic destruction when the foes of the player land a hit upon Volgarr

Volgar as seen with full Armor Upgrades and Flaming Shield

In this way the player is rewarded for the ability to consistently prevent enemies from damaging Volgarr, thus influencing players to think about how to approach obstacles throughout levels in an intelligent manner, in order to anticipate what actions are necessary to take in order to achieve optimal play.

Fanart created by Randy Gaul for a Volgarr the Viking fan art contest. Volgarr’s flaming sword is used to cook a giant chicken atop Volgarr’s mighty spear!

Not only does Volgarr the Viking draw from excellent arcade style games, like Rastan and MegaMan – Volgarr the Viking features a very vast well of in-depth gameplay. I’m not talking about an immersive storyline, or advanced interactive cutscene elements. Volgarr the Viking has simply ingenious level layout. Here’s an example:

Volgarr the Viking Gameplay

In the above image the player sees a chest to their immediate right. The instinct of a player in this situation is to approach the chest and strike it with Volgarr’s massive sword. Knowing this and understanding the instinct a player experiences in this situation, the level designers then decided to hide additional content above the player, in order to reward players for challenging their natural impulsion to strike the chest.

Player spotting a hidden chest!

If the player decides to pause and observe the environment with the camera zoomed outward, an additional hidden chest can be seen. In order to acquire the chest, the player must expertly throw spears into the wall, in which to jump upon:

The spears are commonly used as a tool in which to traverse walls. However, the designers Kris and Taron take the simple concept of throwing a spear into the wall even farther, and extrapolate upon the idea in interesting ways…

Volgarr riding a spear struck into a skeleton’s shield.

In the above image the player has the ability to strike a skeleton’s with the spear, and then ride the spear. Riding the spear like so avoids the spikes within the pit and allows the player to reach an otherwise seemingly impossible to reach location.

Striking the same enemy upon the shield seems to only make large sparks. However Volgarr can easily crouch. Requiring the player to crouch to hit certain enemies with the sword adds an interesting dynamic of crouching into combat. Little subtleties like this are what really contribute to Volgarr’s depth of gameplay.

Volgarr striking the shield of a skeleton.

All in all Volgarr the Viking should excite every single person who has ever owned a SNES, Sega Genesis, NES or enjoyed old-style arcade games in the past. Volgarr the Viking brings out the best from some of the best past-times, and infuses them with a lot of original ideas and modern technologies in order to create something wonderful.

I myself don’t have access to the Alpha at this time, so I don’t have experience playing the game first-hand. Those that currently have Alpha access did so through pledging to the original KickStarter campaign – which I was totally broke and out of money for. You should expect some gameplay videos from myself as soon as I can possibly upload them.

Be sure to purchase Volgarr the Viking, or better yet purchase multiple copies and give them out to people you know. This game, as stated in the introduction, is only the most exciting game to have been made within the last DECADE.

# Ancient Forest and Grumpy Monsters

Hello all! I’ve been away for a little while over the summer. This summer is the one that came right after my Freshman year, and so I wasn’t able to get an internship. This means that this summer is likely going to be the last one I’ll ever have to really just relax. So I took a month or two off from programming and did some other things. I’ve been working a lot at hotkeyit.com creating content.

I’ve finally have a finished product to show off from my second semester at DigiPen! The game is called: Ancient Forest and Grumpy Monsters. The whole idea is to as an ancient magical forest to fight off a faction of Grumpy Monsters! Placing down tree structures is the main mechanic. These structures act as defensive towers, spawn creatures of the forest, and spread purification onto the land to counteract the spreading corruption of the Grumpy Monsters.

Here’s a little info on the team qMopey that created the game:

The team, qMopey, is a team of four programmers that are currently attending DigiPen IT that are developing the game Ancient Forest and Grumpy Monsters. This game is our second semester project. The game was coded in C using a DigiPen in-house DirectX library. The only functionality used from this library was loading images into memory, and displaying them on screen -even mesh creation is handled by our team. The team consists of:

• Anh Do
• Kevin Giang
• Colton DeGraw
• Randy Gaul
 Gameplay Screenshot of corruption and purified land.

In order to gain resources you place any structure underneath a sun tile! Each tree under a sun tile produces a single extra income point.

As the player progresses through the campaign levels new monsters and technologies are introduced. Here are a couple images of some of the various units on the Grumpy Monster’s unit roster:

RANDOM TRIVIA:

• 21786 lines of code
• 220 source files
• 1 million hours of work (joking, but it felt like 1 million)
• All art was created by programmers on the team who actually get no class credit for the art
• Anh Do is terrible at the game Lol

# Game Program Structuring/Design: Game State Manager

Not too long ago I created my own first game from scratch in pure C. I struggled most with program design. I’d like to share what I’ve learned about a proper game state manager.

A game state manager is a method of creating a highly organized main game loop, which is generalized to the point that it can apply to any situation without pre-runtime modification of code. The game should always be in a state during runtime. That state could be the main menu, a pause screen, or a specific level or scenario. A state is divided up into multiple categories, and these categories are generalized enough to apply to every state the game can be in.

The idea is to use function pointers, and a specific set of them. There are six different functions to know:
• Initialize
• Update
• Draw
• Free
These are the six functions that will make up your main loop, and once constructed your main loop should need little to no modification throughout the development of your game. Each function represents a category of functionality during a state. Every state consists of these categories. Each different state will have six functions designed for each of the function pointers in the main loop to point to them. This way your main loop will simply point to different states with its six pointers whenever you want to switch from one state to another.

The load function takes care of loading all of a state’s necessary data. Load should be called only once per state -not even if the state restarts. Load also initializes the loaded data. This function is called first when a state starts.

The initialize function prepares the state’s data to be used initially. It should not load any data, only prepare it. This allows a fast restart of a state in the event a restart is required -no loading or unloading will be involved in a state restart.

The update function uses a change in time (dt) to hand off to necessary functions to update the game in realtime. dt is defined as the time elapsed since the last call to update. Input should be gathered once per update call before calculations are made. All gameplay logic should happen in this state, and all live objects should be updated here.

The draw function renders all required images onto the screen, and additionally plays any desired sound effects. A well organized program will send data off to a graphics manager in this state, allowing further decoupling of major system and logic components.

The free function is what frees any objects or data no longer required, and sets the state up for switching or restarting. No data is unloaded (image sources, sound sources, meshes, etc). The idea is to set everything up to be initialized cleanly again.

The unload function is called during state termination, and unloads all data loaded in the load state. Here is an example of a properly set up game flow of a main loop:

Initialize system components
GSM_Initialize( firstState ) while not quitting   if currentState is quitting     nextState is Quit   if currentState is restart     currentState is previousState     nextState is previousState   else     GSM_Update( )     Load( )   Initialize( )   while currentState is nextState     Update       gather input       get dt       update game logic     Draw( )   Free( )   if nextState is Restart     previousState is currentState     currentState is nextState   else     Unload( )     previousState is currentState     currentState is nextState Unload 

By analyzing the setup of the above game flow you should be able to see how it works. To change a state, you simply modify the global variables currentState and nextState. previousState is then kept on-hand automatically. GSM_Update is responsible for updating the function pointers Load, Initialize, Update, Draw, Free and Unload whenever a state is started. In the event the global variable currentState changes, these function pointers will then change to their appropriate values via a switch statement. This switch statement lies within the GSM_Update function. The switch runs on the value of currentState, and once it finds a match it assigns the function pointers in the main loop to the appropriate matching state. Here is an example of a GSM_Update function:

// Update the Game State Manager by syncing the three state indicators to their // corresponding function pointers (all six of them). int GSM_Update( void ) {   switch(currentState)   {   case Level_1:     Load = &Level1_Load;     Initialize = &Level1_Initialize;     Update = &Level1_Update;     Draw = &Level1_Draw;     Free = &Level1_Free;     Unload = &Level1_Unload;     break;   case Level_2:     Load = &Level2_Load;     Initialize = &Level2_Initialize;     Update = &Level2_Update;     Draw = &Level2_Draw;     Free = &Level2_Free;     Unload = &Level2_Unload;     break;   case MapEditor:     Load = &MapEditor_Load;     Initialize = &MapEditor_Initialize;     Update = &MapEditor_Update;     Draw = &MapEditor_Draw;     Free = &MapEditor_Free;     Unload = &MapEditor_Unload;     break;   case Presentation:     Load = &PresentationLoad;     Initialize = &PresentationInitialize;     Update = &PresentationUpdate;     Draw = &PresentationDraw;     Free = &PresentationFree;     Unload = &PresentationUnload;     break;   /*case Template:     Load = &Load;     Initialize = &Initialize;     Update = &Update;     Draw = &Draw;     Free = &Free;     Unload = &Unload;     break;*/   case Restart:     break;   case Quit:     break;   }   return RETURN_SUCCESS; }

And there you have it; a proper organizational setup to allow an excellent method of managing game states. Using this sort of organization allows for each state to have a universal format which allows for modification of states, additions of states, and deletions of states during development to be very easy and time-efficient.

# Game Design: Positive and Negative Feedback; Flow Control

As I’ve said a few times in the past, I have been. Lately I have also been applying what I’ve learned into judging StarCraft mapping contests, like this one, and weaving them into my own map like this one. I’ve decided to take some of the knowledge and tools I’ve gained and write a post here about them. First, I want to talk about positive and negative feedback back loops in two different contexts.

The first context I want to talk about them in, is in the study of cybernetics.

Cybernetics deals with the ways a system gauges its effect and makes necessary adjustments. The simplest cybernetic device consists of a sensor, a comparator, and an activator. The sensor provides feedback to the comparator, which determines whether the machine is deviating from its established norm. The comparator then provides guidance to the activator, which produces an output that affects the environment in some way. This fundamental process of output-feedback-adjust-ment is the basis of cybernetics.—Stephen Littlejohn, Theories of Human Communication
As this quote explains, cybernetics is a study of how a system reacts and makes adjustments to the current state of the system. This should sound rather relevant to video games. This type of automated reaction is used all the time; have you ever played a game that automatically tiers to the user’s level of skill? There are two primary types of adjustments that are made upon a system, these two are positive and negative feedback reactions, usually used within a loop.

For example, take a room with a thermostat and a heater. When this room’s sensor, the thermostat, reads a certain temperature it can trigger the heater to react. This system can be rigged to perform a negative feedback reaction in which the heater heats the room when the temperature is less than or equal to a certain amount. Assuming the room naturally cools, the room’s temperate will oscillate between a few degrees and stay that way, all the while the room’s specific state is constantly changing. A positive feedback loop would be if the heater turns on when the temperate is equal to or greater than a specific temperature. In a positive feedback loop, the temperature of the room will spiral up and up once it hits a certain activation point. Both positive and negative feedback loops are essential tools to be used in game design.

A great example of a negative feedback response is in the game Super Mario Cart. In Super Mario Cart there are weapons you gain from running into question marked boxes with your cart. Once you hit one you obtain a random weapon. You have a much greater chance to obtain a powerful weapon when you are near last place in the race, and you have a much greater chance to obtain a weak weapon when you are in first place. This sort of automated reaction the system generates creates a much more compelling form of gameplay, in which all the racers are usually closely pitted against each other neck to neck until the very end of the race. This generates an exciting play in which the outcome of the overall match remains uncertain till the very end.

The second meaning of positive and negative feedback would be rewards and punshiments to a player. Simply put, rewards are great to use to encourage players to make certain choices, and punishments are used to deter certain behavior. There is also a third category known as negative feedback. Negative feedback is not necessarily a punishment, but is used to deter a player from making specific choices. For example say you do not want your game to be focused on fighting, although you want to have an occasional enemy in your game. It turns out that too many players are focusing on finding and fighting enemies rather than experiencing your game how you designed it to be experienced. You do not want to punish the player as to deter them from playing at all, so what you could do instead is implement a clever negative feedback mechanism. You might be thinking that you could just make enemies stronger and therefore make the player want to avoid them -this might just make finding and killing enemies an interesting challenge for the player. Instead you could give the player absolutely no reward for killing the enemy (no points or anything), you could also make enemy encounters not worth the risk (as in making the player restart the level if an enemy kills them, or have enemies be “thieves” where if they hit you you lose items). If your goal is to make enemies something the player wants to avoid, give the player a reason to avoid them. If you find that fighting these enemies is truly fun for the players, you could also switch your game to a fighting one; it’s your design, you decide.
Flow; flow would be the fine balance between difficulty in a game and the player’s skills. Skills do not just include physical coordination; skills also include knowledge of the game’s workings, knowledge of the other player’s skill level, physical coordination, intelligence level, and response time. There are more than likely many many more forms of skill which I did not mention, but these should give a general idea. The difficulty of the game is pretty self-explanatory. The flow channel of a game is a narrow isle where the difficulty of the game is perfectly balanced and matched to the skill level of the player. Here is a diagram of the flow channel graphed with challenge over skill level:

As you can see, it can be hard to create a flow in gameplay for all different types of players. One way that game designers achieve balanced flow is to apply positive and/or negative feedback loops to a game’s processes.

Here is an interesting excerpt from the book Rules of Play that talks about the design process for a game made by two designers:

In a wonderful essay published on Gamasutra.com, Jesse Schell and Joe Shochet of Disney Imagineering write about the process of designing Pirates of the Caribbean-Battle for the Buccaneer Gold, a game “ride” where a group of players stands on a motion-platform pirate ship surrounded by video projections. During the game, one player steers the ship while the other players operate a number of cannons, firing at monsters, forts, and enemy vessels. Pirates of the Caribbean is designed as a condensed five-minute experience, and it was essential that players feel properly challenged at every moment of the game.
In their design analysis, Schell and Shochet detail a number of design problems that had to be overcome in order to maximize player enjoyment. For example, during playtesting they identified as a problem the fact that the player steering the ship could take the ship to what they call “dull places,” leading to a less engaging experience for all of the players. In the selected quotes below, Schell and Shochet outline some solutions to this problem:
Architectural Weenies: “Weenie” is a phrase coined by Walt Disney himself. It refers to the technique used on movie sets of guiding stage dogs by holding up part of a sausage… In the case of Pirates, [there are] three main “weenies,” one for each island: a volcano, an enormous fort, and a plume of smoke coming from a burning town. No matter which way the boat is facing, at least one of these “weenies” is in view. Since the coolest action takes place at the islands, [we wanted] to guide the captains to go there.
Guide Ships: Since the short-term goal of the game is to fire on other pirate ships, captains strive to get near these ships so that their gunners can get a clear shot. Many of the ships in the Pirates world are “on their way” to the islands mentioned above. Many captains, in just trying to stay near these ships find that just as they have destroyed the ship, they have arrived at one of the islands, without even trying to get there.
Sneak attacks: What if the captain ignores the guide ships? Even if he heads toward one of the “weenies” it might mean as long as a minute during which the gunners have little to shoot at. For this reason, [we] created special “sneak attack” ships that “magically” appear behind the players’ ship, and quickly pull up alongside, when no other boats are in range.
The Waterspout: This was [a] nickname for [a] “last ditch” forcefield that surrounds the game play area.If a captain tries to sail out of the main game play area and out to open sea, they hit the forcefield, and the ship is “magically” pointed back to where the action is. The few guests who see this don’t even realize that anything unusual has happened. They are just pleased to have their boat going somewhere cool.
Schell and Shochet are thinking in very experiential terms, using clever techniques to subtly guide player action in meaningful directions. At the time of its release, Pirates was a very high-tech production, featuring real-time 3D graphics, physically engaging cannon-firing interfaces, and a large motion platform to simulate a pirate ship rocking on the waves. Often in these instances, a desire to “properly” simulate a coherent 3D space or “correctly” output logical behavior for computer-controlled characters overshadows the design of the actual play experience. But Schell and Shochet had no hesitation in making pirate ships “magically” appear to guide the player, or abandoning “realistic” physics to have the player’s ship turn on a dime to facilitate navigation. As they put it,”By choosing to be less concerned with reality and more concerned with what was fun, we created an experience that…is easier to adapt to, quicker to learn, and is a better show.” In game design, player experience should always trump so-called “realism.”
Boredom and anxiety, as game design watchwords, are wonderful because they speak directly to player experience. As you shape and sculpt your players’ pleasure, you are guiding them between the Scylla and Charybdis of anxiety and boredom.This task is made all the more difficult because, as we know, the experience of play can only be indirectly designed. How do you create a set of rules that maximizes the play of pleasure for your audience?

The designers of this game implement two negative feedback loops. Did you see them? Onewould be the sneak attack ships. These ships react to the players being all alone at seas, and then appear out of nowhere to create an exciting experience. The other would be the water spout; the water spout reacts to the players entering the boundaries of the map, then spins them in the correct direction, thus keeping the game in a specific state. The guideships and weenies would be more a form of positive feedback in which encourage the player to make specific decisions. The guideships encourage the players to travel to the key focul points of the game while the weenies create enticing visual scenes that players are likely to travel to. Both of these provide the players with a reward and a reason to take specific actions.