Saving/Loading and Pseudorandomness in single-player games

Posted on 1 CommentPosted in 2018 Workgroup Topic Proposals

This is one of those things that strikes me as an unsolved problem in game design. As Raph said in his book, players tend to gravitate towards game exploits even at the cost of their own fun. The solutions that prevent player exploits also tend to punish players for the horrendous sin of actually trying to play our game honestly. Some examples:

Save anywhere, saving your random number seed: game is predictable. Quicksave before a boss and know exactly what it will do. Quicksave before gambling in the in-game casino and know what numbers come up. Premonition as a superpower.

Save anywhere, without saving your random number seed: repeat until success. Quicksave before any risky thing, try it, reload and retry if it fails. Infinite time reversal as a superpower.

Save only at save points that are far enough apart to make save-scumming inconvenient: punishes players who have busy lives and can’t have their game held hostage until they find the next save point, and a pox upon the level designer that forgets to put one in somewhere that leads to a mandatory 2-hour play session to progress.

Save anywhere but with limited saves: without consulting a strategy guide, player has no way to gauge when to save, inevitably ends up conserving their precious saves, playing conservatively, spends half an hour clearing out an area with relative ease, accidentally wanders into an insta-death trap and has to repeat the whole process, rage-quits.

Save anywhere, limited saves, game strongly telegraphs when danger is coming: may as well have just used save points in those areas, why did you even give the player a choice that’s obvious.

Save anywhere, but only one save at a time, game deletes save upon reload so save-scumming is impossible: power goes out and player loses 50 hours of progress, tracks down and kills game designer, claims justifiable homicide.

Autosave at checkpoints: basically the same problem as save points, just without the extra button-press to save.

 

Can we find a better way, or at least map and explore the design space with save/load systems to quantify the tradeoffs so that the least-damaging system can be chosen for a specific application? Could we make a tool that presents a questionnaire with a bunch of options and uses the answers to spit out a functional design doc to save future designers the time and trouble of reinventing the wheel with every single game they work on?

Games for Kids Growing Up

Posted on Leave a commentPosted in 2018 Workgroup Topic Proposals

“How to design games for kids” is a well-tread topic in the game industry (both industries, actually, digital and tabletop). There are two areas of this that seem to be unsolved problems that I’d like to move the needle on, though.

First is that kids grow up. Most games are designed for a specific developmental stage, and once the kid passes that stage, they outgrow the game. Is there a way to design games that will grow with a kid? I’m not just talking educational games with advanced content, or standard games with difficulty levels that get harder as the player advances in skill while keeping the same mechanics. I’m talking about a core game that starts off very simple, and then gets more mechanically sophisticated once the player can handle more advanced concepts. (On Facebook, I proposed Candyland Legacy that starts off like the traditional children’s game and then gets more complex mechanics and interesting choices added to it each year on the kid’s birthday or when the parent thinks the kid is ready, where the game might ultimately evolve into a heavy strategy game for 12+.)

Second is that many kids have siblings of varying age ranges. Since games are often designed for a specific developmental stage, any given game is either going to be too advanced for the younger kid or too boring for the older one. This is similar to balancing a game for players of wildly different skill levels, but different in that players don’t just have different game skills, but different life skills in general. Adding a handicapping system is one thing, but how would you do that when (for example) some players can read and some can’t?

Armor for the Game Developer Soul

Posted on 2 CommentsPosted in 2018 Workgroup Topic Proposals

The game industry can be a wonderful place, but it can also be harsh. Each year, we lose more skilled veterans to burnout, frustration, or plain old poor treatment. The games we make have a very human cost. While each of us can individually try to make our own personal bubbles of excellence, realistically, game industry culture and treatment of devs changes slowly, and this isn’t something we can fix on a macro scale in a weekend.

A student once said to me: “I realize that this program is supposed to prepare us for industry, and I know the industry can be rough… but you realize there’s a difference between poking us with sharp sticks so we grow a thicker skin, and equipping us with armor… right?” This stuck with me as something to consider, not just for students, but for developers at all levels.

I propose some of us work on a set of tools that could be applied on the individual level to protect against the worst the industry has to offer. Not because it should be the individual’s responsibility to deal with a broken system, but so that fewer people can be broken. Let’s save some lives and spirits of our fellows.

Design for Passivity

Posted on Leave a commentPosted in 2018 Selected Workgroup Topics, 2018 Workgroup Topic Proposals

YouTube streamers have become a major force affecting the game industry. We now live in an environment where games don’t just have to consider what it’s like to play, but also what it’s like to watch.

Professional sports have been designed this way for many years (although we only get a new one of those that catches on once every several generations), but it’s a relatively new design consideration for today’s video game and board game designers.

The purpose of this group would be to create a set of core design principles and best practices specifically towards creating games that are at least as fun to watch as they are to play.

Definition of “game”

Posted on 1 CommentPosted in 2017 Workgroup Topic Proposals

Inspired by this thread: https://www.facebook.com/thebrenda/posts/10155664616687387?pnref=story

Creating a definition for the word “game” that doesn’t exclude things that are obviously games, or include things that are obviously not, is hard. It may be entirely impossible. Many individuals have tried and failed. No one has yet succeeded.

That would certainly qualify this as one of game design’s hardest problems. Perhaps if we bash enough of our brains together, we can find a better answer than any that has come before. Or at least move the needle slightly in the right direction.

Overcoming Grief

Posted on Leave a commentPosted in 2017 Workgroup Topic Proposals

I recently got posed an interesting design challenge: how would you design a game specifically to help players heal after the loss of a loved one?

There is plenty of literature in psychology about stages of grief, normal vs. pathological grief, and how the commonalities and differences in how loss affects people, and there are some games that deal with the topic in various ways, but to my knowledge there’s no easily-digestible set of best practices for dealing with themes of death and loss. So, let’s make one.

Avoiding n00b design mistakes

Posted on 2 CommentsPosted in 2016 Workgroup Topic Proposals

The difference between a junior and senior level game designer: the junior sees all kinds of “design decisions” that aren’t decisions at all to the senior, there’s a clear right answer that the senior already knows through experience; meanwhile, the senior’s decisions are things that the junior doesn’t even see as decisions because they don’t realize there are alternatives to consider at all.

Can we find ways to ramp juniors faster? I’m thinking a list of most common junior-level mistakes, questions, uncertainties and their obvious-to-a-senior-level solutions, with the ultimate goal of making a short guide for first-time designers to get them more productive more quickly, by identifying core areas that they tend to miss if left to their own devices.

Screw game design, let’s solve the WORLD’S hardest problems

Posted on 3 CommentsPosted in 2015 Workgroup Topic Proposals

We like to talk a good game about how design thinking or systems thinking is relevant in all kinds of areas outside of game design, and how the world is full of (hackable) systems.

Let’s prove it. Let’s get some great design minds together to figure out how to game a real-world system.

Politics is full of systems. Could we get one or more game designers into a high-ranking public office?

Human biology is all about systems. Can we cure cancer?

Economic systems drive our lives. Can we figure out a pathway to get to a post-scarcity society?

Something along those lines.

Fixing Online Harassment

Posted on 1 CommentPosted in 2014 Workgroup Topic Proposals

The industry is currently, for lack of a better word, under attack. This isn’t an isolated case, but something that’s part of a larger system. If anyone knows how to analyze, understand, and ultimately control systems, it should be game designers. So maybe we should say, fuck “solving game design’s hardest problems,” and instead use our time together to solve some of the hardest systemic problems out there in the rest of the world, as they are affecting our industry anyway.

There were some idiots out there targeting a bunch of academics at DiGRA on the theory that they are some kind of secret shadow organization that controls the game industry, apparently oblivious to the existence of PH. Clearly, if we work on this topic, the standard Code of Secrecy/Blabbing will need to be considered carefully, to protect all concerned.

Game balance

Posted on Leave a commentPosted in 2014 Workgroup Topic Proposals

Nearly every game project has, at some point, some designer doing work on balancing. Yet there is a dearth of resources explaining how we do it. Let’s get some heads together and figure out if any of us even do this in the same way, and if there’s a way we can formalize our methods so that others can make use of them.

(I realize balance is a massive topic, possibly beyond the scope of our ability to cover over a single weekend. If so, we can choose a suitable subtopic to elaborate on.)