Where do you start and end (and miss out) with game designing?

I’m mainly asking for large parser/parser-hybrid games. Where do you begin?

Personally, I go for a puzzle approach, then map, then I make a walkthrough of the game. Sometimes (like the next game I’m making) I began with a score system. But I doubt anybody does that.

Also, do your games usually have a properly coherent puzzle/story line? So far I’ve had to do quite a bit of removal of the bootstrap paradox (“you need the bone to unlock the door”, but I’ve implemented no key) and chicken-and-egg paradox (“you need the key to get into the room with the umbrella, but you need to use the umbrella to get the key”).
Anybody else get that?

2 Likes

I believe the best parser-IF games are designed with a core system of rules, like a magic system. Then a story forms on top of that system. Plotkin and Short are likely the two best IF authors at this type of game development and have written extensively about it.

5 Likes

Start with the story, surely?

2 Likes

I have started two games with only the ending of a story in mind.
I continued by thinking about what it would take to get there.
Characters in stories often encounter problems along the way. What problems might come up in the course of things?
Finally: what would be mechanically interesting about that?

5 Likes

I wrote three games with the mechanism in mind first, then built stories around that. When I wanted to do a game that used emotions as a limited command set, I had to think about what type of PC would do that, and a poltergeist was the obvious answer, so WHHoGG all came from that. The others started with story ideas first. The only game I’ve written where I knew what the ending would be was The Spectators, and that’s because I based it off a poem that gave me the ending. I have trouble with endings, which is why I have 3 games on the shelf in varying stages of completion that I can’t figure out how to end.

I am plagued with these in puzzle design, but I actually find it enjoyable to make a puzzle flowchart that solves these. And sometimes getting myself out of corners like these yields good ideas.

5 Likes

For my first, and only, IF game so far I started with the idea of writing a sequel to H.G. Wells’ “The Time Machine” and exploring the idea of what happened to the protagonist time traveler after he disappeared into the future.

I wanted it to have a narrative feel so I realized I had to have a few characters for the player character to interact with and puzzles as gating mechanisms for the story (old school text adventure stuff).

My original idea morphed into a sprawling epic that I had no idea how to implement as I spent months, maybe years, gathering ideas. Eventually I pared it back to something more manageable, created a dependency diagram to map out the flow of a more simpler game with a minimal number of characters, and started coding in August 2020 for Parsercomp 2021.

Since it was my first time writing Inform 7 and time was tight, I was forced to pare things down even further but was please with the final entry (currently working on v2.0, sick of it, hope to release by the end of the year).

My next game has a different genesis. Tentatively titled “Muskville,” it will have a simulation back-end similar to Infocom’s “Suspended” but over the past few months I’ve realized that it needs a more “human” element to it so I’m considering the option of adding interstitial stories and vignettes using Inform 7 scenes which feed back into the simulation aspect.

I guess for me it starts out one of two ways: with an interesting technical challenge (link) or an interesting dramatic situation or scenario. Both will probably be in any IF game I create going forward but the initial Aha! seems to come initially from one of those two areas.

I do like the idea of building out from a core system like @DavidC suggested, but I just don’t have enough experience with the medium yet to do that (though, on second thought, I guess the simulation aspect of “Muskville” could be considered a core system. We’ll see.).

Update: I should also mention that I am focused right now on using Inform 7 exclusively and working within its constraints. Too often in the past have I been seduced by the latest programming language, framework, or tool instead of doing actual game development.

9 Likes

For me, game dev is something like:

  • I always have a bunch of half-ideas bouncing around in my head not accomplishing much of anything
  • Every once in awhile several of these spontaneously congeal into something that might be a game design
  • I have to take conscious effort to evaluate whether a congealed lump of half-ideas is big enough to land or if it needs to be thrown back in the pond. Deciding this usually means checking if it has either a) a definite beginning and end, or b) an inner gameplay loop that’s compelling in and of itself
  • If the idea is “big” enough to get this far, then I think about what the game is “about”. And whenever you’re making a game (or anything else) “about” something, it’s not about what it’s “about”, it’s about whatever what it’s “about” is about. So a game “about” the Illiad is probably actually about hubris, because the Illiad is “about” hubris, if that make sense
  • With the basic gameplay hook and the basic narrative hook in hand, then it’s throw-everything-at-the-wall-and-see-what-sticks time. This is where I intentionally whiteboard out about ten times as much game as I could ever actually implement
  • Then I play Jenga on the design, removing things until everything breaks, adding the last load-bearing design element back in to produce the minimum game design. That’s the implementation target
  • Then as the game is actually implemented, it will inevitably turn out that some of the things that I had identified as essential aren’t, so they get removed. Some of the things that got removed as inessential will get added back in to fill the gaps. And independent of the core game design, a bunch of things I liked from the whiteboarding phase can get added back in, basically as doodles in the margin of the final design: not part of the core design, but as details that give the game a more lived-in feel
  • Playtest until I can’t bear to look at the damn thing anymore
  • 10,000 years later, the game is released
8 Likes