Designing the best game I’ll ever play

Posted on Leave a commentPosted in 2018 Workgroup Topic Proposals

If I had the rest of my life, what game would I make, for ME? None of us want to waste the time we have on this mudball. We all want to make Art that has a lasting impression on this world. I’ve had a few moments with peers to muse about the “greatest possible game ever”. It made me realize that the “greatest possible game ever” is different for everyone.

In thinking about making MY “greatest possible game ever”, I started by picking all the games I really like, and culling out the game features and mechanics I really like. It would be like X-Com, but with story like Jagged Alliance and also Motorsport Manager. A post-apocalypse world like Fallout. A hero management mechanic, like Heroes of Might and Magic.

Smashing together all the best parts of all the best games.

But isn’t that caveman thinking? By myself, I can’t think of a better way to do want I want.  But it feels reductive and shallow.

So perhaps, in a group, we can figure out not WHAT sort of game to make, but (the process of) HOW to design the best game I’ll ever play.

Verbs from the edge

Posted on 3 CommentsPosted in 2018 Workgroup Topic Proposals

Games are interactive, and we often think of interactions as verbs. Run, jump, shoot, get, unlock. Any of us can conceive of a game that uses these verbs.

But games are a huge market, with loads of competition. To break from the crowd, we can try to find verbs that no one has used in a game. We can also try to design games that don’t rely on verbs (at least in the way we normally use them).

I’d like to be part of a workgroup that collects and documents ways to break from the common verbs of game design. I think we could focus on 1) finding verbs that are unused in games, 2) find design paradigms that can’t be reduced to verbs, or don’t rely on verbs, 3) finding ways to combine verbs in new ways to produce unusual gameplay.

Game systems that display themselves

Posted on Leave a commentPosted in 2017 Workgroup Topic Proposals

Much of my game development can be described as “rapid prototyping”. But what’s not rapid is GUI. It’s a basic rule of thumb, that when I add a mechanic or value to my game prototype, I must then budget more time to create the GUI that exposes that feature to the player. And, despite my raft of helper functions that make GUIs a bit easier for me, it’s a hand-creation process that always takes time, especially if I want it to look pretty.

What if the basic variables that were members of a game object were smart enough to display themselves? What if you could have a member function called
::DrawMyData(RECT screenRect), and it would just magically draw all the important data of the object? And it drew the data in an intelligent way, giving more space and color to the most important data? And it did so no matter what size or shape of bounding rectangle you gave it?

Is it possible? Sure, but there’s lots of little details that would have to be worked out and coded.

Is it useful? Perhaps for lone-wolf rapid-prototypers like me, but for everyone else? I don’t know.

Assuming the idea would be useful, I’d like to explore the concept, from both coding and aesthetic perspectives, with an interested group.

Writing for the Ludonarrative

Posted on 4 CommentsPosted in 2017 Workgroup Topic Proposals

We all know the basic tension between Narrative (the story the game developer tells the player) and Ludo-narrative (the story the player creates while using our game).  Everyone talks about ludo-narrative dissonance, but this is not about that.

We all assume that Narrative in games is supported by lots of writing, while Ludo-narrative is supported by gameplay and emergent events. Recent experience shows me that’s not really accurate. In fact, I’ve seen lots of Ludo-narrative that’s cleverly supported by pre-written text.

Over 20 years ago, the Jagged Alliance games had lots of small chunks of writing that focused on the relationships between your hirelings.
The Fallout series has writing that supports major and minor game decisions.
Motorsport Manager has lots of small chunks of writing that support game events, and help the player contextualize them, especially regarding the drivers and mechanics you’ve hired for your racing team.
Out There and FTL have lots of text event trees that help define the game.

 

These examples show us that ludonarrative can be and is supported by writing. But while there’s lots of writing about writing for videogames, I haven’t found any resources that address this sort of short-form writing. Tree-structure-dialog writing IS well documented, and there is some overlap, but not enough.

 

Let’s discuss short-form writing designed to support the ludo-narrative, and assemble some best-practices.

 

Games that are BAD for you!

Posted on 2 CommentsPosted in 2016 Selected Workgroup Topics, 2016 Workgroup Topic Proposals

Many game designers (myself included) have been thinking about how to make games that aren’t just fun, but also make people better, and/or change the world for the better.  It’s hard, ’cause while we know of games that already try, it’s always harder to evaluate game MECHANICS for “goodness”, instead of just “fun”.

So I had a thought; suppose we find the games that benefit us (as humans), by trying to find the opposite of games that hurt or poison us (as humans).  And to do that, we first have to find, study and design games that hurt or poison us (as humans).

Clearly we’ll run straight into the embedded thinking we all share; games are Art, artists can do what they want, personal responsibility, who are you to judge, blah blah blah.

And I can’t help the thought that this workgroup might be creating Ultron, or otherwise Meddling in God’s Domain.

Still, I’d like to join a few brave, foolhardy souls in an examination and analysis of games that are BAD for us (so we can eventually make games that are GOOD for us).

Jimmy and Jane

Posted on 3 CommentsPosted in 2016 Workgroup Topic Proposals

Let’s imagine two college students, Jimmy and Jane.

Jimmy got electronics kits from his dad when he was 8.  He was soldering when he was 10.  He always had access to the family computer, and was writing simple computer games by himself when he was 13.  Everyone around him said Jimmy has such a bright future with technology.

Jane had none of those advantages, but now they are sitting next to each other in a class called “Intro To Computer Game Design 101”.

Jimmy shines brightly in this class, exceeding the scope of every assignment and letting everyone cluster around his computer to see his latest and greatest.  Jane is confused, doesn’t know where to begin, and (with Jimmy right there) is intimidated into believing she isn’t ready for the class.

So she drops out.


Let me stress that 1) Jimmy and Jane have the same POTENTIAL, and 2) Jimmy isn’t TRYING to discourage Jane or anyone else.  Even so, this situation is a real world problem.  I know, ’cause I saw it happen in a class I taught.  “Jane” DID re-enroll the next year, completed the whole 2-year degree, and even shined as the best level designer (using UnrealEd) in the class.  But this is a particular sub-set of the problems facing goals of more gender diversity in our industry.

I’d like to work with a group to detail best practices to 1) nurture and protect Jane’s entry into videogame development, while 2) not punishing Jimmy for his advanced skills.

Computers are tiny and cheap!

Posted on Leave a commentPosted in 2016 Workgroup Topic Proposals

I just bought a raspberry PI zero.  It’s the size of a stick of gum, it’s a complete computer (plays minecraft and browses the web), and I got mine from Microcenter for $0.99 .  This isn’t unique.  Ardunio, beaglebone, CHIP, small cheap hackable computers have entered a new age.

So far, the game-related uses of this new age appear to be hand-held MAME players.  Meanwhile, everyone’s innovating over in the AR/VR space.

I’d like to work with a group to brainstorm how to use the new age of small cheap hackable (wearable, hideable) computers to make  innovative videogames.

Computers are fast!

Posted on Leave a commentPosted in 2016 Workgroup Topic Proposals

We have more computer horsepower at our fingertips than ever before.  But I still use a text editor to program.  And while 3D artists will use a more sophisticated editor to do their work, the point is still that we have way more cpu power than we realize (especially since our computers can run all night), and use it way too seldom for game design.  SETI@home and Folding@home are (now relatively old) examples of how to use brute parallel-ized computer horsepower to try to solve problems.

I’d like to work with a group to brainstorm how to use our computer power in innovative ways in the service of videogame development, and especially in the service of videogame design.

discouraging the dick

Posted on 3 CommentsPosted in 2015 Workgroup Topic Proposals

One of the most requested changes to my game would let users edit the name of their spaceship. When I finally added that, they immediately named their ships “dickbutt69” or something similar. I recognize that this is part of the larger axiom, that if you give game players a creative tool (even a text entry widget) they will immediately make something obscene.

But it annoys me, and I have anecdotal evidence that it harms the game ecosphere at least a bit. So now that we’ve all acknowledged that this behavior is innate, I’d still like to explore ways to minimize and discourage it.

The “Bruce”; reexamining the job descriptions within game production

Posted on Leave a commentPosted in 2015 Workgroup Topic Proposals

On the podcast “designer notes”, Bruce Shelley detailed his past work relationship with Sid Meier, which resulted in historic games. He would receive a near-daily build from Sid in the morning, play it til lunchtime, and spend the afternoon with Sid discussing his analysis.  He also built levels and game content.  As he described his job, it became clear to me that his role, while critical, didn’t FIT into any existing videogame developer “roles/jobs”.

Shelley describes a job that isn’t tester, designer, or producer, but does a lot of each. Just as importantly, his job could not be held apart from the rest of the team; it was a VERY tightly integrated support role for Sid Meier, who was doing the programming and iterative design.

I think we need more “bruces” ( I know I do). But we could also ask ourselves; how can we smash the pidgeon holes that the games industry stuffs us into, and make up our own job descriptions?

Computer horsepower and videogame logical correctness

Posted on Leave a commentPosted in 2015 Workgroup Topic Proposals

PART ONE: Over the last decade, I’ve marveled at the increasing computing power we all have available, and I’ve asked many colleagues the question: How can we use this raw computing power in the service of game design? The answers have been dis-satisfying. Most seem confused by the question. Some proudly talk about nightly builds and backups. Others describe how art tools are used.

My mind immediately goes to GA, genetic algorithms, a powerful (and computationally expensive) way to find optimal solutions to specific problems. Unfortunately, GA requires a “fitness function”, and most of the “fitness functions” I can think of (in regards game design) determine something AESTHETIC, which is really the domain of the human mind.

PART TWO: Imagine you’re making an adventure game. In act 1, the player gets a flashlight. In act 2, the player finds a trashcan, which deletes anything the player drops into it. In act 3, there’s a dark room that requires the flashlight to traverse it. Thus, the player can accidentally choose to make an unwinnable situation for themselves.

This is a “bug” in the game design, and there are a thousand ways to fix it. But how do we avoid making the “bug” in the first place? Talk to game designers, they’ll tell you “that’s what testers are for!”. But testers can be expensive, especially for indie developers, and they aren’t a magic solution.
But also, since this problem is a “bug”, I could essentially be asking for a game language that has “prove-able correctness”, a computer science problem that has never been solved (for general cases). So, way too hard to solve.

FUSE THESE: With the new computer horsepower we have available, I suggest we revisit the idea of testing games “brute-force” (examining every possible input combination) for correctness. I also propose that we use text adventure games as a first step, because of the limited and discrete choices those games are known for.

So I’d like to spend time examining the innate structure of text adventure games, and building a representation of text adventure games that facilitates computer “brute force solving”.  Understand that I’m not trying to “revive” text adventures/interactive fiction; I’m thinking about all videogames, really.

emotionally safe spaces in game development

Posted on Leave a commentPosted in 2015 Workgroup Topic Proposals

Arguably, there’s a new level of social awareness in videogame development, led by young indie and LGBT groups. More specifically, I’ve read of groups that ask for (and sometimes demand) an emotionally safe space”, for working or creative interaction. As a boy in Texas in the 70’s and 80’s, I can’t imagine I could have asked for such a thing. I CAN imagine that those three words would have been alien nonsense to any authority figure I had contact with at the time. Throughout my career, “emotionally safe spaces” also did not compute. Every shop I worked in cared most about work output; emotional safety meant the ability to close your office door, and stress was just part of the job description.

“Emotionally safe space”. Does it matter for videogame developers? And if so, what are best practices to achieve it?