Orbit: Satellite Defense is available now on Steam

Click here for more information about Orbit: Satellite Defense

Available now on Steam

Rating old Game Design Docs; should I Make it, or Break it? Mathew and Attila discuss ideas for Bisector: The mathematical target slicing cousin of Fruit Ninja, Boolean Bash: A Logic Operator tile puzzle, and Bribery Race: Throw around money to alter the racetrack in your favor!

Side-note: I totally meant to say "Caltrops" but instead I said "Cantrips". I've been playing too much D&D lately.

A solo-cast where Attila condenses the episodes "Environmental Reuse" and "Procedural Generation" into byte-sized B1TS 0F W1SD0M

Attila and fellow RTS fan Chris Feres discuss the later years of the RTS genre including the ill-fated Command & Conquer Franchise.

Attila waxes nostalgia with fellow RTS fan Chris Feres. A look at the early RTS scene including the heavy hitters of the 90’s; Starcraft and Command & Conquer

An interview with the co-creator of the popular Red Alert 3: Paradox mod! Join Attila and Chris Feres as they discuss the ups and downs of game modding.

From the much loved Yoshi to the oft-under-appreciated Yellow Spinning Blocks, Mathew and Attila examine all the features that made Mario World truly deserving of the “Super” prefix.

Cut-scenes come in all shapes and sizes, from brief dialog exchanges, to grand cinematic. Mathew and Attila discuss the best practices of cut-scenes in gaming.

The game that cemented Mario as the platforming icon he is today; Mario Bros. 3 stands as a shining example of how to take a great game and improve every single aspect of it.

Inspired by the delightful traversal mechanics of Super Mario Odyssey, Attila and Mathew discuss who much traversal mechanics matter in other games.

Despite being the so-called "black sheep" of the Mario Bros. series, Mathew and Attila look at the aspects of Super Mario Bros. 2 that made it into games to come, as well as the elements that were understandably cut.

So often, AI meant to assist the player ends up doing the complete opposite. Mathew and Attila discuss everything from rage-inducing Escort Quests to delightfully helpful invulnerable assistants in their discussion on friendly AI.

Mathew and Attila discuss the platfomer that set the bar for all others to come and made Mario a world-wide sensation. What crucial design choices led to Super Mario Bros. becoming such a sensation? What set it apart from other platformers at the time?

Should government legislation crack down on harmful game design practices? The ESRB might cover content rating, but what about the psychological traps present in so many of today's free-to-play games? Mathew and Attila discuss whether or not these nefarious practices should be subject to outside laws.

Mario 64 brought the famous plumber into the 3rd dimension, what was gained and what was lost in the transition? Mathew and Attila discuss the 3D platformer that set the golden standard for years to come.

Are Consoles going the way of PCs? Incremental hardware updates threaten to overthrow the identity of the home gaming console. Mathew and Attila discuss the implications for the industry and for consumers.

Did you experience this Wii U gem? Mathew and Attila talk about everything from the aesthetics to the sound design of this stellar 3D Mario title.

Super Mario Galaxy remains one of the best and most iconic Mario games released to date. Attila and Mathew discuss everything there was to love about this classic, as well as a few details which are not to their liking.

How does this playground game provide the basis for the best tactical game-play experiences? Mathew and Attila look into the widespread implementation of Type Advantage across games of all genres.

What makes a game feel good? What makes a control scheme feel good? What makes destroying an enemy satisfying? The answer to all of these questions is Game Feel! Mathew and Attila discuss the nebulous concept of Game Feel.

The elements that make The Legend of Zelda: Breath of the Wild the masterpiece that it is are sprinkled throughout the Zelda series. Mathew and Attila speculate on the design decisions of Breath of the Wild and look at where some of its most interesting features draw their inspiration.

With all the hate surrounding games having too much "hand-holding" what's the right way to share information with your players? How can you strike a balance with sharing enough information so players know enough about how to play your game without them getting bored? Mathew and Attila discuss the surprisingly complex problem of sign-posting.

How are crazy Sequence Breaks and Memory re-writes even possible in the first place? Attila gives insight on the programming practices that gave rise to certain Speed-running tactics.

Non-stop overtime and slavish conditions seem to accompany the weeks leading up to the release date of most AAA games. Mathew and Attila discuss the slippery legalities of "Crunch Time".

Are game artists being lazy when they create red and blue versions of the same enemy? The devil is in the details; Mathew and Attila discuss everything from Shiny Pokemon, Overwatch Skins, and Paper Mario enemies to illustrate the best and worst use cases for palette swaps.

Checkpoints; the more the merrier? Do they even influence the difficulty of a game, or do they just save you from repeating content? Where is the best place to insert a checkpoint? Also, more discussion on save-scumming, save-states, and other ways players create their own "progress markers".

From the exceptional Loyalty Missions in Mass Effect to the mundane Fetch Quests in MMOs of years past, Side Quests provide some of the most and least memorable experiences in gaming. Mathew and Attila discuss what makes some quests more interesting than others, what the best quest rewards are, and more.

Make the numbers go up. You have to. You can make the numbers go up faster if you play every hour, on the hour, all through tomorrow, for the rest of your life. Progression Systems keep players engaged, but wouldn't it be better if your motivation was to play the game for the sake of enjoying the actual experience?

As much fun as Card Games might be, they are made from the ground up to extract as much value from the consumer as possible. Mathew and Attila discuss games that are distributed as digital Collectible Card Games and physical Trading Card Games.

10 pages of rules before you can even start playing? Why does a board game rule book take 10 pages to explain what a friend can summarize in less than 5 minutes? A discussion on the best way to create engaging board games which are easy to get into but offer just as much emergent complexity to keep you engaged.

Luck can feel great when it works in your favor and aggravating when it works against you, winning a game of skill can be rewarding, but loosing one leaves you no one to blame but yourself. Discover the ins and outs of luck vs skill as applied to Game Design!

Do we let Hearthstone get away with being pay to win because we find it fun to play? Do digital card packs count as content or consumables? Are they a worthwhile purchase if set rotation is going to make them obsolete?

Would you rather pay for Consumables or Content? Is it okay to have "pay to win" in a single-player game? How can developers use micro-transactions in ways that don't harm consumers? Mathew and Attila discuss micro-transactions in games. Attila talks about his negative experiences with the Plants vs Zombies franchise, including the "most stressful Zen Garden ever".

Mathew and Attila discuss what truly makes a choice Meaningful in a game. Games discussed in the show:

Deus Ex: Human Revolution

Super Mario Bros.

Mass Effect

Life is Strange

Persona (series)

Final Fantasy VII

Halo 5: Guardians

Overwatch

Elder Scrolls III: Morrowind

Dark Souls (series)

Extended Thoughts

If you've ever had the moment when a game has really made you stop and think about a decision, you'll know the wonders of Meaningful Choice. We experience choice all the time in games, but it isn't always something that gives you pause, usually because one option is clearly better than the others. A choice can be meaningful on two different layers; on one layer a choice might be meaningful because the developers have invested a lot of effort into it, other choices feel meaningful because of the moral implications involved in the decision. I refer to these as layers because they are not mutually exclusive, and indeed they feel ever more impactful when they coalesce, like when developers create a powerful moment of moral choice in a game's story where two or more possibilities are fleshed out with narrative consequences. You can also give players meaningful choices when it comes to game-play as well. By giving a player multiple ways to tackle a given challenge, not only do you cater to different play styles, but you also create a high degree of replay-ability.

Given how difficult it can be to construct meaningful choices, remember that it is better to have a single, well developed answer to a problem than a myriad of half-baked ones. Even if you create a moment where the player can pick from several viable solutions to a problem, odds are the player will simply pick one at random and may even come away with buyers remorse, wondering at every stumbling point if they should have picked a different option. Not only is it incredibly difficult to create a game brimming with meaningful choices, it would also be mentally exhausting for a player. If a meaningful choice truly gives the player pause, you don't want that to happen in the middle of a real-time combat scenario. Those kinds of choices should be quick and easy to calculate. Above all, keep in mind that an uninformed choice is not a meaningful one. If the player cannot get some sense of the implications of their choice, the consequences can feel more like fate than a result of their selection.

Mathew and Attila discuss narrative in games, and the dichotomy between games which put story first with lacking gameplay and action games which don't bother to tell a good story. Games discussed in the show:

Donkey Kong

The Legend of Zelda

Metroid

Bioshock (series)

Metal Gear Solid V

The Legend of Zelda: Skyward Sword

Half Life

Uncharted (series)

The Last of Us

Telltale Games (Walking Dead)

Mass Effect (series)

Braid (video game)

Dark Souls

Firewatch

Mega Man (series)

Bastion (video game)

Extended Thoughts

Some of the best narrative experiences presented in games are ones which acknowledge the interactive nature of the medium. Since the player is an active participant, it can be difficult to offer the player enough freedom in the story while still telling the story the author wanted to tell. On top of that, in some games you can only make a guess at the player's pace in completing objectives and advancing the story. In the case of games where the player has a choice in which objective they will tackle, and where in the world they will go, the pacing is further hampered. A game's narrative must also never be at odds with the gameplay or, at best, players will want to skip it, at worst, they will actively dislike it. Due to the added challenges that interactivity brings, rather than letting a story "unfold" in the traditional sense, games must weave the narrative into the world.
Every single aspect of a game has the potential to contribute to the narrative. If non-playable characters simply spout a line of tutorial dialog at you, they won't feel like they are contributing to the narrative. They should feel like actual people, with real motivations and relationships with other characters and the world around them. The world itself can also serve to further the narrative, serving as the canvas onto which characters express themselves, and reveal something about themselves. Even items can contain some element of the game's story. Beyond simply their utility purpose, every item can have a lore description of a fragment of one that comes together to contribute to the larger narrative. The more factors you have contributing to your game's narrative, the more fully realized the world will feel.

Mathew and Attila discuss Shovel Knight, it's penalty for death, and whether instant-deaths make sense in a game where you have a health-bar. Games discussed in the show:

Shovel Knight

Extended Thoughts

Shovel Knight was a wonderful 8-bit romp through a colorful and imaginative world, but it brought with it classical game tropes like the "instant death spike" and Bottomless Pits on either side of a narrow platform with an enemy waiting to stun-lock-knock me back into them.

Thankfully, one of the earlier items you get in the game, the Phase Locket, makes you invulnerable to all damage, allowing you to walk harmlessly over spikes, and prevent you from said knock-back-dealing enemies. Of course, there were plenty of times were you needed a different item equipped and died to these hazards all the same. If I could have permanently assigned the Phase Locket to another button on my controller, I would have done so. Seeing as how you can pause the game at any time and switch your equipped item, it's not even like the developers wanted to prevent this quick switch use of relics.

Anyway, it got me thinking about the "art of the instant kill" and where best to apply it in games. An instant death hazard shouldn't be slapped into a game without thought, nor should you exclude the possibility from your game without consideration.

The way the check-points are laid out in Shovel Knight means the instant-kills are used rather strictly for increasing difficulty.

In the case of Shovel Knight, the Instant-Death sticks out like a sore thumb because you have a health bar. If it's the Enchantress casting deadly magic on you or getting stomped by a Yeti mini-boss, nothing else kills you in one hit except for these spikes and pits. They are an exception to the otherwise consistent rule that against everything else, you can have another chance. If you're going to break a consistent rule, it has to be for a very good reason, ideally one which actually benefits your players. Think about a game with a big open world with a huge gorge the player is tasked with jumping over. The game may well have the bottom of the gorge detailed and used, but if the player lands here and survives the fall, then they are faced with a huge hurdle of climbing back out of the gorge before attempting to jump it again. It is far preferable to the player to be plunged into darkness and respawn at the edge. Think of it as a mercy killing, as a way to set the player back to a safe point to try the challenge over again without the tedium of resetting themselves.

Now, the more classical approach to instant death is the removal of a life bar, then, it is simply consistent for everything to kill the player in one hit. One-hit death games are famous for being unforgiving, and that's exactly what they are. When you give players multiple hit points, you are effectively dictating how many mistakes they are allowed to make before they need to tackle the whole challenge all over again. Since you are demanding perfection, you must keep in mind how many obstacles you place between the player and the next check point, and the challenge level of those obstacles.

Dark Souls made famous the idea of loosing important currency when you die, and Shovel Knight has a very similar mechanic. However, the key difference between the games is that in Dark Souls, it is the player that chooses to press on. The player has the choice of how much they want to press their luck, how far they are willing to travel before they retreat back to the safety of a Bonfire so they can spend their Souls. In Shovel Knight, you have no such choice. If you hit a difficult point in a level, you have no choice but to risk loosing all your hard earned currency time and again until you finally make it through all the way until the end of a level.

All of this simply underscores something which I come across very often when designing my own games; just because a mechanic is interesting in another game, doesn't mean you can insert it into your own game without thinking through all the design implications. The whole reason the Souls mechanic was interesting in Dark Souls was because of the risk-reward mechanic that it created; permeating the experience with tension as you try to survive long enough to spend your precious Souls. This is lost in Shovel Knight, replaced only with a sense of unfairness at an incredibly steep penalty for what often is an instant-death.

Mathew and Attila jump on the Pokemon GO bandwagon and discuss the potential future of Nintendo games on smartphones.

Pokemon GO

Extended Thoughts

Despite the incredible success, I don't think Nintendo is going to jump ship any time soon and start putting any of their core games on smart-phones. Firstly, the majority of games in their back-catalog were designed with an interface which expects button input. Nintendo has standards too high to simply add virtual buttons onto a screen and call it a day. Add to that, most of their games are built with sit-down-and-play experiences in mind, not the sort of shorter time-span found in most popular smartphone games. If we're going to see further Nintendo software on non-Nintendo hardware, it's going to be more in the vein of Pokemon GO; games developed for that platform that serve as a gateway to their quality premium products.

Mathew and Attila discuss Death and Energy Systems in games. Games discussed in the show:

Street Fighter II

Super Mario Land

Super Mario 3D Land

Super Mario Bros. 3

Robo's World: The Zarnok Fortress

XCOM: Enemy Unknown

When We Were Young

Braid

Stardew Valley

Animal Crossing

Final Fantasy 7

Paper Boy

Dark Souls

Extended Thoughts

We are fortunate to live in an age where just about anyone with time and dedication can learn to make games and share them. Of course, initially, games and the cabinets they were housed in were very expensive to produce and manufacture, so anyone fronting the cash for creation of an Arcade cabinet needed a promising return on investment. The ideal solution to this would be creating a game that is so much fun to play that it would attract a lot of positive attention. Unfortunately, the case often was that games were made to be incredibly difficult to create circumstances under which players would die frequently and have to keep pumping quarters into their machines to keep playing. This is not to say that all games in this era which were difficult were bad games, not at all! If you're playing a bad game and you die, you give up and move on to another cabinet, bitter about your lost quarter, but that's it. These games needed quality game play to keep players invested in their experience so they would, in fact, invest actual quarters into it.
This created a particular breed of gamer; after all, if you had a budget limiting the number of times you could die, it became all the more important to master the game and play cautiously, taking in your surroundings and memorizing the structure of familiar levels to limit the number of times you died.
As time went on and home consoles became available for purchase, many arcade games were ported onto them. Many games produced in that era were made with similar levels of difficulty to their arcade port brethren, although with a different motivation. Rather than having to justify an endless stream of quarters from the player, games needed to justify a large up-front cost. Now, the difficulty of a game wasn't used to draw money out of the player, but to elongate the player's experience and make the initial investment seem more worthwhile.
In the modern era, the last old ideas about death are slowly being overturned, studio by studio, but there are many studios for whom it seems the old line of thinking is all they know. 
We are now in an era where designers should be thinking about death as a possible means of helping players, rather than as a punishment. For instance, if a player is attempting to make a jump between between two ledges but fails, it is more merciful to "kill" the player and drop them back at the top of the ledge than to force them to climb all the way back up before attempting the jump again. Of course, for this death to truly be of help to the player, there are other things that need to be addressed about the nature of that death. Designers need to evaluate the penalties and "iteration time" associated with the death condition in their game.
First of all, not every Death needs to result in a penalty. Try to see if you can separate the instances in which a player deserves an actual penalty from those where the death is not necessarily deserving of penalty. After all, not every death is a failure, and not every failure should result in death. As designers, we must divorce Death from Failure in our minds. I would not go so far as to remove all penalty from all Deaths. For after all, if death has no meaning, it can rob you from your sense of satisfaction upon completing a challenge without dying (although, if a challenge is difficult enough, the measure of skill might simply be how efficiently an objective can be completed, and Death need not even be a factor). The genre and mechanics of a game determine what sort of penalties are possible in a game, and which make the most sense. Typically, the penalties for death involve taking progress away from the player, usually in the form of traversal (having to re-navigate an environment to get back to where you were) or in taking away currency which the player needs to progress. Sometimes, the traversal penalty is combined with the currency penalty, forcing the player to loose both on death. In games like Shovel Knight and perhaps more famously in the Dark Souls series, lost currency can be reclaimed if the player can navigate back to their point of death provided the player doesn't die again, in which case the original currency is lost forever, and they loose more of what they had. In Dark Souls, this creates a constant tension as you are always in danger of loosing the required currency for leveling up. The combination of both traversal and currency penalties may seem harsh, but it is integral to the play experience of the game and has been expertly woven into the design of the game and the nature of its challenges. However, just because it works well and is well regarded in the Dark Souls series doesn't mean everyone should lift this mechanic wholesale and add it to their game, especially if your game has more traversal based challenges that can result in instant death.
In Dark Souls it is the player that chooses to press on, and how far they travel before retreating to a Bonfire and spending their currency. In Shovel Knight, you can only go forward through a level and cannot spend your hard-earned currency before you end up in a scenario where you loose it.
For a great example of how the traversal penalty can actually be helpful, we can look at the check-point system in the Halo series. When a player dies, they are reset to an earlier period in time before they died, usually very close to when they died, but after dying many times over, they may be sent back further.
When the player is sent back further, it is an opportunity for them to scavenge different weapons for the fight ahead, or perhaps pick up more ammunition or even find a different angle of attack on the encounter which has killed them so many times. Of course most times, a player has only failed due to execution (not equipment) which is why the designers give them a couple tries from a nearby checkpoint before they consider sending them further back in the level. and the player always has the option of reverting back to their previous checkpoint if they feel they are in a no-win scenario.
Iteration time should be thought of as the time it takes between when the player dies to when they get to try it again. For instance, if you expect a player to encounter death frequently in any part of your game, the iteration time should be kept as fast as possible. This means no lengthy player death animations, and if possible, no long load sequences should be necessary to reset the player to get another shot. Here's another, even more basic affordance; if your game uses a Keyboard as player input with the Arrow Keys and perhaps Spacebar for jump, don't force the player to press the "R" key to restart the game after they died. There is no reason they should have to alter which keys they have their hands resting over. The only time you want to make the process of restarting difficult to perform accidentally is when, in the instant the player respawns, they must be ready to give the game their full attention to prevent another, quick death. However, if you're contending with that situation, then perhaps your Checkpoint system needs some refinement.

As is often the case, the most important thing to remember is that you want players to complete your game, and even Death can be a tool you can use to help them accomplish this.

Mathew and Attila discuss the ideal length of a gaming session. Games discussed in the show:

The World Ends with You

The Legend of Zelda: Ocarina of Time

Robo's World: The Zarnok Fortress

New Super Mario Bros.

Deus Ex: Human Revolution

Cliff

The Legend of Zelda: Twilight Princess

The Last of Us

Extended Thoughts

Play Session Basics

Session length refers to the amount of time which a player spends in a game from the moment they turn it on to the moment they turn it off. From lengthy MMO raids to a few seconds spent playing a mobile game between stops in public transit, you must divide your game into session lengths that best accommodate the intended audience. Sessions can be thought of like chapters in a book; natural divisions of a game experience between which the user can end their game session or continue as they see fit.

One simple way this division is achieved is to break your game up into levels, but this isn't always possible given the nature of the game. Otherwise, a save / load system of some sort must be implemented which can allow players to dictate their own session lengths. Of course, with the ability to save and load anywhere comes the potential for abusing such a system to artificially deflate game difficulty. However, not every type of challenge is prone to abuse from "save-scuming" and the issue can be circumvented by only offering a "Save and Quit" option to the player. This way, the creation of the save file allows players to jump out of the game whenever they need to, but doesn't allow players to save and keep playing, reloading the file whenever they fail. Another approach is to limit saving / loading to preset save / load points; physical places in the game where the player must interact with a game entity to save their progress. This still allows you to dictate what transpires within a play session, although it is not as accommodating of length. Perhaps the ideal solution would be a combination of Save Points and the ability to Save and Quit from anywhere, as this can allow players to drop-in and out of a game at will while preserving the intended challenge of the game based on the location and scarcity of save / load points.

Getting into the Game

If it takes 5 minutes to get past the opening logos, loading the title screen, and then loading the save file, players probably won't feel like even opening the game unless they know for certain that they can commit to a longer play session. When I designed the main menu for Zarnok Fortress, I made it so that the main menu appears instantly without any splash-screens to get in the way of the game beginning. I also ditched the idea of the "title screen" which does nothing but display the name of the game and a message that says "Press Start to begin". The "main menu" is the first thing the player sees with the cursor positioned over the one-click-Continue button that instantly loads the last-played file. This means from when the user launches the game, they can start playing instantly. If you're intent on having splash-screens display before the game begins, I would suggest only having them appear the very first time, or at most the first few times the game begins. Beyond that, the logos can be featured on the Main Menu screen if you're really intent on reminding the user who it was that made the game they are playing. In the case of Zarnok Fortress, I further gave players the option of selecting how the game would load the levels. By default, the game loads levels one at a time since this has the least amount of up-front time cost. If a player is in for a longer play session though, they can elect to have every level pre-loaded into memory to speed up the time between levels, although this makes them sit through a long load before they can get into the game. I know just enough about asset loading in games to understand that offering this kind of choice isn't always possible, and may be severely limited by the amount of memory available from the game hardware, but when you can offer players this choice, they are sure to appreciate it.

Getting BACK into the Game

It can be tempting to enforce control over the length of a play session by not letting players quit out of the experience in the middle of something important, like a puzzle to which they might forget the details. If you've ever stopped playing a game for any length of time only to return to it utterly bewildered about what you should be doing or even what the controls are, it can kill the experience and make a player drop the game for good. 

In defense of Fi from The Legend of Zelda: Skyward Sword (you'll never hear anyone else say that) she could at least remind you of your current objective, as well as give hints on how to get there. This is useful not only for players who are stuck in the game, but also for anyone resuming a play-through from an extended absence. Another, more elaborate solution from Pokemon FireRed / LeafGreen was a Journal that kept a log of everything the player had done recently, playing it back to them at the start of their next play session. While this system didn't give you a hint as to what to do next, it did contextualize everything you'd done up to where you left off in the game, which might have been enough to jog your memory into remembering what you meant to do before concluding your previous session.

One thing I haven't seen done very often (but something I believe would be incredibly useful) would be the ability for a player to access a quick primer on the game's controls to remind them of what does what. This is more important for games with a large number of different inputs, or games like First Person Shooters which can have small differences in controls from game to game. It would certainly be useful to a player coming fresh off of a session in a different game where "Right Bumper" performs the reload action, where now they need to press "X" instead.

Session Length by Platform

The length of individual play sessions must be influenced by the platform the game is being played on. Platforms can be broken down into a few distinct categories (in truth it's more of a sliding scale based on device capability and usage): Mobile, Handheld, and Console / PC. Of course, the platform a game is played on is not the only factor in session length, as more powerful devices can play host to games with session length structures of less powerful devices, and modern smartphone devices are capable of rendering experiences akin to full Desktop experiences of just a few years ago, so the following is mostly just a helpful generalization.

Mobile

Mobile refers to games played on a Smartphone (typically with only one hand, as the other is likely occupied holding onto the safety bars of whatever transit system the player is riding). These games should have the absolute shortest possible session length, as little as the amount of time it takes to get between stops on a subway (under one minute). These are the kinds of games where Iteration Time becomes incredibly important; how quickly can a player retry a challenge which they have failed at? When I designed the parody game Cliff, I made it so that the user doesn't even need to touch the screen when they die, they immediately restart the game and continue from where they left off. This can shave down precious seconds which are actually large fractions of time when dealing with sessions this short.

Handheld

While the handheld market is being carried almost solely by Nintendo's 3DS, and may not be much longer for this world in its current form, it serves as an important middle-ground in the sliding scale of session length. Anyone who packs a handheld game system in addition to the smartphone they probably have is likely in for a long trip, or is a dedicated gamer. Handheld games must play host to a wide range of expected session length that bridges the spectrum from Mobile to Console / PC. As such, it's difficult to put numbers to the exact session length because it depends so much on the kind of game being played, but lets say it occupies the range above 1 minute up to around 15.

Console / PC

These are the heavy hitters; the games which some players actively schedule around so that they can continue to enjoy them even as the amount of free time in their lives dwindles. These are games which can convey stories of massive scope (made by Indie and AAA alike) or multiplayer matches which have a minimum session length of 15 minutes (bear in mind that the time limit on causing eye-strain is 20 minutes of up-close focus). While games of this scale can tempt a player to play from beginning to end, it is the responsibility of the designer to build in break points at the upper limit of 40 minutes. At this point, give players the chance to come up for air, even if they decide to simply dive back down into the game. If you structure your play sessions to be much longer than this, players may not be able to finish your game because they cannot invest the necessary time into a single play session.

Mathew and Attila discuss the length of games, both AAA and Indie. Games discussed in the show:

Anatomy by Kitty Horrorshow

Firewatch

Journey

The Witcher 3: Wild Hunt

The Elder Scrolls

South Park: The Stick of Truth

Contra

Mass Effect Trilogy

The Order: 1886

Extended Thoughts

For those of us who have been fortunate enough to grow up with games, I'm sure many have fond memories of immersing themselves in 30-50 hour long experiences. Whether that meant playing a game to completion or sinking hours into the multiplayer, sometimes the experience could last even longer. However, as time went on and we grew up, we find that adulthood responsibilities demand more of our time and we can no longer (responsibly) afford to dedicate as much time to gaming. This either means favoring shorter experience so we can play a number of different games in less time, or being extra selective in which 30+ hour experience we choose to partake in.

When looking at what longer games have to offer, there are very few which actually justify their full play-time. Many longer games resort to padding out the experience in some form or fashion, but it is important to understand that this is not an issue exclusive to large AAA games. There are some games that are padded at 1 hour in length, just as there are games which are padded at 50 hours. Perhaps out of fondness for longer game experiences of days past, certain vocal gamers demand that games adhere to a "dollar per hour" ratio. As children, we are far less likely to notice when a game is padded out or has some segments which are repetitive. At the camp I work at, I see kids listening to 10 hour long versions of songs all the time. But this cannot form the basis of our demands for new games that are being made; it will result in worse games overall! In the end, a game's length should be determined by its story and the number of unique mechanical combinations it can present. However enticing a story may be, there are few mysteries that can be drawn out over 50 hours. However fun a combat system is, you can only introduce so many unique enemies for the player to fight. There is a point at which an experience begins to stagnate, and it is up to developers to trim the dead ends and deliver a satisfying conclusion to their game well before that happens. The ideal length of a game can almost be determined by the mathematics of combinatorics; if your game has a certain number of mechanics that can be combined in a certain number of ways, the length should be determined by the number of unique combinations that can be generated. Obviously some combinations will be so fun that they are worth repeating at least once, and some combinations are not worth having at all, so it ultimately comes down to the individual mechanics of the game. Essentially, there is a sweet spot for every game to find; not too short that it doesn't get to explore the intricacies of different mechanics intertwining, and not so long that those parts of the experience feel as though they are being drawn out like butter over too much bread.

Attila tears into Paper Mario: Sticker Star.

Paper Mario: Sticker Star

Extended Thoughts

As much as I loved the first two Paper Mario games (the original and The Thousand Year Door) I feel as though I was at odds with the very principle of Paper Mario: Sticker Star. I believe however, that this was beyond a matter of personal preference, that there are some fundamentally broken (even paradoxical) mechanics in this game. I believe that it might be helpful to analyze exactly what went wrong, seeing how the various mechanics involved in the game's combat system operate in opposition to one another, instead of coalescing. Throughout the game, you collect 3D items that you can flatten into Stickers and then use as special items in Combat. Even your basic jump and hammer attacks appear in the environment as ready-to-use Stickers. And here's the crux of the issue; all your basic and special attacks are competing for space in the limited number of pages that make up your Sticker Book. Let's walk through the specifics:

1. You can't use the powerful 3D items you find until make your way back to a specific place in Toad Town where you perform the Sticker conversion (get ready for a lot of back-tracking).
2. Converted Stickers are tailor made to deal crazy amounts of damage to specific boss enemies, and it would be a complete waste to use them against anything less. They also require no input from the player to use them, no execution challenge or "Action Command" as the game calls it.
3. Converted Stickers take up a huge amount of space in your inventory so there's no way you can convert them all and still have enough space to take on regular enemies.
4. The specific items you need in boss encounters only become obvious when the fight starts.

So there's the critical flaw. You basically have to resign yourself to death the first time you encounter a boss, then go all the way back to Toad Town, then all the way back through the Boss's level, and then use the one item without which you are in for an unfairly difficult fight.

I'm not entirely sure if there's much to be done in making the inventory-based combat as it is presented in the game any better. There are a number of overlapping systems which make the game so fundamentally flawed that I would rather start from scratch if I wanted to make a combat system that was as engaging and fun as the traditional action-RPG battle system the series adhered to in its first two iterations. The most simple surface-level solution would simply be to give the player no limit on their inventory space, but at best this just cuts the difficulty of the game as every instant-win item is just somewhere in that list and all you need to do is pick it. I came up with a few other fixes, but as I said, none of these really make the game great, perhaps just a little better:

1. Make it so that no single item is a must-have, instant-kill for any boss. Perhaps late-game items can instant-kill early-to-mid-game enemies at best.
2. Have a number of different items which have varying degrees of effectiveness against your enemy, but exactly how much the item lives up to its potential damage is determined by an execution challenge, like your basic attacks in Paper Mario. The more damage a potential item is going to deal, the more difficult it is to pull off.
3. Couple this with an ability like Tattle from previous Paper Mario games to highlight what an enemy is weak against, and make the player responsible for retaining that information. Maybe this ability itself is an item, one which the player can naturally carry less of as they memorize the weaknesses of enemies.

As if this weren't bad enough, I even discovered a "First-Order-Optimal Strategy" which I used to blaze through the majority of the game. Simply put, a "F.O.O. Strategy" is one which requires a minimal amount of input with a high return for the player. In practical terms, I found a sticker which I could use to win every fight in the game with on my first turn, bypassing all combat; the Koopa Shell (and later the Red Koopa Shell). By using the Shell on the first turn, I could pretty well instant-kill every enemy in a given encounter. Between the Coin Bonus I received from winning the battle in one turn and the coins dropped by the defeated enemy, I was earning more than enough coins to buy all the Koopa Shells I needed to coast through every encounter. I'll admit that using this exploit would detract from any fun the game might have had to offer, but I already wasn't having fun, so rather than give up on the game entirely, I used this F.O.O. strategy to get to the end at least once.

Mathew talks all about the Shadowrun series and specifically his favorite entry in the series; Shadowrun for the Sega Genesis.

Shadowrun (Genesis)

Extended Thoughts (written by Mathew Falvai)

What a joy to talk about my all-time favorite video game on the GAMEOLOGY podcast.

For the uninitiated, the Shadowrun universe is a wonderful mashup of Fantasy and CyberPunk. Set in a dystopian future of Mega Corporations, the Awakening returned Magic to the world and many humans mutated into elves, dwarves, orcs, and trolls. You play the role of a Shadowrunner: skilled mercenary for hire. Oh yeah, there are also Dragons. Powerful and intelligent beings that operate behind the scenes.

The Sega Genesis version of Shadowrun is a masterpiece in combining systems, attention to detail, and player choice.

The combat is a great place to start. Everything happens in realtime from the same perspective you see for the entire game. All of the dice-rolling and stat-tracking is done behind the scenes as guns, melee, and magic combine in fast and furious battles. A great detail is the ability to purchase guns from both legal and illegal shops. Illegal guns are the best but can be confiscated by police through random events (we’ll get to those later). You can either purchase armor that conceals the weapons (but provides less protection) or purchase a weapons permit from a specific contact. This mechanic breathes life into the world and adds weight to your choices. I love how these elements bounce off each other.

Speaking of breathing life into the world, random events are another wonderful element of the game. While navigating the world, the view will switch to the conversation screen and play out one of several scenarios. This could be the police wanting to speak with you, an injured man asking for help, or a shadowy figure offering illegal grenades. You always have multiple options to proceed and the outcome will mostly randomly generated. Helping the injured man might result in a cash reward or it could be a supernatural being luring you into a trap. The grenade salesman might be offering a sweet deal or could be an undercover cop. These moments offer engaging diversions that help flesh out a world limited by 16-bit hardware.

Another system I love is the ability to get a criminal record. Being arrested for infiltrating a corporation or carrying illegal weapons results in the record. This restricts your ability to purchase a visa that would allow you to reach the second wilderness hub. However there are multiple ways around this. You can either pay a phone contact to delete this record or pay a different contact to fly you into the second wilderness area undetected. These contacts are only represented by a beautifully drawn image on a vid-phone and plenty of text, but it further expands the universe.

Many of these details and mechanics are completely optional. For example, three separate gang factions exist. The player can gain access to each gang boss by either paying cash or having their reputation at the right level. These gangs offer contacts to their affiliates (Yakuza, Mafia, Seattle City Officials) and/or protection from random gang attacks. Another element that could be completely skipped over but deepens the universe.

The atmosphere is very dark and mature. The story begins by showing the player’s brother’s murder. The main quest is to avenge his death by following clues from one narrative set-piece to the next. Many NPCs are openly hostile to you and the world is painted as a corrupt/dangerous place to be. This is accomplished through a ton of text. Although text can be off-putting to some, it has the advantage of providing the depth of narrative detail found in books. The limited graphics and lack of voice-acting mean everything must be described in words. This not only invokes the imagination to further immersion but has the added benefit of infinite randomly-generated mission. 

Within this detailed world exists a Matrix, which is Shadowrun’s internet. The Matrix is represented with a completely different interface. The character’s virtual avatar uses programs that act much like spells with cooldowns. Defense programs guard access to the rest of the system and the highest level ‘Black-Ice’ programs can even cause physical damage to the player outside of the Matrix. A character can jack in through any cyber terminal and steal data to complete missions or sell off to a particular NPC. It’s also useful during infiltration missions to access the Matrix from inside a corporation to shut down security systems, cameras, alarms, and unlock doors. 

I could go on forever about this game but my biggest takeaway is how well it translated the Shadowrun universe into a video game using detailed, inter-connected systems. It was great then and still holds up during my semi-annual playthroughs.

Thanks for reading.

Attila heaps praise on one of his favorite games; The World Ends With You while Mathew listens patiently. A discussion on how the game handles Difficulty and an example of Mechanics as Metaphor.

The World Ends With You

Extended Thoughts

Mechanics as Metaphor: sending Messages through Systems

Whether you intend for it or not, your game mechanics carry messages to your players. Use this to your advantage and turn your code into poetry in motion.

In the cult hit game, The World Ends with You, there is an overarching theme of the importance of individuality. It's woven into the narrative, and even directly into some of the game's mechanics. One shining example of using mechanics to metaphorically express the game's core theme relates to the combat effectiveness of your equip items. Every equip item in the game is an article of clothing associated with one of thirteen fictional clothing brands in the game world. Each of those brands is ranked in popularity, with different clothing brands being more popular in some zones of the game than others. If you wear items of a popular brand, you get a stat bonus, while if you wear unpopular clothing brands you get a stat penalty. However, the most important component of this mechanic is that the more a player wears a specific brand of clothing in battle, the more popular it becomes, eventually rising through the charts and granting the player the associated stat bonus. If the designers of TWEWY had stopped halfway and only made popular clothes give stat bonuses, that would have been a terrible message. Instead, they managed to turn that around completely and make it a fantastic example of expressing individuality; allowing players to wear what they want in the face of hardship and eventually rewarding them for it.

I would argue that most mechanics in games are devoid of a metaphorical meaning, and that's just as well. Having everything in your game be an elaborate metaphor would be incredibly difficult to construct and interpret, and in most cases it simply isn't necessary. That being said, it is incredibly important to keep this in the back of your mind while you are designing every mechanic in your game. By accident or coincidence, you could end up designing a mechanic that has some very negative undertones. It's all about understanding that nothing happens in a vacuum; your game exists as part of a large and complicated social web that is our world, and there are many things in our world that are fine in some cultures but terribly offensive in others. So take a moment to evaluate the messages in your game and ask yourself these questions: are they the messages you intended? Are there messages you didn't expect? Every once in a while you'll be presented with a fantastic opportunity to embed a meaningful message directly into the mechanics of your game, the code itself becoming poetry in motion.

Mathew and Attila discuss difficulty, fairness, and consistency and how this can be done well or done poorly in games. Games discussed in the show:

Dark Souls

Bastion

Dark Souls II

BioShock

Robo's World: The Zarnok Fortress

Final Fantasy XIII

Super Mario World: Feather Cape

Mega Man Boss Select

The Legend of Zelda: A Link Between Worlds

Batman Arkham Knight

Extended Thoughts

People play games for a myriad of different reasons. Some people play games for the narrative, some for the challenge. Some people play games just to pass the idle seconds aboard morning transit. Something that affects the appeal of any game experience is the game's difficulty. I'll be discussing true difficulty in this write-up, not difficulty in controls (which falls under more of an accessibility issue). There are a number of different ways we perceive games as being difficult, some more overt than others. Typically, the more overt a game is about its difficulty, the more it tends towards being a frustrating experience for the simple reason that creating a truly "challenging but fair" experience is incredibly difficult. It's something that only experienced developers can properly pull off, and it is the product of a LOT of play testing and iteration. It's incredibly easy to make an experience which is arbitrarily difficult.

Any experience which relies on trial and error on the part of the player, (especially when the penalty for the "error" in question is death and loss of progress) that's the easy / frustrating kind of difficulty. This kind of difficulty stems from lack of communication to the player; throwing them into situations they are unequipped to deal with, confronting them with hazards that they have no way of encountering without getting hit by them at least once, invisible paths that you just have to know are there. Situations we are confronted with in real life where we are under-informed are incredibly frustrating and unless that is what you are trying to evoke in the player (why!?) they should be avoided.

Ways of Modifying Difficulty

Of course, there are plenty of situations where even if the majority of players understand the solution to a given problem, there will be a few who do not, a few for which a given part of your game is just too difficult. It's in these circumstances where having an adjustable difficulty is incredibly useful. It lets more players experience the parts of your game that lie beyond the one particular wall they've run up against. There are a number of different ways these difficulty modifiers can be built into an experience, and there are a number of ways in which this can be done well, or poorly which I'll classify as "multipliers", "modes", and "items". I'd like to preface that a game may draw on any combination of these methods depending on the nature of the experience (I believe it is a rare case where a game uses only one method).

Multipliers

Multipliers apply a mathematical increase or decrease to the given difficulty of an experience. They are perhaps the simplest way of modifying a game's difficulty. If on "Normal" difficulty given enemy attack deals X damage to the player, on "Easy" difficulty it deals X - 2 (or half of X) and on "Hard" difficulty it deals X + 2 (or two times X). My main issue with Multipliers as a means of modifying game difficulty is that it leads to a core inconsistency; if the player gets used to playing on a specific difficulty they will find it jarring when an attack that they are used to surviving suddenly leaves them KO'd.

Modes

Difficulty Modes represent core changes to the game experience. This could mean altering the number or type of enemies that spawn, removing hazards from the game environment, or adding in extra power-ups. Due to the nature of these changes, it often makes it difficult (if not impossible) to swap a difficulty Mode once a game session has begun. After all, if you have the Mode set to Normal, then toggle over to Easy where there should be fewer enemies, how is the game to decide which ones should de-spawn? What if the player is standing in a space where a Hazard would exist when they decide to bump up the difficulty? This is why choosing difficulty Modes is typically set in stone at the beginning of starting a new file, or in the game's main menu before starting a play session, it allows a fixed experience to load in and avoid all the issues just mentioned. By contrast, Multipliers are the easiest to turn up or down at a moment's notice since they aren't changing anything core to the game layout. Although creating alternate Difficulty Modes presents a significant design challenge, it also presents a number of different ways for a player to experience the game and solves the issue of maintaining consistency that Multipliers struggle with. Indeed, consistency is an especially great aspect of Modes because should a player choose to play through the game a second time on a harder difficulty Mode, all the experiences of the previous play-through will still be relevant.

Items

The last category of difficulty modification is the use of Items, especially consumable ones that the player can carry with them and trigger at specific instances. These are items which the player does not need to use to get through a specific challenge, but which make the challenge easier. Mega Man provides some great examples of how this is done. You can use the Emergency Energy Tanks to replenish health from the pause Menu, allowing you to bank up on Health where it is easy to find, and then expend it where you have need of it. You can also use "Rush Powers", granted by Mega Man's trusty robot dog. The powers they afford vary from game to game, but for instance, some give extra rising platforms which you can jump onto to make certain jumps easier, or platforms that travel forwards which you can use to cross large gaps. Even in the recent Mario games, your ability to store an item in a backup slot to be used when needed means you can get an item from an easy level, and then use it where necessary to get through a difficult level.

In my game, Robo's World: The Zarnok Fortress, I took the Mega Man approach and included Spare Parts which the player could collect throughout the game, and then redeem them not just to replenish Health, but also to get Shield Power-Ups and Grenades. Allowing players to redeem items to deflate difficulty at their whim is both a blessing and a curse. It certainly accomplishes the goal of allowing players to self-regulate the game's difficulty, but it can allow players to entirely circumvent moments in the game by simply walking through all the hazards you've placed in their way, "damage boosting" to get to the end. It can leave players with a definite sense of having completed a part of your game "incorrectly". Item usage gives players a very potent means of modifying the difficulty in your game and means you really need to think through the nature of the challenges in your game and how they can potentially be affected by item usage.

Difficulty Curves

As a player progresses through a game, it is reasonable to assume that will naturally get better at it. They will learn to master the controls and gain a more thorough understanding of the mechanics. As such, the difficulty of a game should naturally rise over time to provide a level of challenge to the player that feels "just right". As I see it, an ideal curve can be broken into three parts:

Smooth Start

The beginning of the curve should be the flattest as you take the time to introduce the player to your game, letting them get a feel for the controls before giving them any real challenge.

Upward Slope

As a curve begins to steepen, you must pay close attention to each interval of the slope, making sure that there are no "walls" where the difficulty rises too suddenly. Let the slope build, but keep it a smooth curve; don't let it build to an unpleasant spike.

Flattened Peak

When a player has attained a new threshold of competence, they should be allowed some time to enjoy that feeling of power before you increase the slope of the difficulty to provide them with a fresh level of challenge. This creates the moment of "release" that follows the intensity of a "tense" moment as the Slope reaches its steepest point. You may even consider having the difficulty dip down a little at this point.

Curves withing curves

As the difficulty curve's overall shape trends upward over time it should have smaller subsets of peaks and valleys. Towards the end of an experience, you can start to increase how steep the Slope of the curve is, scaling the challenge up at a faster pace than earlier in the game. 

Curves within curves within curves

But why stop there? As important as it is to have an overall curve of your game in mind, you can plot out the difficulty curve of your game down to the moment (The execution of a complex attack can have its own curve mapped to it!). It seems like an awful lot of planning and tuning, but if you can map out a satisfying curve for your game, it will ensure that the order of things shakes out nicely and your game will feel better as a result.

The Problem of Open World Games:

This is where we arrive at "The Problem of Open World" games. When you give a player the choice of which part of the game they wish to tackle first, (letting them pick a Dungeon or Robot Master) it means that each of those zones must be equally difficult to begin with and follow the same difficulty curve within each stage. Depending on how the difficulty is balanced, this can have one of two results. If every stage is balanced towards being a viable entry point in the game for the player, then it will therefore not present enough of a challenge as the player tackles the last few stages, especially if the player is picking up a stat-boosting item somewhere in each stage that further reduces the difficulty of the levels. Alternately, the difficulty is balanced towards late-game play and it presents a difficulty spike which turns early-game players away, which I would argue is the worse alternative. In this case, if the player gets a stat-boosting item in each stage, it effectively creates a backwards difficulty curve as each item the player gets makes the game easier. Even if the balance falls somewhere in the middle, that would just mean you are alienating both early and late-game play experiences. The way I chose to tackle maintaining a balanced difficulty experience within an open world in Robo's World: The Zarnok Fortress was with a mechanic in the game where the enemy's intelligence level goes up. This way, at the outset of the game, the enemy intelligence would be low, making for an easier play experience. As time went on, the AI level would go up, matching the player's advancement and providing a consistent level of challenge. On top of that, I allowed players a means of countering this intelligence increase with another mechanic within the Digital Environment. In addition to being a means of quickly traversing the Fortress, it also gave players the opportunity to play a Pac-Man style Minigame where they ate up bits of data that represented the enemy intelligence.

Crafting a difficulty curve that makes your game not too difficult and not too easy for all different kinds of players can be a challenging design problem. Sometimes it's not enough to give players the tools they need to modify the difficulty of the game through use of Multipliers, Modes, or Items if they don't understand how to make use of them. You may need to build things into the game that automatically notice if the player is running up against a wall and offering them non-intrusive suggestions as to how to tackle that particular challenge. You may even consider implementing a system which actively modifies the game's difficulty in response to the player's success or failure within the game. This is how I approached difficulty management in the Tower-Defense / Real-Time-Strategy game Orbit. The game would actively spawn more or fewer aliens for the player to contend with depending on how prepared the player was to deal with a given threat.

There are a myriad of ways you can build in variable difficulty into your game. Whatever the narrative, genre, or mechanics of your game, there's bound to be some method that you can make use of to make your game enjoyable and accessible to a broader audience.

Mathew interviews Attila about his recent participation in a Game Jam and Attila shares his thoughts and experiences with Jams past. Games discussed in the show:

Robo's World: The Zarnok Fortress (The Digital Environment)

Stardew Valley

HeliChopper (Made in 17 Hours)

When we were Young

Gentlemen Drop Dead

Cat Daemon (Throw Away Games' Jam Game)

Extended Thoughts

I've only been lucky enough to participate in 4 Game Jams; 3 in-person and one online. To give a brief overview, the goal of a Game Jam is to create a game, either as an individual or with a group, within a short time limit. At an in-person Jam attendees meet up in a specific location to be in the same space as other jammers, whereas in the case of an online Jam, participants coordinate the event over the Internet through use of a website or forum. An online Jam does not preclude the possibility of teams, but it is certainly less likely that team members will end up seeing one another. Due to reasons such as the cost associated with renting the space for an in-person Jam, they don't tend to run for more than a few days. Online Jams face no such constraints and may therefore run as long as the event coordinators see fit, up to a month in some cases.

The Jams I participated in are Toronto's own TO Jam (3 years in a row) and once in the online Game Maker Community Jam. If you are considering participating in a game Jam and have the opportunity to participate in an in-person Jam, I highly recommend it. That isn't to slight online Jams, but attending one in-person has a couple added benefits. For one, they are a fantastic way of meeting new people with a common interest in game development in your local area; you might make some new friends! Working side by side with team members can really help you to coordinate your efforts and get the most out of a jam experience. Plus, there's nothing quite like the creative energy of the other teams around you, catching snippets of conversation and insights into other people's workflow can serve as a source of inspiration on your own project.

 If you are a prospective employer, Jams are a fantastic way to see what people are capable of in a limited span of time. I personally met the Artist who I hired for work on Robo's World: The Zarnok Fortress at a Jam! I've also seen some people who've done nothing but play games and / or watch YouTube videos all three days of the Jam, making them people I wouldn't consider working with. By contrast, when you're dealing with an online game jam, it's more difficult to evaluate the work habits of other participants, although some people do take it upon themselves to live-blog or even live-stream their development. When participating in an Online Jam, you are also participating from the comfort of your own home. Some attendees of in-person Jams elect to stay at the location overnight, packing sleeping bags to ensure that they can remain at the event as long as possible. I've always personally chosen to return home overnight to sleep in the comfort of my own bed and have a daily shower, which is a given when participating in an online Jam. That being said, if typically a Jam participant doesn't have a lot of spare time to dedicate to making games, I can completely understand why they are motivated to squeeze every last second out of the in-person event. I will advise however, that first time attendees don't try staying overnight, it would be better to get a feel for what a game jam is like before going for total immersion.

Many game Jams incorporate a Theme of some kind; an over-arching concept which serves as the inspiration for the game you are making. Some Jams take the theme very seriously and only post the theme when the Jam starts, others are more lax and may post it up to a week before the event begins. For my part, I find the Jams that heavily enforce the use of their theme to be less fun. For some people, the Theme is a great starting-off point which inspires the game they are about to work on. I come up with new ideas for games all the time, and therefore find it limiting to have to constrain my ideas to fit a jam's theme.

One of the best things about a Game Jam is the fact that it presents the opportunity for game designers to practice the most fundamental mantra of their craft; "Fail Faster". While you may not completely bring to life your game idea within the time-frame of a jam, you should at least be able to create a minimum viable product, something shows off the heart of the experience you want to create. The Jam build can serve as your test-bed, with other jammers as your audience to see if your idea has merit, or where it needs improvement. If you manage to hook an audience with just your Jam build, if you hear those magic words; "I'd love to see more of this!" You'll know that you're starting off strong. And don't worry if your Jam game isn't showered with adoration, perhaps it just needs some tweaking before it really shines, even the best designers need to iterate on an idea several times before they get it right. You can't get too invested in an idea, if trying to bring it to life reveals some fundamental flaws with an idea, just be glad of the time you've saved yourself, lest you'd continued working on the game in isolation and the flaws hadn't become noticeable until the end of a long development cycle.

Another great benefit of participating in a game Jam of any kind is that it helps you refine your sense of Scope. As a developer, it's incredibly important to see how far you can push your skills, and what you accomplish within a given period of time. After all, when you work on a larger scale project you'll likely be breaking up larger tasks into smaller ones as you build out your project time-line. Accurate estimation is critical to ensuring that your project hits the expected ship date. Poor time estimation can result in your project running late, which can strain a project's budget among other unpleasant side-effects.

Mathew and Attila discuss how games can get off on the right foot; what makes a good tutorial? Games discussed in the show:

Robo's World: The Zarnok Fortress

Pokemon

XCOM: Enemy Within

Rayman Legends

Batman: Arkham Knight

Legend of Zelda, Fi

Mario Galaxy 2: Cosmic Spirit

Super Mario Bros. 1-1

The Witness

Final Fantasy VII

Extended Thoughts

A well constructed tutorial can make or break a game. When constructing a tutorial for an interactive medium, developers should aim to create a similarly interactive tutorial. The more interactive a tutorial is, the more it resembles actual gameplay, the better a player will learn its lessons. Occasionally, this can be accomplished by actually tricking the player into a desired outcome. A great (and comedic) example of this is in the opening moments of Portal 2 where the character is asked to "speak" and given a prompt on-screen that says "Press A to speak". Actually pressing the button causes the player-character to jump, and the humor of the dialog in this moment helps the player remember the button associated with this action. Of course, you might be asking yourself, doesn't the "A" button perform the Jump action in most games? Why would the developers feel that it is necessary to teach something so basic? Quite simply, it's because it's best not to make any assumptions about what the player may or may not know, even in regards to actions that seem like common knowledge. While the "A" button is typically the jump button, depending on the kind of game you are creating, it might not even occur to players that they have the ability to jump.

A good tutorial makes no assumptions, but you can allow the player to indicate if they have played the game before, and don't need to start from scratch

The less text a tutorial features, the better, as players tend to ignore it. If possible, text instructions should be paired-down single-word overlays accompanied by a button prompt. If you need to display a lot of text, you can convey it through dialog to make it more compelling. Players are far more willing to give their attention to dialog, especially if they are presented with a face, as it helps sell the feeling of an interactive conversation.

Text walls are a mortal sin in the eyes of some gamers.

If you can't directly involve the player in the element they are being taught, you can demonstrate how that element works by having other characters interact with it. This can be accomplished either through a video playing in the game showing the player character performing a given skill correctly, or by demonstrating a mechanic in the environment of your game. As an example of the second case, players begin the original Portal game without its iconic armament and learn the simple mechanics of movement and traveling through portals and moving boxes onto buttons. By the time you finally encounter the portal gun, it's sitting on a pedestal and rotating, firing portals automatically. This gives you a great sense of anticipation, but it also illustrates how the thing you are about to pick up works. When you have an external element like this which the player is not in control of, it can hammer home the idea of how it will function once the player has control of it in a sort of "do as I do" presentation.

While constructing a tutorial, you need to be sure not to introduce too much to the player at once. The pace at which you introduce new elements is highly dependent on the kind of game you are making. You might decide to have a number of super-short levels that each encapsulate a single tutorial element, or to have a longer tutorial level that introduces multiple elements to the player. In the second case, you should still take care to only introduce one new thing to the player at a time. If players encounter two things they've never dealt with before at the same time they don't get the chance to see how the elements act individually. Again, going back to Portal as an example, once you finally pick up the Portal gun off of its pedestal, it can only fire one of the two possible portals. The player makes their way through the next few puzzles where the developers teach them about the intricacies of portals, breaking common player misconceptions such as "the blue portal is the 'in' portal and the orange portal is the 'out' portal".

I'd recommend playing through Portal as a Case Study in how to do a tutorial correctly. Plus, it's a lot of fun and not very long.

Of course, if the game you are creating the tutorial for has mechanical synergies the player should be aware of, these synergies should be showcased in a tutorial format, if not necessarily within the first level. You'll have a great opportunity to reintroduce players to situations they are already familiar with (which is important, as the repetition helps reinforce learning) while introducing a new element to keep the tutorial fresh.

It can be very difficult to keep a tutorial compelling, but that's also incredibly important. If it feels too much like an instructional course and doesn't do a good job of representing the game that is to come, players will want to skip past it and miss all the valuable lessons you needed to bestow for them to properly enjoy the game. One big reason it can be so difficult to construct compelling tutorials is because of how tightly controlled they need to be. Some parts of your tutorial might demand that the player master a skill before being allowed to move on, and there is a big difference between "doing something once" and "mastery". You must ensure that players are learning the right lessons about the game mechanics they are presented with. Ideally, your game mechanics will be reasonably intuitive, but if not, it's your job to present them in a light that makes them intuitive. If an ability doesn't feel intuitive to a player, it could go ignored in favor of an easier to perform ability which works for most, but not all scenarios, and then players will encounter great frustration when they hit a wall where the easy-to-perform ability no longer suffices. 

Making something intuitive isn't exactly easy, it involves illustrating clear scenarios when a particular skill is necessary so that players can connect the dots.

Player feedback is vital for far more than just seeing if a mechanic is intuitive. Even if you've poured lots of thought and effort into the creation of your tutorial, if it doesn't make sense to players, you need to change it. You cannot let your ego get the better of you and insist that no change is required, citing the lack of skill play-testers have at the game as evidence that "they are just stupid, but any intelligent person would be able to figure this out". I would hope that developers are aware of how important it is not to look down on play-testers if they stumble through your tutorial. As the developer of a game, you get to see it built from the ground up, getting plenty familiar with the controls and mechanics. It should be expected that players aren't going to be playing on anywhere near the same level of proficiency as the creators of the game. Of course, as you iterate and make changes, getting an appropriate sample size of testers to evaluate every segment of your tutorial can be incredibly difficult, especially for small teams. You should strive to get as many fresh perspectives on your game as possible to ensure that you are getting unbiased feedback (that they aren't simply completing some component of your tutorial because they already know how to play).

I wish I didn't have to bring up the ego issue, but it's something I've witnessed and work to make changes in spite of.

A good tutorial is not one which front-loads everything there is in your game, but one which is well paced out. If a player isn't going to need a particular skill or have to worry about a particular mechanic, leave it until the level in which it will be encountered. In the extreme case, you certainly wouldn't want to teach the player how to do something at the beginning of your game only to have it go unused until the very end of the game. It would be unreasonable for the player to remember that unused skill throughout the whole game. Instead, every time you introduce something new to your game, keep good tutorial practices in mind. Even if player is encountering a new game element in the last level of your game, you should be relying on the same good teaching practices as you've used up to that point. Don't make the assumption that just because they've made it this far that they don't need new mechanics explained to them. Always keep in mind that your ultimate goal is to teach players how to play your game so they have the best possible experience in it.

Don't try to compress everything into the beginning of your game, implement good tutorial practices whenever a player is taught a new mechanic in the game.

Mathew and Attila discuss what makes a boss encounter memorable, looking at Mini-Bosses, Temple Bosses, and End Bosses. Games discussed in the show:

Legend of Zelda: The Wind Waker

Robo's World: The Blulite Rocks

Halo: Combat Evolved (Warthog Run)

Paper Mario: The Thousand Year Door (Shadow Queen)

Final Fantasy XIII

Legend of Zelda Twilight Princess (Ganondorf)

Paper Mario: The Thousand Year Door (Bonetail)

Extended Thoughts

As much as we might hate tests in school, gamers relish the chance to rise to the challenge and tackle a well crafted boss. Although there are innumerable approaches to Boss design in games, there are some practices that have stood the test of time. Since different classes of Boss have differing best practices, I'll be dividing them into the following categories: Mini-Bosses, Temple Bosses, End Bosses, Experiential Bosses, and Secret Bosses.

Mini-Bosses

Mini-Bosses are encountered by the player at mid-points in their experience. They might be guarding a special item, a door, or any other sort of objective. During the rising action of a given zone, they serve as a small climax, to help flesh out your ideal interest curve. Mini-Bosses can be anything from tougher versions of enemies the player has already encountered, to larger foes that fight in a unique arena that serves as part of their combat experience. Defeating a Mini-Boss in most Zelda games rewards the player with a new Item which they will learn to use before going up against the Temple Boss. Mini-Bosses can be constructed like other enemy characters in your game, and in fact they may be reused as enemies further down the game's timeline.

Boss Rushes

Other types of bosses usually should not recur in such fashion due to the nature of the challenges they present. The only place where it would make sense for these other kinds of bosses to re-appear might be in a "Boss Rush" experience, where the player must fight every single boss in the game one after another. Building a Boss Rush into a game's core experience can come across as padding out its length. Since bosses are usually unique enemies, it rarely makes canonical sense for the player to have to fight them again. Still, it can serve as a great gauntlet challenge for players to test their skill, so while I would advise against making a Boss Rush mandatory for progression, I would highly encourage their inclusion as a way for the player to earn some sort of rare item, or even as an unlockable bonus play mode that the player can access from the main menu of the game.

Temple Bosses

Temple Bosses serve as the big guardians of a given area in the game and perhaps a test of the player's mastery of a particular skill,  usage of an item, or simply a "level gate" (evaluating that the player has reached an appropriate "level" before being able to proceed). By defeating this boss, the player is proving that they are ready for a new type or tier of challenge in the game. It is usually this tier of boss that is subject to the "3 hits" rule; not necessarily that the Boss dies in three strikes, but that the player successfully exploits the boss's moment of weakness on three separate occasions. Of course, this is specific to a game with a boss structure like Mario's; it wouldn't do to have a Dark Souls boss keel over in 3 hits. That being said, it is worth exploring why this is done, as many well-crafted bosses have been made with this sort of structure to them. To land the first hit, the player must familiarize themselves with the boss's attack pattern and moment of vulnerability. The second hit, on a smaller scale, is usually a smaller proof of mastery in itself, proving that the first hit wasn't a fluke. After the second hit, or once the player has brought the boss under 50% of its total health, it will enter an "Enraged" state. Once Enraged, the boss will often exhibit some extra challenging characteristics such as moving more quickly, attacking more aggressively, or changing up its attack pattern. Landing a final hit on an Enraged Boss ought to prove that the player has completely mastered the challenge the Boss present, and if the boss were to require further hits without continuing to change up its tactics, the fight could start to feel tedious. Since a Temple Boss fight is meant to serve as the climax of a particular zone, the last thing you want is for the encounter to feel like anything but an exciting challenge.

End Bosses

The concept of an "enraged" state goes beyond just Temple Bosses as well; End Bosses can have multiple stages to their encounters too. In the case of these multi-stage bosses, each sub-phase of the boss can (but doesn't necessarily have to) obey the rule of 3 Hits. If the battle is broken into stages like this, it can be a great opportunity to revaluate the player's mastery of all the skills they have learned throughout the game, with each phase of the fight testing a different skill. I personally believe these kinds of encounters are far more interesting than having a single large health bar which you must whittle down over time (an experience that is essentially static throughout the battle).

Experiential Bosses

It's important to keep other types of "final challenges" in mind too. In place of a Temple Boss or even an End Boss, you can include a particularly challenging experience. A great example of this is the "warthog run" in the final levels of Halo 1 and Halo 3. While you aren't fighting any single large enemy, you are doing your best to survive a ship going into a nuclear meltdown and the collapsing superstructure of a Halo respectively. They provide a unique and memorable experience to close out the game and leave a (hopefully) positive impression on the player of the adrenaline fueled final moments.

Secret Bosses

All the bosses I've discussed so far are ones which fall somewhere along the planned path for the player. They should be designed to be within the skill range of the player at the moment they are encountered in the game, with perhaps the End Boss being a notable jump. Beyond that lie "Secret Bosses"; challenges that are far above the expected skill of the average player. Secret Bosses are typically found in RPGs, or any game where the player has free roam of the world. Even getting to these bosses is usually a gauntlet challenge in itself, like the Pit of 100 Trials in Paper Mario: The Thousand Year Door. The boss itself is typically more powerful than the End Boss of the game, and may require the player to have the most powerful weapons, armor, or abilities that can be unlocked in the game in order to succeed. If the End Boss tests a player's mastery of the "story" component of the game, the Secret Boss exists to test a complete mastery of the entire game, a true capstone challenge.

General Design Practices

When encountering a boss, especially a Temple Boss or the End Boss, you should consider the feasibility of introducing it with a cut-scene. This may not be necessary if the boss is a character which has already been introduced at an earlier point in the narrative, but even if that is the case, a brief cinematic will set the stage and heighten the player's anticipation for the battle ahead. You could use this cinematic as an illustration of the boss's power, or even make it functional by safely demonstrating the boss using one of its attacks while the player is invulnerable and giving some insight as to how the attack might be avoided. It also lets you show off the intricacies of the boss's design which the player might not notice if they are engaged in battle. Whatever the purpose of the cinematic, you should either keep it very short, or simply only play it the very first time the player encounters the boss, as it can be infuriating to sit through a cinematic multiple times if the player dies to the boss.

When looking to create a boss in a game of your own, it can be difficult to find the balance between something challenging enough that it will feel satisfying when defeated, and something which asks too much of the player. As with all aspects of game design, feedback and Play-testing are crucial to ensuring that players are understanding the challenge they are presented with. A boss is not the time to introduce new mechanics to the player, not when they could be within range of a one-hit-kill enemy and too distracted trying to survive in order to follow any new instructions. You must make sure the player can identify the boss's attack patterns and weaknesses (physical "weak points" or "moments" of vulnerability between attacks). However, when you go to implement that feedback, consider that instead of changing the boss, you also have the option of modifying the level leading up to it, helping the player to better understand the mechanic they are being tested on. You should want players to be able to defeat your bosses, as any good teacher wants their students to pass their tests.

Games discussed in the show:

Call of Duty of Infinite Warfare

The Legend of Zelda Wind Waker HD

Starcraft II

Mario Kart: Double Dash

Mario 64

Final Fantasy VII

Sega 32X

Extended Thoughts

All art is created in, and for its own time. Society advances, cultural touchstones come and go, new phrases enter language, and stories age until they can entice only scholars of history. No work of art is immortal, but it certainly seems like video games age like few other forms of art, so quickly that it has become common practice to remaster, or even completely remake games that were new only a few years ago. The reasons for these recreations vary on a case by case basis, but chief among them should be making the original experiences accessible to new players.

Games seem to age quickly compared to other forms of art, and so are subject to far more remakes and remasters

One such barrier that developers should tackle is that of the game's controls. Control paradigms shift over time and across game genres; what was the standard method of controlling a particular game years ago will likely feel awkward to a gamer of today. An awkward control scheme will pervade the entire experience, and might serve as a barrier to entry for new players. Giving players the option to remap their controls does a lot to prolong a game's lifespan, but it does not make it immortal. Games released on the Wii U's Virtual Console allow players to fully remap the Gamepad buttons, but in the case of N64 games, this doesn't compensate for the fact that where the N64 controller had four C-Buttons, the Gamepad has a second Analog Stick. In the case of Ocarina of Time where the player assigns items to these buttons, the Analog Stick is an awkward substitute. As game consoles adopt ever more varied controllers, each with their own features (some might call them gimmicks) it will make it difficult to recreate those control schemes in future. This is why, even if a developer has built in a relatively robust control mapping system, it does not guarantee immortality. After all, can you really create a control customization system that accommodates the potential lack of analog sticks where your game normally relies on them? The more complex your game's control scheme is and the more tied into controller specific functionality it is, the more likely it will need to be (at the very least) retouched to keep it accessible to players.

Giving players control over their controls is incredibly helpful in prolonging a game's lifespan, but cannot guarantee immortality

Further to updating a game's controls, developers would do well in retouching the game's entire interface and menu systems. There is an adage when it comes to planning concrete paths across a campus; simply plant grass the first year, then wait and see where the grass has worn down before constructing the permanent paths, as this will be a perfect indicator of the paths people take as they move from building to building. If a game has been out for years, developers can look at which actions players want the fastest access to, and build in these quick-access options directly into the new menu system.

Giving players quick-access to the options they use the most will go far in making the remaster more accessible

While the most significant way to improve a game's accessibility is through improvements to its interface, most remakes usually take the opportunity to improve the original game's artwork, and for good reason. While some games have a stylized art style that can stand the test of time, there are many games which tried to have a "realistic" art style in their time, few of which have aged gracefully. Specifically, improving the artwork of the "photo-realistic" games of the N64, PlayStation 1, and Original Xbox era would, in many cases, constitute an accessibility improvement. Given how important artwork is in directing the player's attention and aiding them in traversal of game environments, when a game's artwork can improved through the availability of newer and more powerful hardware to run on, this can improve the entire gameplay experience. And, let's be honest, many gamers (especially young ones) are much more likely to try a game if it's graphical fidelity can match the standards of modern AAA games, so even in this way, improving the artwork of a game can help in making it more accessible to a new audience.

Improved graphics can improve the accessibility of a game just like improving its controls or menus, but only if that artwork isn't so flashy as to detract from the environment's readability

Even with a new coat of paint and an updated control scheme, sometimes there are significant things like a game's combat mechanics that (despite how good they were at the time) now feel dated, even to fans of the original game. This is usually due to hardware limitations or mechanics constructed around a limited range of inputs that leaves a game feeling "old", no matter how good it felt in its prime. This is where we enter the world of remakes; the chance to take inspiration from a game's original plot, characters, and setting, but ultimately create a new experience from the ground up. This is where developers truly need to decide whether it is worth creating a spiritual successor or numbered sequel instead. If the original game was particularly popular, the decision will probably land on a remake since this can help ensure a return on investment for all the resources that are going to be invested in what is essentially a brand new game. These are the kinds of games where the experience might be very different from the original game; entire sections added, altered, or even removed to keep things in line with modern pacing expectations. The most important thing a developer should seek to do in creating a remake is building upon the essential experience of the original game. So long as they can preserve (and hopefully build upon) the original reason players fell in love with the original game, those same players and more will love the remake.

Above all, remakes must preserve the essential experience of the original game, for that is why players liked the game in the first place

Mathew and Attila discuss the growth of AAA games and how they seek to satisfy a larger audience. Games discussed in this show:

Final Fantasy XIII

Star Fox 64

Deus Ex

Star Wars: TIE Fighter

Mario 64

The Legend of Zelda: A Link Between Worlds

Wii Remote

VR: Vive and Oculus

Castlevania: Symphony of the Night

Extended Thoughts

As the game industry evolves, AAA games require more and more resources to produce and need to appeal to larger and larger audiences to remain solvent. To reach those larger audiences, developers need to craft multi-platform experiences that work just as well with a controller as they do on mouse/keyboard. This does not necessarily mean creating games that are expected to play identically on both platforms. If implemented poorly, this results in truncated controls and a worse experience on one or both of the platforms. Rather than creating the game based off of one control scheme and then porting it to another, developers need to consider all possible input methods right from the start, designing the control scheme to play off the inherent strengths of each while avoiding their weaknesses.

Poorly created Console / PC ports often feature a control which feels truncated on one or both platforms.

Sometimes it isn’t possible for a developer to create an experience that maps well from keyboard / mouse to controller, namely Real Time Strategy games. RTS games have long remained an example of irreducible complexity; we may never see an RTS fully realized on a traditional controller interface because it lacks the bulk of inputs offered by a keyboard and the precision selection capabilities of a mouse. If a developer wishes to extend the brand of a Real Time Strategy beyond the realm of its PC origins, they must consider the strengths and weakness of a controller. At best, they might create a game which takes place within the established universe of the franchise and features some Real Time Strategy elements with a different set of core mechanics. Any developer which does seek to create a truly cross-platform RTS experience is fighting an uphill battle, and will likely need to make some sacrifices along the way to make the game playable with a controller. It is these sacrifices which have die-hard PC gamers concerned, claiming that these changes are only for the worse and that it reduces the difficulty of a beloved genre. Of course, these claims are made of all sorts of genres, and “hardcore” gamers will further proclaim their distaste for the lack of difficulty to be found in modern AAA games.

RTS Games may be a tough nut to crack, but are all genres worsened by existing on console?

RTS games aside, one must ask how much the complexity of a game’s control scheme plays into its difficulty. In reality, complexity in control is one of the worst ways to make a game difficult. If a game presents an overwhelming number of inputs to the player, that by itself can make it inaccessible to certain players because it’s simply too much to keep track of. This is just as true of a keyboard as it is a game controller with too many functions mapped onto it. Rather, the best way for complexity to arise in a game experience are from the mechanics of the game itself; the results of the player’s inputs and all their possible combinations. By shifting the focus of a game's complexity away from its control scheme, developers have the opportunity to make the game much more approachable without sacrificing the complexity of the play experience. That being said, to make any of this complexity truly approachable, a game needs a good tutorial. If a player is taught enough about a game as to really dive into the depth it has to offer and feel like they understand the interplay of its mechanics, they are far more likely to have an engaging experience. From this sort of complexity, a much more satisfying difficulty can be woven, one which will appeal to far more players, both hardcore and casual alike. This is as true of sprawling RTS games as it is of simple Mobile time-wasters, whatever the scale of the experience, everyone can enjoy approachable depth.

Command and Conquer 4 - Now a MOBA?
Super Paper Mario - No longer an RPG!
Star Wars Battlefront
Final Fantasy
Kirby's Epic Yarn
Mario 2 / Doki Doki Panic 
Mario Kart
NHL Series
Rogue Squadron 3
Star Fox Adventures / Dinosaur Planet
Pokemon Black / White

Extended Thoughts

I'm sure everyone has had the experience where they've been excited to play a new game in a series only to try it out and find its not what you were expecting. There may be lots of ways in which a game can disappoint you, but this is specifically in regards to a game which ends up being almost completely different from the original save for perhaps a familiar looking world or a few characters you recognize. While sometimes a developer is accused of changing too little between entries in a series, in this case it feels like they've changed too much, resulting in an experience that is entirely different from what made you like the game in the first place.

When creating a new entry in a franchise, developers walk a thin line between changing too little and changing too much

While not always the case, it's possible the developer might have wanted to create a new franchise or spin-off of their original game, but then felt the pressure from the publisher of this new game not selling well because it isn't part of an established brand. As a result, the publisher may consent to funding the project on the condition that the developers brand the game as a new entry in an existing franchise. Of course, even if the developers are able to make a good game it will still result in something vastly different from what people expect out of the franchise, which in turn can lead to damning User Reviews and therefore less sales of the game in the long term. In the absolute worst cases, this can lead to players abandoning the series and the death of the entire franchise (at least temporarily, nostalgia can be a powerful resurrecting force). Given everything publishers stand to lose in the rebranding of a product as a new entry in the franchise, it speaks of incredibly short-sighted planning on the part of certain publishers that they consider this to be the "safe option", that, or it speaks volumes of what the publisher's sales charts must be telling them about consumer purchasing behavior.

Rebranding a game as a new entry in an existing franchise might make economic sense to Publishers, but it hurts the creativity of developers and the expectations of gamers.

It's a viscous cycle which needs to be broken to benefit developers, publishers, and players alike. Unfortunately, there's almost nothing the developers themselves can do to break the cycle since these decisions are tied up in the finances that fuel the creation of the games in the first place. Developers are at the mercy of whoever holds the purse strings, and Publishers likely won't change their ways unless the sales charts dictate that change. That means it's up to us as Players (and consumers) to vote with our wallets, aim to make informed purchases, and assist others we know in making informed purchases (assist grand-parents in picking out better games as gifts). There's a big rush to be the first to experience something, and it's incredibly tempting to get a new game in a franchise you love, but you've got to ask if the potential disappointment isn't worth waiting a few days to see the reviews. If we can pull this off, it will mean that developers everywhere will get their original ideas off the ground and inspire us with new worlds and the stories within them.

Prove to publishers that we want new experiences, vote with your wallet and reward innovative new games

Show Notes

Mathew and Attila discuss games that build themselves! The pros and cons of procedural generation. Games discussed in the show:

Rouge's ASCII World

Shadowrun's Infinite Quests

Speedrun - Free Arcade game

Mario Maker

Hotline Miami

Metal Gear Solid 5

Borderlands Guns

Galak-Z - Finding loot

Sudoku - Solve them with Algorithms!

Rubik's Cube - Can you solve more than one face?

Extended Thoughts

Having discussed Environmental reuse last week, I wanted to touch upon another game design tool; procedural generation. Advances in both hardware and software have improved the nature and quality of experiences generated by procedural generation. As the prospect of using procedural generation becomes more accessible, it is important to consider its use cases.

Can an algorithm create an experience as compelling as one hand-crafted by a designer?

When talking about procedural generation it will be useful to break it up into two distinct categories; procedurally generated experiences and procedurally generated environments. A procedurally generated experience is one that takes place within a fixed environment (an "endless" mode in a game where enemies keep spawning according to a set of rules) while a procedurally generated environment is the physical space that an experience takes place in (a randomly generated dungeon). A procedurally generated experience can take place in either a hand-crafted environment or one that was created with procedural generation, whereas a procedurally generated environment can only play host to a procedurally generated experience as the level will never be seen by a designer.

Procedural Generation systems can create environments, experiences, or a combination of both!

Procedural generation may seem like a great tool for small teams to quickly build out the physical terrain of large game worlds, but there is a significant time cost associated with creating that system in the first place. To break down this time cost, lets go over the basics of how a procedural generation system is built.

At its heart, a procedural generation system is a constrained means of creating random outputs. Those outputs can be (but aren't necessarily limited to) the experiences or environments you are seeking to create. The constraints are made up of the very same rules you would use as a designer when creating your game (certain enemies must be placed on the ground, power ups should not be placed on spots players cannot reach). Certain "rules" will no-doubt be easier to recreate in code than others. The more elements there are in your game, the more the constraints grow exponentially as all possible inter-relations of those elements must be taken into account. Consider this example from a platforming game like Super Mario World; while it might be easy to create a system that does a position check to ensure that Goombas are always placed on the ground, it might be more difficult to ensure that those Goombas are not placed in such a space in which it will make it impossible for Mario to jump up through a one-way floor. Of course, you could create a simplified set of rules for such a game by only generating terrain which can be traversed through a series of easy-to-perform jumps; making "safe-guesses" as this will guarantee that you'll end up with something playable. Of course, "playable" can be a long way from "fun". Ultimately, you need to decide if the scope of the project you are working on merits the time investment necessary to create a procedural generation system, or if that time would be better spent hand-crafting your levels.

As the number of constraints in your procedural generation system grow exponentially, is it worth simplifying the system to just make "safe-guesses"?

Whether or not you ultimately use procedural generation to create your game environments, it can be an excellent tool for decorating them. For instance, if you are creating a large open-world where the emphasis is on filling a large area with decoration, you can use procedural generation to fill a space with a set of randomized elements. For example, in creating a city, it would be incredibly tedious to decorate all the roads with lane markings, cracks in the pavement, weather damage, etc. but you could easily feed these details into a procedural generation system and have it do a large amount of the work for you, so long as you take the time to look over what the computer came up with and verify that it didn't make something outlandish.

On the experiential side of things, procedural generation is excellent at creating certain types of puzzles, specifically ones with simple rule sets like that of a Rubix cube. The possible movements the cube can make can be encoded and then applied as a shuffling algorithm to scramble the puzzle.

One of the most basic examples of procedural generation; a random-shuffling algorithm

The same sort of logic can be applied to creating a Sudoku. A completed board can be generated which adheres to the rules of a Sudoku, then numbers can be deleted from the board at random to create the puzzle itself. That being said, any puzzle which is created by an algorithm can be solved by an algorithm. Relying too heavily on procedurally generated puzzles can get boring or frustrating because the computer can actually spit out puzzles faster than it takes a player to solve them. At that point, the challenge being presented is as arbitrary as playing 52 pick-up. That being said, lots of people still enjoy Sudoku puzzles and solving scrambled Rubix cubes, I don't mean this as a slight against that sort of entertainment, but with the power and flexibility afforded by modern game devices I personally believe we can create puzzles that are more varied and satisfying to solve. 

As with all tools available to a game designer, if you decide to use procedural generation in the creation of your game, or as part of the game experience, you must consider all the implications of the randomly generated experiences that the system can produce. Investing a lot of time into a well built procedural generation system can create a near-limitless number of possible experiences, but volume does not substitute for the quality of an experience. It is highly important to start with a fundamentally strong game-play experience, only then should you consider which elements of the experience can be handed over to a procedural generation system.

Games and other things we mentioned in order of appearance.

Robo's World: The Zarnok Fortress, available on Steam

Metroid

Metal Gear Solid

Metal Gear Solid 5

Twilight Princess

Ocarina of Time

Wind Waker's Triforce Quest

Quality of time over length of experience

Super Mario 64

Super Mario Sunshine

The Last of Us

Minecraft

No Man's Sky

Extended Thoughts:

For a number of reasons, be it conscious decision or a simple lack of budget, you'll see environments reused in games quite often, much to a gamer's dismay. I feel that the reason we dislike retreading ground in games stems from our experience retreading ground in our day to day lives. I think most people have some sort of routine where they take a familiar path to and from work every day, and when we play games we want a contrast from this monotony. We want an endlessly new and interesting world, and it's all too easy to call the developers lazy for not creating new environments for each new experience.

Environmental re-use is at its best when you can have a unique experience within a familiar environment.

Instead, our focus should be on unique play experiences. If a game is making you retread the same ground and perform the exact same task while nothing about that experience has changed, then yes, you have a right to call the devs on it.

Twilight Princess:

But let's look at the example of playing as the wolf in the Twilight sections of the game. Your control scheme is familiar, but your means of traversal are different. You have a different objective then simply "get from point A to point B" as you do when you are a human. You are tasked with hunting down a number of insects which which hold the key to forward progress in the form of Tears of Light. True back-tracking (turning around and going back the way you came) is possible to allow for players to fully explore an area if they fear they've missed a Tear, but isn't mandatory. Upon finding the last one, you are granted instant passage back to the point where the Tears are redeemed. I think this is great design choice because even if the designers had taken care to make the return path an interesting one, it's so psychologically draining to have to "go all the way back". I think devs might be tempted to make the player leg it back to the start out of some distorted sense that this will help inflate play time and make people think they are getting more value out of the game.This is not at all the case. First of all, it's painfully obvious when a game is forcing you to back-track and everyone feels that immediately. Secondly, going backwards isn't really adding any value to the game. If it was well designed, back tracking should always be possible in the emergency sense discussed earlier, and therefore shouldn't be held up as something exceptional. It's aimless traversal at best, and a nightmarish grind at worst, like swimming up stream against a level which was designed to be played optimally in a single direction.

Back-tracking should be possible to allow the player to go back in case they missed an objective, but otherwise it feels like swimming up-stream, against the flow of the intended level design.

In the case of Twilight Princess, there are clearly some parts of the game that are "world" and some that are "level" and this is an important distinction. "Levels" are dungeons, temples, or any other part of the game you can expect to go through in a linear fashion. Re-treading these "levels" is the least fun because it can be difficult to create a vastly different experience within a space that was so tightly designed. On the other hand, the "world" includes locations like Hyrule Field and the Towns in the game; locals which are not hives of combat or puzzle solving, but open space that knit the levels together. Free-roaming is the name of the game in places such as these.

Certain zones serve a utility function within the world, like shops in towns, and we can expect to return to these areas as we explore the areas of the world around them.

Until the day when we can spawn complete experiences from our brains, environments will be re-used in games. Twilight Princess handles environmental re-use very elegantly because it always seeks to provide the player with a new experience within familiar environments.

Paper Mario: The Thousand Year Door

With Twilight Princess being a great example of "environment reuse" done right, I wanted to turn a critical eye to PM:TTYD. I'll just quickly preface that this is one of my absolute favorite games of all time, and I've played through it about 6 times, on an average of 22 hours per file. If anyone has played the game anywhere as much as I have, there will be a few segments that probably stick out in your mind for having an inordinate amount of back-tracking.

Despite how much I love Paper Mario, there are several brutal instances of back-tracking in the game.

That being said, Paper Mario has a nearly flawless difficulty curve. When you enter a new area, you're always just around the right level to fight the enemies in that area. Cutting out all the back-tracking and subsequent enemies that you fight while back-tracking would mean you no longer have the experience necessary to be at the correct level. It'd be like playing Pokemon and dodging all the encounters with random trainers. Sure it feels like it's saving you time, but in the end you need that experience and it's only worth fighting those trainers when you first see them, otherwise you're too over-leveled.

So clearly Paper Mario is constructed around the back-tracking, but these are still parts of the game which I would gladly skip if given the choice because they aren't adding to the experience. There's nothing new or exciting about running back and forth four times between Twilight Town and the Ghostly Manor. In fact, in this part of the game there's a pretty strong implication that you should be fleeing every battle, but this feels awful as a player, and you can loose a lot of saved up coins.

Paper Mario, and lots of other games in similar situations, would have been objectively better games if they had cut down on the back-tracking.

On a back-of-the-envelope calculation, I estimated that you could crop out about 7 hours worth of back-tracking out of the game, and that would have left it a much tighter experience. Make sure you don't cave into people clamoring for "dollar per hour" game experiences. It's far better to keep your eye on your "awesome per second" ratio.