Game length, wordcount and what to cut. (And other general questions)

Authoring General Design Discussions
1

Alternate title : Help, for i am drowning in condiments and the meat is raw.

Making yet another thread on the idea of word count and game length, mostly since the other ones are fairly old by now.

I’m in the discovery process of inform, as in, the more i write the more power i realise i have, the more i try to implement, then i try to debug, and by the time either success or frustration happen, i get the harrowing moment of lucidity that it’s been hours and i’ve done little to no actual plot progress. I’m sitting at barely 6k words, most of them purely framework. Not participating this year until the product is of the quality that i would be happy with is unfortunately not an option, hence the open ended question(s).

Granted there’s a lot of messing about with the stylesheet and the accompanying images and eventual sounds to the game which also take time, but i digress.

  • What really is the measure of length? Time to winning condition in moves? Total word count of purely the prose?
  • What makes you decide what to sacrifice in the idea of “good enough”, and what are you unable to compromise with? At what point do you realise that, perhaps, having planned for the player to input “blush” or “cook” in a setting with virtually no sense to do so, should have come after the game is up and running?
  • What is sufficient “population” of a room in interactive options? - I suppose this also falls in the wordcount category.

I’m honestly somewhat miffed i ended up having so much genuine fun with the process, as this is still technically “work” which is the conflicting kernel in all of this.

4 Likes
2

For me, it’s how much time the average player will spend experiencing the game. A game that takes only a single carefully-crafted move to win can still take an hour to figure out what that move is!

The core experience for the player is what I’m unwilling to compromise on, and the length of the game may have to be sacrificed for that: better a short but solidly-implemented game than a long but frustratingly-unimplemented one.

Testing is the best way to find out what players will actually do when facing your game, then you can focus on implementing fun responses to those things specifically.

Depends on the room. A hallway that exists only to connect other spaces needs less population than the core puzzle of the game.

This, though, is really the key. If you’re having fun and learning as you go, I’d say that’s more valuable than any guidelines about word count and room size. Certainly my first work was a sprawling mess of interlocking systems!

6 Likes
3

Not sure how to address all of the points, but I can share a thought on this point. Ask yourself, if I removed this bit, would it be apparent from the player’s perspective that something is missing from the complete game? If no, then it isn’t technically mission critical. If yes, ask yourself what is the minimum needed there to not feel strange.

7 Likes
4

Sprawling mess of interlocking systems about covers it. I have so many flags that could be implemented better but without those i’ll end up at step 0 again.:melting_face:

Rematch took me… well over an hour i think, so that’s also a very valid point.

4 Likes
5

See, this is the question i was dreading. From the player perspective, the ability to both ASK about a random subject, while also having a TALK TO command are… almost superfluous. But yes, that… is the core point I’m understanding. A complete game, before adding bells on.

3 Likes
6

Scroll Thief started as “hey, I really liked the Enchanter trilogy, I wonder if I could come up with some puzzles using that magic” → “what would be a not-too-complicated story behind this” → “oh hey X would be cool I wonder how X would interact with all the spells” → “oh hey Y would be cool I wonder how Y would interact with all the spells” and so on. If you start a transcript you’ll be immediately slammed with a huge list of extensions to handle all these things.

I think a lot of us started our first IF projects the same way.

3 Likes
7

I’ll agree with all the good stuff folks have said above. If it’s a helpful benchmark, my two games (in Inform, which from your word count comment it sounds like you’re using too) are 1) a puzzle game that’s probably a little over two hours to play through reasonably thoroughly, which clocked in at about 95k words, and 2) a puzzleless narrative game that takes about an hour, at about 75k words. They’re both implemented pretty thoroughly, but I’m an inefficient coder so probably a competent programmer would reduce those word counts by 20% or more.

In terms of the broader question of how deeply to implement, there’s no single answer of course and especially as you’re learning a new system, if you’re having fun and figuring out new things there’s not much point to stopping yourself. But it is true that pacing-wise, you often want some simpler environments or challenges alternate with the more densely-worked out stuff, and having a custom response and subsystem for everything can both burn you out and lead to player confusion (like the famous fully-working kitchen or bathroom, which is exhausting to build and then probably pointless or misleading for the player).

Beyond using your judgment and getting testers, the other thing to do is to just play other games with a critical eye on how they do that sort of thing - you’d do worse than to spend a week playing some of the top games of the last couple years and just pay attention to what they do, and what works and doesn’t work for your sensibility. It’s more art than science, so training up that area of your brain via examples is a helpful step!

8 Likes
8

Slowly realising that i’m indeed building a fully implemented kitchen while the game is about your house being demolished, yes. I’ll try to just progress the fundamentals for a week or so and by then hopefully have a more sober outlook of what is viable. It doesn’t help, however, that my standards of length are of the like of Blue Lacuna or The Weight of a Soul, but the roughly 70-80k words as @DeusIrae mentioned gives me a proper perspective i think.

4 Likes
9

well, I guess that there’s sadness and melancony in cooking for the very last time in your kitchen… That is to say, if fits the narration, kept your fully implemented kitchen.

Best regards from Italy,
dott. Piergiorgio

6 Likes
10

I’ve followed this guide before and found it to be a good baseline:

6 Likes
11

I love this topic. I feel like I get to have a lot of conversations about discrete things, but this kind of qualitative, philosophical stuff really rings my bell.

Have you said why you are writing a game yet? I personally think you should do what you need to do to satisfy whatever goal you’ve set for yourself. Ah, wait, I’m remembering now. This was a school project of some sort, and you are using Vorple? Am I getting that right?

If you benchmark some high-placing parser games from recent years, you will probably get some good ideas about length, amount of simulation, depth of implementation, play time, and so forth. A lot of authors rely on a kind of synecdoche, letting one or two details represent the entirety of a location. I think there is probably a sweet spot, though maybe not a hard rule.

I think kitchens and bathrooms can be quite interesting, but unless they have some thematic importance you will be spinning your wheels on drains and garbage disposals and dishwashers and whatnots for a long time. I did not know this when I started my game, but there is apparently a meme (not an image with text, but a recurring bit) about what I’ve heard called “my dumb apartment.” Apparently new implementers (like me) tend to start games off in residences and overcook them. But what if that’s where the story starts? I kept my dumb apartment.

If it weren’t for the deadline, which by necessity must push philosophy and aesthetics aside, I would say to learn what interests you, and write what fires your imagination. Or do one or the other. People enjoy all kinds of different relationships with IF.

So, again, I recommend playing winning games from the past couple of years and paying attention to the contents and descriptions of rooms. I think 4-8 hours would be sufficient. Benchmarking will help you defend your design choices (and potentially expand your works consulted if you have one of those), too.

11 Likes
12

My frustration stems from the fact that i ended up enjoying the coursework, yes. The intention was “Development of an interactive fiction game using modern tools” but halfway in the process i realised that i want to do this justice past those vague requirements. Mostly because i found my own comfortable corner of greek mythology and there’s a surplus of intent, inspiration and imagination, but little time and actual implementation.

4-8 hours are my endgame goal, as i doubt i’ll let this project go after whatever i end up delivering for the competition (which is unfortunately part of the requirements of the thesis and hence the sour note). For now though, i might have to make do with a solid hour or so, assuming full interaction.

6 Likes
13

Still, it is great to have something you want to write about! That’s the hardest part for me.

Since judges can only play IF Comp games for two hours, you could probably find out everything you need to know by looking at some top-scoring Inform games from those competitions. Most (all?) will be under two hours. That’s a benchmark stat you can use to justify the play time of your project.

Since a lot of people are releasing source code on April 1, you could easily gather objects/words/locations as statistics to cite/consider (if that isn’t too late for you).

I look forward to your seeing your completed version!

5 Likes
14

Since I think a part of your question is about a process/project management aspect, I’ll give the usual recommendation and link Emily Short’s helpful article where she describes several approaches: Idea to Implementation – Emily Short's Interactive Storytelling

At the time of writing, her method was: “Write the through-line first” (roughly similar to the “Minimum Viable Product” idea):

“[…] create a simple outline design of the game and implement it so that you have something you can play (even if very quickly) from a beginning to the end, and which contains the most critical turning points of the plot. With that skeleton in place, […] complicate the game incrementally, fleshing pieces out […].”

“by the end of the first week or so you have a complete playable game. It is always in some sense ‘finished’”

“At any given phase of development you’ll have something that you could stop, beta-test, polish, and release.”

It’s difficult to give a rule here.

The items which are necessary for your puzzles form the core and make up the minimum number.

In addition to those, maybe just start out with one interactive item per “real” (non-hallway) room. Examples:

  • A kitchen might have a fridge which opens and closes, and which you can put things in. That adds to the immersion and is easy to do. But as Mike said, don’t implement a full kitchen, unless it’s good for your story.

  • A living room might have a TV which you can switch on and off, and change channels on. Provides a good opportunity for atmosphere and worldbuilding.

  • A bathroom might have a sink where you can turn the water on and off.

Doing that, with all its concomitant complications (should you be able to UNPLUG the appliances? Can you put a broom in the fridge? Can you FILL something with water?) and its combinatorial interactions with your puzzle objects, will already be some work.

But it might hit a good spot where the players feel like they inhabit a real world, yet aren’t distracted too much, and where it’s manageable for you. You can always add more if it seems too bare-bones.

Where the exact sweet spot lies depends on your puzzle mechanics, your story, and your writing skills in directing the players’ attention to the important parts.

In addition to those “interactive” items, you’d typically add a few scenery items which just have a description for examining and otherwise a polite message to fob the players off and indicate that they don’t need to interact with them.

7 Likes
15

This is all good advice above, but just wanted to flag that you might want to hold this idea lightly and test it to see how it works for you before committing to it – I did my first game in a ramshackle polish-by-section approach which was admittedly messy but wound up working well. For my second game I tried the through-line method but found it a lot harder to get motivated at the beginning when I was just laying down a bunch of generic placeholders, and then kind of overwhelming to do all the polish work at the end.

This definitely isn’t to say it’s necessarily bad – I think it’s definitely an approach that works for many folks! – but just that it’s not something you should push for if it’s not working for you.

6 Likes
16

Ironically enough i used that exact excerpt in the earlier parts of the thesis requiring documentation and sources. Unfortunately, this is all too theoretical and my actual mileage is incredibly varied. I’m 1k words in since the start of this thread, and unfortunately that is all purely a singular dialogue node, mostly around fluff and setting. (discipline who?)

Hoping that by the end of the week i’ll have a working barebones cart, even if it the wheels are square. One to two items per room sounds like a good consensus, so i’ll double back to that once all the rooms are populated and all the key locations thought through.

4 Likes
17

Amen! I’ve never made a game this way. I would say it’s because the thing that tells me whether I can even make the game, or am going to love making the game, is never present in a skeleton prototype.

Often there’s one scene I have to make in full, and if that works, I become confident the whole thing will work, or will be writable, or is technically possible, or is exciting, or some combination of the above.

It’s not like I don’t throw down some skeleton map locations, but this throughline planning idea for individual rooms or even the whole game, I’ve never used in these modern times. I did it in the 1990s when I had to nail down everything before I moved because each game was essentially a database I was creating in BASIC. Today, I can lurch from one interesting thing to a necessity to the next interesting thing to the next necessity, etc.

-Wade

5 Likes
18

Totally valid perspective, and I think writing out a particular scene to check for atmosphere/excitement or technical feasibility is a great idea!

But regarding this point:

The throughline approach, as I understand it, is not the same as planning it all (nor even most of it) beforehand. Part of its appeal is that it’s flexible, and that you don’t have to make a lot of plans which then might not pan out when something turns out to be too difficult or boring.

For example, if I wrote a murder mystery game, then the following would be a completely valid, albeit not particularly interesting through-line, in my view:

  1. the starting room with the victim’s body
  2. a piece of evidence hidden in the starting room
  3. a room with a suspect NPC who is incriminated by the evidence
  4. game ends in victory when the player arrests the suspect after having found the evidence

This can then be made more interesting and complicated by adding other suspects and pieces of evidence pointing in various directions.

But having said all that, I’m not sure whether I’d follow the approach myself. As we say in German, “Theorie und Praxis sind zwei Paar Schuhe.” (“Theory and practice are two different pairs of shoes.”) :slightly_smiling_face:

6 Likes
19

The term for this is “scope creep”.

The best ways to handle this:

  • Outline the game start to finish before coding so you know where you’re going and what to focus on.
  • Don’t make the first game you write enormous.
  • Write and finish several small projects first. Finishing a project is the best way to learn what you’re capable of and how long it takes you so you can plan the next one better.
  • Prototype outside your game if you have any “everything and the kitchen sink” elements. Then you can clip relevant source text and include, or create an extension.
  • Outline the game start to finish before coding so you know where you’re going and what to focus on.
  • Don’t double back to polish before you’re done with a complete draft (invokes the “Chapter One Inward Death Spiral” where you have a ready to publish chapter one and nothing else.) Polishing is the most fun. Save it for last - otherwise it’s like cleaning your windshield before washing the car.
  • Program the structural skeleton of the game (Wot He Said) so you can run it beginning to end before writing all the detailed descriptions and coding fun extra stuff. Empty rooms or empty placeholder passages: “Diabolical machine goes here” Perhaps a repeat: Don’t paint the house before it’s built.
  • Outline the game start to finish before coding so you know where you’re going and what to focus on.
8 Likes
20

Enormous is the key term here; In actual effort of implementation, it’s proving monumental.

In actual playtime or well, wordcount in parallel, things are looking bleak, hence the downwards spiral leading to the thread. Out of nowhere, i’ve had to do Javascript (typescript even), HTML, CSS, try to understand Inform 7 (still at this bit), realise that virtually everything i want to do has an extension for it, read the extension docs , realise the extension needs some minor rule modifications, go back to the JS bits, realise they can’t work with the active implementation in the inform game… essentially a rather enormous amount of concurrent learning leading to the realisation that regardless of what sacrifices will be made for the timeframe to be reached, it’s still going to be not good enough.

Maybe the fundamental issue is that i feel like my efforts are not going to be represented in the final product. Slowly inching towards acceptance, and that i’ll just turn this into a passion project after the first appearance, but that still leaves a somewhat sour taste in my mouth.

Again, i digress, stuctural cohesion is - or at least should be- the priority, so i’ll make do with what needs to be done.

I just hope the concept of a puzzle has a very loose term because so far, this is just a story where the more you interact, the better it is for your score.

And doing dumb stuff will have repercussions.

Sidenote- I really appreciate the active conversation, did not expect this much genuine help. Thank you all!

3 Likes