Did I Just Design a Problem?

Authoring General Design Discussions
1

I’m taking Ron Gilbert’s advice and trying to design an adventure game by using puzzle-dependency graphs. This turned a notebook page of events for (what I imagined was) a small game into this graph:

new
new1120×923 69.1 KB

First, the game looks a lot bigger than it looked in my notes. That’s okay if I don’t sleep much before the IFComp, but it now it also looks like there’s another problem.

I’ve got several layers of four or five simultaneously-open puzzles. If my math is right, this means that there are somewhere between 24 and 120 possible states this game could get into during the middle-game.

Did I just mess up? Or is this manageable? I could just make the game linear, but that would reduce player agency to the point where the game wouldn’t be very interactive.

1 Like
2

It’s impossible to say based just on the chart, but I’m guessing not? Like, qua chart this is maybe 20% more complex than the first section of the game I’m working on for IFComp, which I, as a non-programmer first-time game-designer pulled together in maybe two weeks. The charts for my other sections are probably each three or four times more complicated, since I implemented a lot of alternate solutions in those, but they also were pretty much 2-3 week projects to implement (of course testing and refining takes longer!)

But really, the point is that if you’re using a reasonably fully-featured IF language (and it seems like from the other thread that you are/will be) you don’t really need to worry about the raw number of different states, but rather the complexity of different interactions and how much time/interest you have in addressing those interactions.

So this is why it depends on what’s behind your placeholders – if grokking the wibble just turns the lights on in the room where the plugh is, that’s like two lines of code that will near-automatically handle what happens when a dark room becomes lighted, with no fundamental interactivity with what’s going on with the waldo or the fred or whatever. But if quxing the visions makes the PC hallucinate that every object in the game world looks like a different breed of dog, and the waldo, once found, starts wandering around the map setting random objects on fire, that will take a lot of work both to implement and to check for interactivity between different possible things that could be going on.

IMO these charts are helpful for figuring out how the player will experience the flow of the game and IDing some top-level design insights (like, grokking the wobble should probably feel like an early climax, since it culminates a bunch of the initial tasks, and you might want to make the grok/use plugh - find wibble/wubble sequence a little easier since it looks like that will be a longish, linear set of puzzles that don’t interact much with the rest of the game which could be frustrating as the player gets near the end). But I don’t think they’re much of a guide to the difficulties of implementation.

3 Likes
3

Whew. The graph looked bigger than I thought it would.

Most of the nodes will just be “sensible verb with obvious object” situations, but some of them will be more puzzley. I haven’t decided which will be which yet.

That’s what I was worried about. I guess I’ll find out soon enough.

I should probably work on the flow of the end-game more before I start designing the puzzles.

Thanks.

4

The majority of time is, I think, usually spent in devising appropriate responses for the wrong interactions, or coming up with plausible reasons why object A intended to solve puzzle B isn’t also an appropriate solution for puzzle C (especially if the player can encounter puzzle C before they solve puzzle B), rather than on implementing the “correct path”. (Or perhaps allowing object A as an alternative solution for puzzle C, but the problem with that is if objects are consumed in the process of solving puzzles, as is typical, it’s possible that the object originally intended to solve puzzle C wouldn’t be a good solution to puzzle B in its place…) So don’t forget to factor that in as well.

(On the other hand, I’ve never released a “real” story, so take this with a grain of salt.)

1 Like
5

I find it more useful to write down the requirements in a simple way and then make sure the game logic enforces them.

“You can get the qux at any time.” No problem.

“You need the lamp to go underground.” That’s important, write it down. Then keep track of which parts of the game are underground.

“You need the helmet, the sword, and the rope to reach the last room.” This is easy to keep track of. Maybe each of those is at the end of a chain of several puzzles – this means a lot of possible states, because the player could do any chain first or work on them in parallel. But you don’t have to worry about that.

(Just be careful not to embed assumptions in your game text. Don’t write about the sword glittering in the lamplight if the player hasn’t gotten the lamp yet.)

The main thing the graph is good for is telling you when you have a dependency loop. Say you need the lamp to get the helmet, and you need the helmet to get the wand, and you need the wand to light the lamp… that’s a problem. But you could have figured that out without the graph, really.

(There are also dependency problems that don’t show up in the graph. Alternate solutions present a real problem for graphs – there’s no good way to represent them in that format. Consumable resources are another.)

5 Likes
6

This brought up Hadean Lands trauma I didn’t even know I had.

2 Likes
7

I think LucasArts games wouldn’t allow that sort of thing. Zak, for instance, would just refuse to eat the sandwich he would need to feed the phone company’s guard dog later. Maybe that’s why Gilbert didn’t mention it.

That’s unfortunate.

8

Yes, but that still requires thinking of that interaction and writing a plausible refusal. It’s possible that the story system being used does this by default, but often the default message is not the most appropriate.

1 Like
9

Welcome to the wonderful world of parser game development!

I think you’re doing everything right: Considering the pros and cons of various languages, jotting down notes about the puzzle structure, asking questions on the forum. But you are vastly underestimating the amount of work that goes into these things.

Optimism is great for getting started on a project. Don’t feel bad when the deadline whooshes past—this could turn out to be the IFComp 2021 winner, if you keep at it!

3 Likes
10

I would agree with Linus’s sentiments. Making big parser games is hard. Adam Cadre claims to have spent 15 hours a day for 6 weeks straight on Photopia. I spent more time on a game (Color the Truth) than I did on my master’s thesis, about 200 hours.

There are other similar stories here: How long does it usually take to write an IF game?

On the other hand, Jon Ingold said about All Roads (an IFComp winner): “I wrote All Roads in 24 hours but to be fair I spent a wh[i]le after bug fixing and stuff. Probably only a few weeks tho” (https://twitter.com/joningold/status/1063055334779052038)

All Roads, though, is fairly linear, and was designed to be written faster than ‘My Angel’, his previous comp game. So I guess it really depends on your complexity you’re going for.

3 Likes
11

All Roads took 24 hours to rough out? Ye gods.

I will echo the above – I’m just wrapping up an Inform 7 game that will probably wind up being about at the Comp’s two hour limit, and it probably took me ~150 hours, including learning the language, with about a third of that testing and revision? And before that last chunk of polishing time it was pretty rough – building in lots of testing time is pretty necessary to getting a parser game in reasonable shape, I think. But I also started mine right around last year’s Comp and I was fortunate to have it lying around when COVID hit and I suddenly had more time sitting around.

Anyway, just echoing the wishes of luck regardless!

2 Likes
12

I think I read somewhere that the reason Activision shut-down Infocom was because they were spending 200 hours of development time on 8-hour games, which, I guess, wasn’t profitable.

That works out to 25 hours of man-time for every hour of play-time.

(I think it’s safe to say I won’t meet the deadline in a month.)

2 Likes
13

To be fair, it is possible to write a good short game in a short time. There’s a whole annual competion for games written in just a few hours. However, somewhat longer games tend to rank higher in IFComp, and IFComp judges are probably also less forgiving of the bugs that can only be eradicated by lengthy and thorough beta testing.

4 Likes
14

Worktime for my parser games:

  • Tingalan: ~300 hours over 2 years
  • Six Silver Bullets : ~300 hours over 2 years
  • The Dead of Winter: 24 hours over 3 days
  • I Summon Thee!: 16 hours over 2 weeks
  • Be There!: 4 hours in a single afternoon

you can definitely make parsers in any size. Knowing how to apportion the time is also important. Six Silver Bullets has a lot of “time invested” but it still drew a lot of deserved criticism because the parser was very stingy. I should have spent more time on the basics.

2 Likes
15

What about Skybreak!?

16

Skybreak! is approaching 800 hours of work now (I’m really hoping to get an update out sometime before IFComp). I don’t usually classify Skybreak! as a parser because there are a lot more menu options than text commands. While I dislike wading into the parser/cyoa wars it seems fair to distinguish here, because a lot of “design time” in parsers should go into the parser itself, whereas with a game like skybreak most of the options are “1, 2, 3,” and so on.

I am also about 40% done with a true CYOA/Parser hybrid which has more than 200 hours of work and which will hopefully be done in time for NEXT year’s IFComp or spring thing

5 Likes
17

One of the main reasons I switched from Inform 7 to a choice system was it significantly decreased implementation and debugging/testing time required to polish a game.

I’m the doof who back in the day would kill myself to write an entire parser game a few months before the competition. And my early games suffered severe scope and feature-creep due to lack of discipline. One thing I also discovered - even if you get your game done it’s incredibly difficult to find testers willing and able to thoroughly test during the last few weeks before the Comp if the story is of any significant length or complexity at all.

I literally started Transparent a few days before IFComp intents to enter closed, meaning I wrote that game in about a month. It appeared to be a small game as conceived, consisting of a treasure hunt through a mansion with about 16 rooms and a few outdoor locations, but if you’ve ever tried to play it, you understand the systems involved (photography, electricity, random ghosts moving around and doing things, an ill-conceived strict inventory and container system) are stupidly complicated and required tons of updates and corrections during the Comp as they were allowed on a limited basis.

(I suspect I might be the only author in history that has managed to make ClubFloyd ragequit a game because they got trapped in a room and couldn’t exit… :cold_sweat:) #iswearthisshouldbefixednow

The Baker of Shireton I did a little better. I had prototyped the baking system earlier in the year, and had scoped it as a base game with optional modular pieces - meaning if I ran out of time there were significant parts of the game I could cut. I started the main game about three months before the Comp. I still had to make several corrections based on stupid mistakes that resulted due to lack of thorough 2nd party testing since parser games allow for so many emergent interactions the author cannot even possibly consider themselves.

Fair was the parser game I did the best job scoping. I intended it to be short and replay-able, and had the entire game from beginning to end planned out in my head in the months after the previous Comp, and I severely reined in any attempt to make it more complicated than about ten locations and characters. Due to this, I planned to begin writing it three months in advance with milestones and based on previous experience it went almost without a hitch…

Of course I had one brilliant random last minute idea “What if I include time travel?!?” (facepalm) which almost wrecked the entire project: that was me at 2 AM the night before the submission deadline (despite having to work the next day) carefully picking through the code line by line and taking out all the freeform time-travel to limit the game to the parts where it worked properly. Then test test test test test like a maniac since no tester was going to have time to get to that part in one day.

  • Highly Recommended habit: if you’re working with a deadline, scope thoroughly and lock down your game beginning to end and don’t add stuff. Avoid entertaining ideas that might not seem difficult like “What if I include time travel?!?” Don’t write a game with a deadline if you don’t yet know exactly where it’s going to end. That is how you get in the death spiral of scope-creep.

At this point I switched to a choice engine (AXMA) and was ambivalent about getting a game done in six months before the competition. I decided to try and get something done and chose a game I only half-heartedly thought I could complete and might not be received well.

This resulted in Cannery Vale which was done -bam- in like two months, and despite being a tremendously huge and intricate game content-wise, it behaved politely with few major problems since choice-narratives afford the author a greater amount of control over what it’s possible for the player to do. Of course I can’t write a simple branching narrative–oh no–there are systems and tons of variables and optional content. The story elements in CV were cobbled together from about four different ideas I had been thinking about for years, so it literally is a Frankenstein’s Monster type project that all managed to work out with 90% less difficulty and testing necessary.

robotsexpartymurder is another enormous Frankenstein project that pulled large elements I had already thought about for a long time, but I started that in December and it was basically structurally complete by the summer and I just had to work filling in all the text placeholders I had put in so that I could make sure the game worked first and then spent the rest of the available time frosting the cake.

My current super-secret WIP for this year was basically done last month and I don’t really know what else to do with myself for now.

  • TL;DR - Scope completely before you code and know exactly where you’re going and what you need to accomplish, especially if you’re working under a deadline. It helps to complete several smaller games in your system of choice to help learn how fast you are capable of working before tackling The Epic. A project that is amorphous in concept will never get done.
9 Likes
18

HanonO,

This is exceptional real world advice for aspiring authors.

Thank you for sharing!

2 Likes
19

I’m glad my sad random tales of woe are helpful to someone! Parser errors can prove amazingly difficult to track down and debug. I pushed an update mid-comp to Baker of Shireton that was a minor ease-of-play adjustment, but which caused the endgame to totally fail and I didn’t catch it until Doug Egan privately messaged me because he was in process of reviewing that game for the second time. That error took all day to suss out - the tiny mid-game thing I changed and didn’t give a second thought to affected a rulebook which rendered the finale completely unwinnable.

2 Likes
20

That’s what I did also. Not that I ever actually finished a parser game, but even my demos required quite a bit more effort than writing a CYOA game. But then I had the brilliant idea of writing my own engine which completely negated any time saved in switching to a CYOA. :sweat_smile: Ten months later and no games released; just a couple demos.

I will say that hypertext fiction games can still be surprisingly complex. You don’t have to compensate for people writing strange commands into the parser, but you do still have to ensure events happen in the correct order, or that phrasing is changed or dialogue is added to reflect past events. I have a habit of adding flavor text to the characters based on transpiring events to make it feel like they know what’s going on in the world around them, which really makes the work balloon quickly (but is worth it).

2 Likes