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
I’ve followed this guide before and found it to be a good baseline:
6 Likes
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
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
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
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
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
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
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
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:
- the starting room with the victim’s body
- a piece of evidence hidden in the starting room
- a room with a suspect NPC who is incriminated by the evidence
- 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.”) 
6 Likes
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
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
I’ll add another hint that Ryan Veeder taught me (he wrote in a blog and I read it, not like he personally mentored me…)
- Don’t mention superfluous extra stuff in your descriptions that you’ll then need to implement as it serves to distract the player from what’s important.
Thorough implementation is a noble cause. But thorough implementation can just be assuring the player “Yes, it’s there; you don’t need to mess with it.”
Just because you have a bathroom, and you and the player know what all should be in a bathroom doesn’t mean you need to spend hours implementing everything a bathroom has unless vital to the plot - like there’s a puzzle where a player has to fish a key out of the drain with string and bubble gum. If the player is just walking past it “Ah. Yes. It’s a normal bathroom. Nothing special you need there.”
Better yet don’t include a bathroom or any other unnecessary locations just for completeness or fall victim to scenery clutter. Extra stuff that’s in a game but not relevant creates inadvertent red-herrings for the player to get hung up on. If you don’t include it, it doesn’t exist and it doesn’t distract.
My version of this is “Don’t describe the wallpaper (unless the wallpaper is important.)”
This is less relevant in a choice narrative where the author can choose exactly what the player can do and/or focus on, thus allowing the author more descriptive leeway without the need for implementing stuff.
5 Likes
While i’m also an adherent to the principle of Chechkov’s gun, well… i’m working on it by implementing a game where everything vaguely mentioned has an explicit purpose! Or at least, trying to, i suppose last minute playtesting is going to tell me if i’m being dumb.
I am trying to keep both locations and descriptions to a happy -ish. Elaborate yes, but the actual visuals are going to be limited around interactive items. As an example, and perhaps, a slightly problematic one…
The automatic look action describes the room. Which makes mention of some trees and birds. Examining the trees and birds points to the sky, which in turn points to a spoiler entity which finally gives a cookie point affecting the ending. And this is all assuming the player will want to interact further! I’m going to add some hyperlinks to the actions directly, but i’m now somewhat unsure whether or not that is a sensible approach.
The only author-induced hand of god i have so far is a forced interaction, and a single “wait, you haven’t done this super obvious thing” directly related to the interaction. I don’t quite want to limit the player into a forced state beyond vaguely pointing them at a direction.
Again, not sure if that’s a good thing! As it stands i do have planned endgame states that assume the player has done virtually nothing except blindly stumble across the map until the end flag is reached. Not much of a game, if played as such, but it’s an option. I really don’t want to limit my endings, i barely have 6 
2 Likes
If you do this, do one of two things (or both). Either include a unique searchable and repeated keyphrase next to each placeholder, something that won’t be used in your game (like Bitcoinisdumb), so you can search your source later to confirm you haven’t left any “describe pretty lady here” bits in your finished game -or- keep a running list somewhere of each time you rough out a section that requires you to double back and finish it later.
Now I have a mental image of Hanon running through a swamp with Veeder perched on his shoulders like Yoda.
4 Likes
Oops 
8 Likes
TODO is the common one I used! And that’s a great suggestion. It’s also good when you go “I need to rewrite this” and you remember to avoid the Chapter One Inward Death Spiral - just put TODO (fix this so it doesn’t suck) there and come back later.
You… 
7 Likes
I use [zork] as my placeholder. It’s only in my game twice, so it’s fine. I don’t think I’ll be able to use it in my second game, sadly.
I would like to advocate for messy games. We all enjoy games that give a feeling of freedom while playing like an open sluice. There are so many great games in that mold that they can be mistaken for law.
In writing studies, my peers and I often used the term “oversanded” to characterize a work that had no objectionable qualities, but perhaps lacked personality as a consequence. The rough parts were gone, but the work was frictionless. It’s nice to get caught in the scenery sometimes or try to learn about a protagonist by reading about their takes on refrigerators or mailboxes.
I think it is good to keep things clean, but it’s also fine (good, even) to leave some burrs and catches. It’s OK.
fist bump
7 Likes
I have multiple (commented) placeholders:
#CONTINUE means “I had to go to bed or do something else at this point, carry on from here next time”
#TODO means “I couldn’t be bothered to flesh out this bit and will come back to it when I have some inspiration or when momentum is less of an issue”
#LEARN means "I don’t know how to do this and will find out before going back to it
#LEARNED means “I learned how to do this and am putting this here so I can remember how much I’ve progressed”
The first two get removed when done, so there’s only ever one #CONTINUE if I’m doing my job correctly. There can be and often are several #TODO tags.
8 Likes