Gameology

Gameology

By Mathew Falvai and Attila BranyiczkyVideo Games
Download on the App Store

Gameology episodes

  • Gameology 23 - Trading / Collectable Card Games
    Show Notes:

    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.

    44 min
  • Gameology 22 - Building Accessible Board Games
    Show Notes:

    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.

    36 min
  • Gameology 21 - Luck vs Skill
    Show Notes

    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!

    22 min
  • Gameology 19 - Microtransactions
    Show Notes

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

    41 min
  • Gameology 18 - Meaningful Choice
    Show Notes

    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.

    22 min
  • Gameology 17 - Narrative
    Show Notes

    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.

    28 min
  • Gameology 16 - Case Study: Shovel Knight
    Show Notes

    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.

    27 min
  • Gameology 15.5 - Pokemon GO
    Show Notes:

    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.

    16 min
  • Gameology 15 - Death
    Show Notes:

    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.

    25 min

About Gameology

From the publisher's feed

Let's talk Game Design! Unique perspectives and discussions between a Gamer and a Game Developer. Featuring Indie developer Attila "Gabriel" Branyiczky of Bluish-Green Productions and Mathew Falvai