In February, I released an MSX game that attempted to merge point'n'click adventures with text adventures. This blog is about how and why it failed in that goal; a bit of a postmortem, if you will, with a dash of comparison to games other people have made. This will repeat some of the points I made already in February, but hopefully nowhere near all of them.
This is yet another "me-me-me" blog, so if you're not interested in hearing what I think or why I did something, just stop here.
To summarise, the game is a 32KB ROM in which a penguin has to find money to buy a gift for their friend. It's a very short graphical text adventure without a text parser, as the commands are given by menus: first select object, then a a verb to apply to the said object (like "take" or "talk to") and when necessary, also second object ("use X on Y").
Sample screenshot of Jäästä.
The UI, which was the reason I wanted to make the game in the first place, is counteracting gameplay. The original idea was to have a text adventure where the actionable objects were highlighted and the player could just right-click the word to display the applicable verbs. I wouldn't want to use the MSX mouse, though, so I'd be limited to an UI similar to what Lynx has, and I didn't see that or using a digital joystick to move a cursor about as ideal.
The "solution" to this was to list all hotspots in a list. The verbs applicable to chosen target would remove the need to guess the correct commands to use. This would still eliminate pixel hunting and having to guess which verb to use.
However, I can now see that was actually counteracting gameplay and should've just murdered my darling idea.
Time to hammer in why 1+1=2. Gameplay's about interaction, and that's making decisions and their consequences. Without choices, the game is a book or a movie. With all the choices, you get to fly a space shuttle with all the tricks and no clue what to do without extensive work, and every move might be your last.
It's not only a matter of having just the right amount of options. It's also a matter of having enough hints to guide the player through the right path, be it hitting parry to stun the attacking enemy thanks to a tell the enemy had or using a rake to swipe a keyring from the bottom of a pond. Call this highlighted path Ariadne's thread if you want. When the thread isn't there, the player is lost in the maze.
In the hunt for hotspots, the objects visible on the screen are the guided correct path, and the screen is the 2D space of choices. By listing all hotspots beside the view, I reduced the search space beyond the minimum for fun.
In figuring out the command to solve a puzzle, the verbs in the dictionary are one dimension of the search space. By reducing the applicable actions for an object, I reduced the action space so far that brute-forcing it became viable without the player needing to try to figure out the logical solution.
As my game engine didn't lend itself to limiting which objects to use on which, selecting the "use on" action for an inventory object was actually the most fun part of the game. Deriving a sense of accomplishment for solving a puzzle on the first try out of ten or so different options isn't much, but it is better than nothing.
Legend Entertainment's adventure games were one model for Jäästä. Back when I tried playing them, I was dismayed by the number of listed items present in so many scenes (especially the verbs). Looking at it now, I could consider them not only "flavour text" but also red herrings -- something to enlarge the search space, to make finding the correct path a bit harder. The same applies to the verb list -- there are many many verbs more under the cut line, this time in alphabetical order, and they aren't filtered to only the verbs applicable at the moment. Here's an early scene in Eric the Unready (Legend Entertainment, 1993).
Towards the end of the development, I tried to repeat this by adding more unnecessary objects to the game, objects that were not a part of the game's progression but something, anything superfluous. Rocks on the beach, an iceberg in the distance, a ship in a bottle in the store. So not only did I copy Eric the Unready, but I copied it badly, and then tried to belatedly polish the copy.
Had I planned the game properly, the limited space wouldn't have been this much of an issue.
My original "storyline" for the game was short, far too short. In fact, the only thing somewhat close to a puzzle it had was how to get to the iceberg. Seeing how much space I still had left after having all of the intended content created, I added a second half into the game, using a different palette beside the white/blue/black-dominant one the penguin village uses.
Using a new palette requires a lot more space than reusing the old ones with the compression scheme the game has. This means the extension area and improving the graphics with more details quickly used up most of the previously free space. I also hadn't made much graphics optimization for space by reusing the same tiles when I drew them, which made this worse.
Another problem with the planning wasn't only the lack of content, but excessive empty content. If a location is present in an adventure game, it should have a purpose, especially if the space for content is limited to begin with.
What was the purpose of the penguin village square? To give the player four exits to other locations in the village, and eventually the return spot; this isn't enough. I could've placed Paula here and done away with her home as a location altogether.
What was the point in the seal beach, when the player could've just as easily have been placed on top of the hill, looking down at the seal below?
What was the point of the empty tunnel on the island before the statue? I really cannot see any reason for it to exist. It should've been dropped or made a part of a puzzle, preferably the latter.
What was the point of the cave entrance, beyond explaining how the player is now inside a cave rather than outside on the beach? The location has only two exits and no objects. Again, the cave entrance should've been at least hidden if not at first blocked. Like the tunnel, this was a part of the hastily added expansion to the narrative.
Looking now back to when I played Shadowgate on NES, I hadn't liked how the locations often felt so... unconnected. Now, I'd say the first-person view and the small viewport are part of the problem. In a wide third-person view, it's easier to place more adjacent points of interest in the same location and in the same picture.
Although, let's go to hidden object games to look at Modern Tales: Age of Invention (Orchid Games/Artifex Mundi, 2017) and an early location here. Judging from the camera angles, these are also first-person views.
In this image, I've highlighted all actionable locations where the player has to do something. All of these involve opening a new display for the location (a closeup of a person, a closeup of a device, a hidden object scene, ...), but all of these need to be looked at several times. The area on the right is a hidden object scene, which will be investigated twice. The crates on the bottom left will need be examined at least on three occasions. This is probably excessive, if we compare this to other adventure games.
Here's the second room of the Shadowgate remake (Zojoi, 2014). I haven't played through this version, but here are what I believe to be the most likely important hotspots in the view (beside the exit, which requires a key, at the back of the room). As far as I can tell, the items/hotspots are used/collected only once (plus the torches are not all needed and are simple items to pick up).
As I stated earlier, in Eric the Unready the list of objects is longer than in Jäästä on average, but at least also the first location had to be visited three times (arrival, passing by twice), with only one actual action needing to take place here. In fact, of this first area, only the bottom of the pit latrine is visited just once.
Had Jäästä used the locations it had as much as any of these three sample games did, it could've been a much longer game, but that would've also needed a better narrative. Something I haven't been good for in a decade.
Another big point in why I wanted to create Jäästä was that I wanted to create a reusable game engine and a tool that would automatically convert regular PC files (graphics, text) into binary files to include in the game. While I did write such a tool and such an engine, the engine has several shortcomings that need addressing.
The engine has no room for "custom" puzzles. It does not (yet) allow for changing the visuals "on the fly" through scripting, i.e., each location must look the same throughout the game. Beside that, the names of the tiles used in a location are embedded in the location record rather than as a separate entity that would be found with a pointer. Meaning -- if two locations used the exact same graphics, the tile names would take 14*14*2=392 bytes rather than 14*14+2*2=200 bytes (2 bytes per pointer). This meant the engine is suited to only item-based puzzles that do not require visual feedback. This way, I could've also had the discussion with Pete (another penguin) without using more space for graphics and further reducing the apparent number of actionable locations.
These past months I've played several of Artifex Mundi's hidden object games where certain puzzle types are shared between several titles. While some puzzles are definitely such that I wouldn't try implementing here, the common "this slot needs an object of shape X" observation doesn't work as well as it should with my engine for the lack of ever actually showing the item on screen.
The engine also had only three icons for item classes. This meant that topics, which could've been denoted by speech bubbles, as opposed to directions, objects at the location and objects in inventory, don't stand out among the other items (they're now items at the location). Just another thing I hadn't thought through when specifying the requirements.
Then there's the lack of support for memory mappers. As the game is now, it has only two 16KB pages, and those are constantly in memory. If 128KB of ROM is divided into 8 pages of 16KB, with one holding all the program code in slot 1 and the data swapping in to slot 2 whenever necessary, a reasonable split would be to have four pages for graphics and the remaining three for locations, scripts and text. Unsurprisingly, even the compressed text will take a lot of space, and this is the simplest way to add to the action space.
One more shortcoming is how the objects have a static list of applicable verbs, determined by which verbs have a script associated with them. If you pick up an object and it is moved to the player's inventory, the object will still display the "take" verb in the list. The way I avoided this with Jäästä was moving the object with the take-verb to limbo and moving another otherwise identical object but lacking the script associated with "take" to the player's inventory instead. Clumsy, and probably not something that is easy to fix well.
Shadowgate on the NES had the save option. My engine does not, as I haven't looked at how the C-tape interface would work here.
Passwords could be an option, but they'd be cumbersome. The game state is generally defined as the location of all the items (2 bytes each), 16 one-byte variables and the player location (two bytes). Without ignoring immovable objects and using a 64-character set for passwords, one password in Jäästä would be 110 characters long -- which is ridiculous. With two simple changes (enumerate possible locations and use this number instead of 16-bit address to mark a location, ignore items that never move), I still get 30-character-long passwords, which are too much.
Forcing the game into an episodic format and then giving a short password for each episode would probably be the best option. As it is now, though, the engine doesn't support episodes yet either.
If I had to create music, I'd rather create a procedural generator to produce something somewhat tolerable of ambient sound effects and call it a day. So far, I haven't found it absolutely necessary to worry about the aural side of my games. Of course, this means that I'm never going to be producing physical copies of them.
Qualitywise, Jäästä is akin to a "hello world" program or a tech demo. Small, technically does what it's supposed to, but overall worthless to the general public. The lackluster narrative hammered it home to me that adventure game design has its own rules that I need to learn if want to create another adventure game.
I'm considering updating the engine with the aforementioned fixes and then spending a good amount of time planning a more complex game for the next MSXdev, one that would take the whole 128KB of ROM. But I doubt that game would actually materialize, given how I'm more driven by coding than creating content.