Implicit actions are definitely one of the tools in a devilish tester’s arsenal. You think you’ve covered all of the cases where a player can interact with the MacGuffin, but have you successfully prevented them from implicitly taking it by typing UNLOCK MYSELF WITH MCGUFFIN?
2 Likes
Typical beginner mistake: not scoping the project thoroughly before programming.
It’s quite common for beginners to get a great vague idea, or an opening with no ending, or an opening and ending with no middle and enthusiastically begin coding a game believing they will figure it out as they go even though they’ve only read the first 7 chapters of Writing With Inform 7. As ideas happen, more complications occur that clash with what’s already been established. Unless you’re participating in a speed-IF with a fixed deadline where the point is to fly by the seat of your pants, or creating a very short game that you can hold in one hand, these projects will rarely be completed.
Scoping the game means you take time to figure all major moving parts beforehand. The author has scoped and can see from beginning to end, and hopefully has set up tent-pole milestones in the creation process. They know exactly what player can do - and more importantly what the player cannot do and what the player might try to do. All the big ideas have occurred and been accounted for with understanding how they affect everything in the game.
You don’t have to pre-write all the prose; that can actually be a fun discovery process especially when you know the exact size and shape of every piece you’re writing with a thorough concept of the full plot/arc and all game systems that can possibly interact. Without a clear goal, you will brainstorm things that inspire other things while writing that will explode via combinatorial explosion and waste a lot of your time: “I’ve added a bathroom and decided FLUSH is a synonym for PUSH - now I have to go through 30 rooms to make sure doorbells and every other pushable item can’t also be FLUSHED…” You’ll create variables and then duplicate variables and end up with a hundred of them that could have been simplified to 20 if you’d planned ahead. The game either takes Herculean effort to complete, or more likely causes so much frustration it won’t get done.
That said, it’s not a problem to privately experiment. Creating smaller private prototypes to see how and if things can work during scoping is a good practice.
Big ideas should happen during scoping and are implemented if they work, or rejected if they don’t. That’s not to say you can’t have a flash of inspiration and discover things during the coding and writing - those are good especially if the author understands the full game and the impact on existing systems. What you want to avoid is writing the first third of a game with 30 rooms mostly completed and then go “hey, what if the player can time travel” - that type of big idea during production throws monkey wrenches into all game systems and you’ll end up basically starting over if you don’t get frustrated. it’s akin to framing a house and then after the walls are up deciding the ceilings should be 12’ high instead of 10’ high. This is a decision for the planning phase and having to raze and re-build or somehow go back and add 2’ to every wall stud (shoddily with tape and nails?) wastes time, effort, and resources.
I have crashed and burned doing this before. Alternately a game that I’ve thought about for a year and knew forward and back how long it was supposed to be and everything that could happen became the easiest and fastest Inform 7 code I’ve ever done in a few weeks. That’s also the one I decided on a whim to add time travel to last minute and broke the code, requiring a a marathon 48-hour extensive renovation to make a very scaled-back version work correctly rather than my original foolish “All I need to do is change the clock!” impulse in a timed game with scheduled events. Lesson fully learned!
A corollary to this: everyone has a Magnum Opus game; their own Counterfeit Monkey if you will. Save that idea and don’t attempt it as your first released game. Complete and publish several small games first so you can practice the process from beginning to end a couple of times. You’ll learn a lot about your capabilities and work process that will help you scope the Magnum Opus and know how much actual time it will take you to complete each phase of the game (or even clue you in that it’s not even possible or worth the time required.)
TL;DR: Nobody in charge of Lord of the Rings was making their first movie.
13 Likes
yes i agree, but it’s bad design to leave the author on their own. There’s a lot of talk about “storylets” in game design, but this approach is not applied to system design. Basically, the system should be a set of high and low-level building blocks that can be re-arranged as required whenever you opt out (ie “instead”) of the normal flow. That’s basically my claim here.
I wrote this awhile ago: One tester’s game polish tips for parser authors. And this: One tester’s tips, cont’d.
8 Likes
- Releasing the game compiled in debug mode
- Not creating and including a new IFID for the game
- Putting an object both in a room description and as a normal object to be printed, e.g. “You’re in the master bedroom. A beautiful ring lies on the bed. There’s a ring here.”
- Not making sure that all objects have the proper article, e.g. “You can see a anvil here.”
- Not having others test the game enough.
- Ignoring testers’ feedback.
11 Likes
Ridiculous carry-alls:
>I
You are carrying a pickaxe, a bowlingball, a birdcage (in which is a magpie), a potted plant, and a matchbox (in which is a single match) .
>PUT ALL IN MATCHBOX
Done.
Alternatively, loopholes to create a ridiculous carry-all:
>PUT ALL IN MATCHBOX
The matchbox can’t contain that.
>GET MATCH
You take the match out of the matchbox.
>PUT ALL IN BIRDCAGE
Done. (granted, which is kind of ridiculous already)
>PUT BIRDCAGE IN MATCHBOX
Done.
I get giddy/evil when testing containers.
13 Likes
This belongs to a category of things I’m struggling with as a new author. On the one hand, obviously you’re right. That shouldn’t be possible.
On the other hand, catering to that sort of detail in the world model seems like it would have no effect on gameplay (unless there’s an item carrying limit somewhere in the world) while it takes time/effort away from telling the main story and making good puzzles. And it only affects the experience of people who are giddy/evil – and maybe they have only themselves to blame?
What am I missing?
3 Likes
I tend to agree. Putting large things in a matchbox would definitely cross a line, but generally I don’t want to manage inventory limits when playing an adventure – too much realism can sometimes makes things less fun.
1 Like
This is a silly argument. Just tell the wonderful main story you have in your imagination, fill it with the most incredible puzzles you can cook up, and then do the work to fill the gaps your world.
6 Likes
What is the name of the game? I’d be very interested to hear what you did in terms of preproduction that year. But that would certainly deserve its own thread.
4 Likes
That was Fair (IFDB), I believe: Hanon has mentioned it a couple times, in addition to his postmortem…
6 Likes
Hello,
Although I am still inexperienced, I tend to concur that in current days, that argument is not as big as it may have been in the 80s. The question is, how much work is it to stop silly containers, and I would expect that you can easily set it up for most modern languages. And if you have lots of takeable objects in your game and worry about all the similar if-statements (or whatever your chosen language uses), just add a size variable to all takeables and containers (if you really want to go detailed, give the containers an extra capacity variable) and do plausability checks either in the verb or in the container class of your game. That sounds like a reasonable amount of extra work, just like individualizing failure messages for various actions.
At least that is my feeling about that.
Still, I really appreciate all the interesting and thoughtful answers you have provided. I have already learned about a few things I need to look out for (hello Debug mode! ), although I admit that I will probably stray in some points (my current project is only half-scoped - I know the flow of its three routes to success, I know the general gist/type of the main puzzles, but I have not worked out all rooms and puzzle details beforehand. I am pretty sure I won’t be needing any more new/reworked verbs besides those already implemented except for one flavourful variant of an existing verb I want to add for a specific class of item which actually adds no functionality. Given that the game’s puzzles are more on the ‘realistic’ side, they are more of the key - lock type or give item to x type. No darkness and no mazes planned. I am not even sure if there will be portable containers (^_^;; ).
Yours,
Deathworks
2 Likes
I’d agree with that. It’s striking a balance between mimesis and artistic licence. Having an infinite rucksack to put everything in rather than (rather oddly) walking around the world with lots of objects in your hands, and then running into an annoying item limit, is fine. Being able to pick up a truck and the Postmistress and then put them in the rucksack probably isn’t.
3 Likes
Getting the sequence of state changes and state checks in the right order.
A hypothetical example:
You are standing in the rain.
>READ THE NOTE
(removing the note from the satchel first)The note immediately becomes saturated by the rain. You unfold it and discover the ink has run and the note has become completely illegible. Your heart sinks. The message has been lost forever.
The note reads:
My Dearest Darling,
Meet me in front of the station at four o’clock, rain or shine.
Whoops! The test of whether the note was legible was done before the implicit action (removing it from the satchel), which, since it was performed in the rain, rendered the note illegible.
The best frameworks have much of this worked out, and they make it possible to do routine things without knowing the implementation details.
But sometimes you need to understand those details to accomplish something specific to your story. So beginners are at a disadvantage simply because they have less experience with the framework and thus less understanding of how to extend it.
8 Likes
Only checking for direct containment/carrying and forgetting indirect containment.
I had a critical event that triggered when the player entered a location while in possession of a certain item, but used carries instead of encloses (Inform 7). A tester put the item in a carried box, so the event never triggered because the player wasn’t technically carrying the item.
It’s easy to make this mistake in Inform 7 by using X is in Y where Y is a room (room Y directly contains X) instead of location of X is Y (X is somewhere in room Y even if not directly.)
7 Likes
I hope I didn’t give anyone the wrong impression about my stance on limitless inventories or handy carry-all containers. Those make life easier for the intrepid adventurer. They are also intentional on the part of the author, a sort of agreement between creator and player. I’m talking about all the boxes, vases, pots and pans, that the PC encounters in the game world. When those are bottomless, I laugh. I’m also a bit annoyed that the author didn’t do the work and sew up the seams of their world.
7 Likes
Josh is correct. I had the idea for Fair immediately after IFComp ended, couldn’t stop thinking about it for an entire year, then wrote it in a few weeks. It was solid and releasable a few days early, but that’s also the game that broke due to my intrusive idea to include time travel two days before the submission deadline.
Yes, my theory on that based on mistakes and experience is don’t put a hard number limit on the player’s inventory because there will be situations like “I can hold three pencils but not four pencils…” or “I can carry three pieces of paper or two pieces of paper and a television set…” Nobody really likes superfluous inventory management and making stash piles. If you seriously want to make inventory management a gameplay element it needs to be more than just You can only carry five things regardless of size and shape.
That’s why usually the PC’s ability to carry thirty things at once is either never mentioned, or hand-waved by including the “carry-all” which is either magical or demonstrative such as the Jansport backpack in Cragne Manor. Giving containers capacities and items size and shape variables might be realistic, but outside of a survival hiking simulator will invariably cause emergent frustration. Yes, it’s fun in survival horror where you must Tetris-puzzle your inventory graphically, but visually drag and dropping makes more sense and is more understandable than imagining it theoretically and typing things like PUT THREE MAGIC BEANS IN POCKET. Grrr, no… PUT TWO MAGIC BEANS IN POCKET. PUT FOUR MAGIC BEANS AND THE BOWLING BALL IN THE BACKPACK.
Yes, definitely a beginner mistake. Authors should take care to limit specific containers. It makes sense to only allow matches to be inserted in a matchbox and not the glowing blue sword, and disallow a coatrack from being hidden a desk drawer - unless the PC is a magician.
If you must have an inventory puzzle, my preference is it should be curated and not applicable to the entire game, such as needing to drop certain large objects to squeeze through a narrow crevice and figuring out which light source you can fit through with you, or not allowing the player to pick up an armchair without first dropping everything else they are carrying.
I can potentially carry thirty items at once - if they’re all in plastic grocery bags and I hook three bags with each hand… but I can’t then simultaneously unlock my mailbox to check mail! 
Not an easy situation to implement logistically.
8 Likes
outside magic/SF technology (that is, Clarke’s Third Principle) I think that if we have the established convention that the PC has a compass-grade sense of direction, we can also have convention that the PC has an exceptional capacity of optimising space inside containers (I actually have an knack for putting things inside drawers, shelves &c using every cm³ or so…) and this is my personal opinion on the point.
But an interesting puzzle is dealing with moving a televisor (or other heavy/bulky equipment) without having to drop it for opening a door then retaking it (that is, a free-the-path-in-advance puzzle); this require a non-trivial coding, namely blocking manipulation commands when having an heavy/bulk object in the inventory (= hands full, literally !), so let’s talk elsewhere about this OS (off-subject) 
oh, and KICK DOOR isn’t the answer ! 
Best regards from Italy,
dott. Piergiorgio.
3 Likes
Sometimes the reason for having many portable things almost goes without saying. Perhaps the protagonist is an archer, and they must carry their arrows around somehow. Zork’s adventurer has his twenty treasures, and all the various keys required to unlock them. Planetfall might have more red herrings than usable things. It certainly can feel that way. That was a deliberate authorial choice.
But a question worth asking is “am I making a thing-centered game?” or “Is carrying stuff around a core experience that I want to create?” Once we’re casting about for a rationale for hauling things around, we might as well ask if we need all this junk in the first place.
As I’ve already implied, I don’t think games with a lot of things are bad. Some of them are great, in fact, but I think it’s worth stepping back and looking at the whole thing if we’re expending energy trying to make transportation of their contents credible. I’m advocating for intentionality, I suppose.
That’s the narrative big picture question, though from a mechanical point of view there are real, immediate benefits to reducing complexity. I know in my first game I kept adding and adding things. I wanted to experiment and learn. But ultimately managing the carrying capacity of various containers or, in my case, adding tons of nouns that were present only for worldbuilding purposes created a ton of overhead when I was already working very hard.
8 Likes
Hello,
Well, I don’t mind unlimited PC inventory, but putting a horse in your pocket is not my thing outside a surreal or gonzo game.
I was more talking about not keeping some basic consistency only because coding it would be a waste of time.
Anyhow, I actually wanted to describe the approach in my game project currently being built: Small objects are unrestricted. Large, reasonable objects like ladders are limited to one AND they are scenery until the PC has encountered a potential usage (so, you can’t take the ladder until you have seen a tree you want to climb). Games already restrict what you can pick up (all the handy items in scenery). To avoid frustration, I have included a GO TO action, so, once you see the tree, you need just one command to go back to that ladder.
And all that is explained in the ABOUT text.
I feel that is not too frustrating, and it helps preventing things from getting too silly.
Yours,
Deathworks
Edit: Reading Drew’s post which arrived while I was typing on my phone, I may mention that I aim at having very few objects in the game, although some riddles can be solved with a selection of items (or actions).
3 Likes