Category Archives: Game Design

Volgarr the Viking


Wicked Snake and Volgarr in promotion Art by Kris DurschmidtWicked 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 VikingVolgarr 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 EmulatorScreenshot 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 UpgradesVolgar 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

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 GameplayVolgarr 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!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 zombie's shield.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.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 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 (CecilSunkure)
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.

Aren’t the sunrays absolutely adorable?

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:


Here’s the download link to the actual game’s installer:


  • 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:
  • Load
  • Initialize
  • Update
  • Draw
  • Free
  • Unload
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
    GSM_Update( )
    Load( )
  Initialize( )
  while currentState is nextState
      gather input
      get dt
      update game logic
    Draw( )
  Free( )
  if nextState is Restart
    previousState is currentState
    currentState is nextState
    Unload( )
    previousState is currentState
    currentState is nextState

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 )
  case Level_1:
    Load = &Level1_Load;
    Initialize = &Level1_Initialize;
    Update = &Level1_Update;
    Draw = &Level1_Draw;
    Free = &Level1_Free;
    Unload = &Level1_Unload;
  case Level_2:
    Load = &Level2_Load;
    Initialize = &Level2_Initialize;
    Update = &Level2_Update;
    Draw = &Level2_Draw;
    Free = &Level2_Free;
    Unload = &Level2_Unload;
  case MapEditor:
    Load = &MapEditor_Load;
    Initialize = &MapEditor_Initialize;
    Update = &MapEditor_Update;
    Draw = &MapEditor_Draw;
    Free = &MapEditor_Free;
    Unload = &MapEditor_Unload;
  case Presentation:
    Load = &PresentationLoad;
    Initialize = &PresentationInitialize;
    Update = &PresentationUpdate;
    Draw = &PresentationDraw;
    Free = &PresentationFree;
    Unload = &PresentationUnload;
  /*case Template:
    Load = &Load;
    Initialize = &Initialize;
    Update = &Update;
    Draw = &Draw;
    Free = &Free;
    Unload = &Unload;
  case Restart:
  case Quit:

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 reading Rules of Play: Game Design Fundamentals. 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.

Too often I see games designed in StarCraft maps that are too hard or too easy, or too hard or too easy once the player reaches a certain point. I also see games made in which the leader has no way of letting the other players catch up to him, because he has such a great advantage over the other players. I also see the losers in a game have no means of catching up to the leaders. What’s the point of continuing play if the outcome of the match has already been determined in the middle of the game because the leading player has a tremendous advantage over the rest of the players? These types of design flaws can be controlled with positive and negative feedback loops. Usually positive feedback loops are harmful to a game’s flow (flow will be explained more in depth soon), and should be switched out for negative feedback loops. If a leading player seems to be constantly destroying all the other players in an unfair way, create a negative feedback response in which the system (the game) reacts and hinders the leading player. Similarly, you can give advantages to the players in last place to encourage and help them catch up to the leaders.

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, 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.