A project 35 years in the making

[julie_m]

Some while ago, I got involved in a discussion about text compression, which ended up with me writing some text uncompression code; only that wasn't the end of it, and it seemed a shame not to do something with the code.

So I ended up trying to create a sort of generic text adventure creation system, based around a game engine written in machine code that deals with all the boring stuff such as rooms, exits, objects, inventory and state (and now, with Huffman-based text compression and bit-level packing to minimise the exits table size) which hooks into a BASIC program providing the complex logic for the puzzles in the game. An SQLite database is used on the host to store descriptions of rooms, destinations of exits, descriptions of objects in hand and in room, "stock messages" such as "I don't understand!" and "You are dead!" (that do not refer to anything specific, so could be relevant to any game) and game-specific messages. On the target, the BASIC program makes CALLs to entry points which return to let BASIC interfere with things if needed. Communication between the two layers is done using some of the permanent variables A%-Z%.

I actually started trying to create something like this 35 years ago, on a real Beeb, but never got very far with it .....

Anyway, once I had the basics of the engine together, I cooked up this bit of fun, just as a test. Birthday Adventure: the object of the game is to bake a birthday cake. There are eight rooms, three or four puzzles, three different ways to die and a hefty nod to Peter Killworth. No SAVE and RESTORE yet, but that functionality won't be hard to add when the time comes. Please have a look and tell me what you think ..... Especially if you're interested in trying out the game engine.

birthday_adv.ssd

(15 KiB) Downloaded 118 times

EDIT: That is an out-of-date (though solvable) version, from before final playtest feedback; try this direct link to latest version on GitHub here.

Usual Adventure rules apply. Press RETURN to repeat a description. TAKE on its own takes the first carryable object listed. INV displays your inventory. There are no mazes in this game, so you can always go BACK to the previous room. HELP might be useful if you get stuck. Bad play may result in unwinnable positions.

[iamaran]

It's very fast and responsive.

[julie_m]

That might simply be because there is so little of it (the disc image was built to be able to run in MODE 6, so no reason Electron users should miss out ) ..... Now I have the engine code in a usable state, though, I will be able to put it through its paces with something a bit more complex.

[lurkio]

I've had a quick go. It's very impressive and intriguing.



Yes, I am interested in trying out the game engine!

[julie_m]

I thought (well, hoped .....) someone might be, so I'm currently bashing out some notes to post alongside it on GitHub.

I can already see some potential improvements with the way "examine" messages are stored; I think, due to the "fully-variable length" record structure I am using, it would actually be better to store them directly in the "objects" table rather than as foreign keys into a separate "messages" table.

[FourthStone]

This looks great, I probably won't use it myself but I'm keen to see what a good adventurist can come up with

[julie_m]

OK, the code with some documentation very much in-progress is now at https://github.com/JulieMontoya/Random_Beeb_Stuff/tree/main/birthday_adv -- you will need BeebASM (link to a universal .deb package I created), and you may need to run sudo apt install libdbd-sqlite3-perl (or its equivalent on MacPorts or Windows) if you have not already got the database library bindings installed. But I have successfully test-built the downloaded code.

By the way, if you have solved the game without cheating then you will necessarily have experienced picking up objects in the dark. What do you think of the way this is handled here?

[fuzzel]

I've just downloaded the game and had a quick look around. I must say, it looks rather good and I'm looking forward to playing it in the next few days. I'll post a mini review once I've completed it (positive and possible improvements). Any thoughts about a sequel?

[julie_m]

Oh, yes! I came up with a really fiendish puzzle that was just too much for a quick 8-room demo (although it would have made a good test case for polystate objects ..... Birthday Adventure only uses bi-state objects), so that is going to need working into a suitable scenario, just because it would be such a shame to waste it .....

I also have plans for some minor engine improvements, now I've actually implemented something with it; I'm going to change the way "examine" messages are stored, and add the ability for rooms to have a long description displayed on the first visit and then a short description on subsequent visits. Making these changes would have messed up the schema of the sqlite3 database, so I held off this time.

[iamaran]

By the way, if you have solved the game without cheating then you will necessarily have experienced picking up objects in the dark. What do you think of the way this is handled here?

Well, I certainly don't remember having ever played a game where I had to do it like that, but you do give a hint here and in-game.

[EdwardianDuck]

Darkness seems to be hard to model well. Certainly I found it hard work to implement something even vaguely usable for Duck! Me? either in 6502 or PunyInform. I also allow the player to only go back in absolute darkness, but the player has to type in the appropriate direction instead of a different command (BACK).

Absolute darkness can be unsatisfying (in the sense that the player is in broad daylight in a field, enters a cave and is then in absolute darkness, despite the gaping hole the player just came through which should be letting in light from outside) in many adventure games, but it's a trope that is what it is. I tried to mitigate this by having varying light levels so the light can get dimmer before the player is confronted by absolute darkness. Also (spoiler alert), I have one small object in a dimly lit location which is not revealed until the player has a good light source.

In Birthday Adventure I did notice that you refer to objects in the room description (e.g. oven in the kitchen), which if examined don't seem to exist.

Three ways to die in eight rooms is well into the "Kingdom of Hamil" mortality rate range, not necessarily a bad thing though.

Jeremy

[julie_m]

I had always thought that it was a bit unrealistic to be able to identify by feel an object picked up in darkness, but not to be able to retrace your steps into the light, or dead-reckon your way along a passage you have already seen illuminated. It would actually be very easy to add a "tell by feel" property to each object, and the variable-length bit-packing scheme makes it cheap too (one extra bit per object, in a record that has to be byte-aligned and so probably has room for it anyway). In conjunction with added bit-tables indicating rooms that have been visited and objects that have been handled in daylight, it ought to be possible to implement a model where an object picked up in the dark can be identified by feel alone if and only if it has previously been seen, some objects cannot be identified at all in the dark, and movement in darkness is considered safe if and only if the destination room has previously been visited. (So BACK is automatically safe, since you must have visited the room you came from.)

Three deaths in eight rooms isn't really excessive If you die on the first move, you haven't lost any progress, have you? And for the ones further from room one, well, you can't say you weren't given fair warning of the danger and the option literally to back away! In fact, I made the hen non-lethal in the light on purpose, because by the time a player had got this far -- solving the Philosopher's Quest homage puzzle, locating two of the "treasures" and about to secure the final one -- it seemed unfair to kill them off. What point is there in making a puzzle if nobody solves it? That's why I put the hints in that I did (and will do, when I post a fix for the oven and something else that did not make the game unfinishable). After all, a crafty L. isn't going to tell anyone very much (though those *K. statements at the beginning might slightly reinforce what you're supposed to do).

[iamaran]

If I'm honest, I've never been a fan of the "dark room" - is it really so dark that I can't step backwards to where I came from - I must immediately die!? As EdwardianDuck says, however, a trope is a trope.

[Lardo Boffin]

For my money a dark room should just be a light room but dark - it should not kill you unless there is a legitimate reason to do so, e.g. a large hole or pool full of piranha that you step in to. Or if it is horror themed maybe the vampire gets you or whatever.
In Twin Kingdom Valley you could navigate all of the underground passages in the dark if you knew the route - I used to do this to save oil.
You could legitimately turn a dark area into a maze though (trope squared!) - you might think you are heading east but end up going north etc. Or if the game is realtime / has a turn counter use 2 or 3 turns each move in the dark as you will be going slower.
In my game engine dark rooms are just rooms that don’t give a description. Anything beyond that is down to a room or event specific implementation.
Of course the main problem is fitting all the extra logic into game…

[EdwardianDuck]

Modelling darkness is something I'm still pondering in my own game (and any potential sequels). One might argue that absolute darkness is a very specific concept and use it sparingly, but still have dark rooms in which player actions are somewhat limited. We had a power cut at about 10pm fairly recently, so it was dark. Too dark to read a book or thread a needle, but enough ambient light to wander around slowly (I like the idea that movement in the dark takes more moves) or take/drop normal size objects, so perhaps that's a better model.

I've also been trying to come up with a plausible reason why the player doesn't like the dark, perhaps getting nervous and wanting to leave as soon as possible or partially freezing due to fear. Basically some sort of McGuffin for why the player's actions in the dark are limited.

One could just do away with dark, perhaps it's been done to death, but I have this idea for a puzzle...

Jeremy

[julie_m]

Didn't Twin Kingdom Valley have a weird thing going on with directions, where if you typed an unavailable direction it would take the nearest available exit? For instance if you typed N and there was no exit North but NW was available, it would take you NW. The Scott Adams games also allowed you to move in darkness, but only through valid exits; selecting a "No Exit" in the dark would cause a deadly fall.

The AdveBuilder engine currently just has the ability for rooms to be "light" or "dark"; in the latter case, room descriptions are not displayed and objects picked up are not identified. It's up to the BASIC program to kill off the player (which is as easy as PROCm(msg%):E%=10 to display a message and set the error condition "game over", which will also satisfy the UNTIL condition of the game loop), or not.

I suppose the engine could be extended to support different levels of illumination; say, pitch dark where you can't see anything at all, gloomy where you can just about make out the exits but can't identify objects and moves may take longer in game time, dim where only some objects can be seen without a light source and normal daylight. Possibly even different strengths of light source; a tealight candle in an underground cave might only be bright enough to show you the exits, but a hurricane lantern or a decent flashlight would let you discern objects.

[julie_m]

Here's the link to the latest version of the project, now with docs beginning to appear in the Wiki and everything: https://github.com/JulieMontoya/AdveBuilder

Birthday Adventure is mentioned as an example of what can be done with AdveBuilder. There's a link to a playable SSD right on the front page of the project, so you don't have to encounter any spoilers (except the one that's already on the disc).

[EdwardianDuck]

On reflection, implementing varying light levels may be overkill for an 8-bit game. I continued implementing this in (Puny)Inform at the weekend, but eventually the question of what interactions are possible with an object, depending on the light level and nature of the object. For example, one might be able to see and pick up a book in near darkness, but probably not be able to read it. I guess it just depends on how much realism one wants to model in, at least in my game, a wholly unrealistic scenario.

Making all portable objects an instance of the class which implements this, instead of just the one critical object, added about 3Kb to the game and certainly didn't make it less sluggish in Ozmoo.

Jeremy

[fuzzel]

I played Birthday Adventure from start to finish this afternoon. I liked the setting and it was quite refreshing being able to draw a map quite easily on a sheet of a4 when starting in the middle. The main sticking point for me was finding a light source - at one point I was almost about to give up but then I remembered to... All in all a very good first effort, looking forward to the next one. It has also got me thinking about my next project, maybe a mini-adventure in a suburban setting with teletext graphics (I've got the drawing bug and Telepaint is brilliant).

[julie_m]

Thank you! *curtsey*

I have to say, you aren't the only person who got stuck there; so I'll make a final version with an extra clue or two so nobody gets left in the dark. I've made some improvements to the game engine -- it can now SAVE and RESTORE a position, and RESTART a game from the beginning, so they can go in too.

I'm putting together some ideas for a bigger game; but I probably will do at least one more small one first, as there is an engine feature (polystate objects) that Birthday Adventure did not use (there were several bi-state objects, which use similar logic, but no true poly-state one) so I really ought to give that functionality a workout. Having a few different games based on the same engine will also help with separating out the game-specific portion derived from the SQLite database and the common, "engine" portion. For instance, I need to get the word lists from the database as opposed to hard-coding them in with the engine source. Making a new game using the same engine but with a different vocabulary will force me to do that, and I will know it is ready to take any database.

There is no reason why it should not be possible to add graphics support to AdveBuilder eventually .....

[julie_m]

The latest version of Birthday Adventure is now live here https://github.com/JulieMontoya/AdveBuilder/blob/main/birthday_adv/birthday_adv.ssd and you can even play it in your web browser here!

I'm going to have to hit the "pause" button on AdveBuilder until I can get enough ideas together for another game, even just another little one. Unless someone else has an idea for a text adventure and wants a way to implement it .....

[Beebson]

Giving more realism to the cave adventures is an interesting topic. Darkness is a must thing to have in games with caves. When you enter a cave, it´s a very good idea to have different amount of light in the rooms nearest the hole where the player came in. If the cave or the tunnel near the exit has another cave or tunnel on the left or right, that cave/tunnel room will have even less light, as it´s "door" may be in 90 degree angle compared to the exit. Also, real cave tunnels may not go straightforwardly N, NE, E, SE, S, SW, W, NW, but may bend to the "left" or "right" every now and then. Or suddenly the tunnel might get narrower or wider or go to two (or more) different directions. They may also lead you to downwards or upwards, descending angle being very small or maybe suddenly it becomes very hard to descend or climb. It may be possible to continue without having a rope or a ladder, but movement may be several times slower. Also, the adventurer may get damaged. In a cave it is possible to get hurted even without falling at all, as caves/tunnels are made of solid rock. If you need to climb or wander in a dim light or in the darkness, you can easily hurt your legs and arms, your head, too! If you hit your feet to something you cannot see, you may fall to the ground and possibly hit yourself to the rocks, perhaps fatally. Damage points might be needed, if one wants to add realism.

It might be possible to stay alive in absolute darkness in a cave or tunnel, but it depends where you are. Some cave/tunnel may have a hole. Holes may just be a frightening drop, and after falling you may just find out that you have fell just three or four feets, but the moment was frightening as you thought you will die! In some cases the hole may lead downwards through one or more levels, causing sure death. Though, going "one level" down may not be a enormous step downwards, as the caves/tunnels are not necessarily very high. Ceiling may be just on the same level as you hair, maybe you can´t even walk normally, but have to crawl instead, as the cave/tunnel is not high enough, so if you go/fall downwards through a certain hole, maybe you only fall for about your own height when your feet will hit the bottom of the cave below. It may be possible to pass a hole in the floor, by using an old trick, a tree. Thinking realistically, either you, or somebody elses previously, have needed to pull that tree all the way from the exit of the cave/tunnel. Think first before programming, if it is possible to bring even a part of the tree to the cave/tunnel all the way, through possibly very hard route. But perhaps there have been few other people in the past who have brang the tree there, helping each other back then, so the adventurer just needs to pass the hole by walking on the existing tree. Perhaps you need to walk slowly to not to fall? For more realism, the holes may not be necessarily as wide as the cave/tunnel is, but just part of it, so the adventurer can pass it by walking around the hole thus those caves/tunnels will need to be at least few rooms wide, at least there where the hole is. In reality, it may be needed to use your hands to grab cave/tunnel walls, to keep yourself against the cave/tunnel wall to prevent yourself from falling down, as there may be just VERY narrow "path" between the hole and the wall.

In absolute darkness, it might be possible to stay alive in a cave/tunnel, but you will have to move VERY SLOWLY, much more slowly than just 2-3 times slower. Imagine yourself in a cave/tunnel in absolute darkness, not knowing where to go to get out or if you can ever get out alive, but knowing very well, that there are different kind of holes and steps everywhere. How fast you would like to walk if you can´t see the dangers at all? Perhaps walking VERY slowly, keeping your arms in the air, in a try to feel possible obstacles in advance. In that way, it´s possible to die by falling, as you might not notice the hole or step in time. The much better idea is to continue on "four-wheels", using your arms as another pair of feet and can then feel in time if there is a drop ahead. But you can still hit your head badly. In caves/tunnels there are stalagmites and stalagtites, you can easily hurt yourself in the darkness. Sometimes you may not crawl on "four-wheels" at all, as the ceiling is near the floor, but must lay on the ground and everything will slow down even more. Don´t forget, that caves and tunnels may be slippery, too. The floor may be wet as water drips through the ceiling. The floor of the cave/tunnel may not be made of rock either, but wet, slippery clay. In certain places there is a danger, that wet clay might cause you to slide downwards, through several rooms. Perhaps you will get hit against the rock wall at the bottom room or will helplessly slide to the hole. There could be an option to choose to walk or crawl in different speeds.

To get out, the different amount of light can be a solution once again. If you have wandered long enough to the right direction(s), you might think that perhaps you are seeing VERY DIM light somewhere, but that light is so dim, that you are not sure at all if you really see it or if it is your imagination. But that can be a hint of the right route. The more you hurt yourself, the weaker you will get. The more time you will spend there without food or drink, the weaker you will get all the time. Your endurance/strenght will tell, if you can survive long enough without food and drink, perhaps badly wounded and ill, too. With endurance/strenght I don´t mean available damage points before death, but how strong you are, if you are fit enough to run long time without problems and carry heavy items and do hard work easily, you can stay longer alive than the person who always drives the car when going to work or shopping or spends the life by just watching the movies all day long with pizza and coke.

To add more realism for 32K Beeb adventure games, the disk drive is your friend and emulator is the friend for people with no disk drive. All this is possible to made, but will need lots more thinking.

[EdwardianDuck]

For what it's worth (probably nothing), modelling variable light levels when porting my game to Inform6/PunyInform became the bane of my life. This is largely because Inform6/PunyInform has a predetermined model of how darkness works built in and I ended up fighting it all the way. Twice, as I had two goes at implementing this. I was close to rewriting the puzzles to eliminate darkness completely, but I quite like the idea that my protagonist is scared of the dark for plot/foreshadowing reasons. Obviously it's easier in one's own framework, as I found before I abandoned it in favour of Inform6/PunyInform.

Jeremy

[julie_m]

Oh, yes, indeed ..... Dark is complicated, even before you factor in things like light spilling from one room to another .....

I don't think AdveBuilder imposes too many restrictions on how the programmer handles darkness. It has a simple light/dark status for each room, and allows the status to be manipulated between unpacking a room's database entry and displaying its description. This allows certain objects to act as light sources, and/or or rooms to be illuminated or not depending on game state bits. The behaviour where objects picked up in the dark are only identified when moving into the light can be overridden. Exits are limited to compass directions; but destination rooms are specified separately from each starting point, which allows you (say) to leave a room by walking East and return by going Southwest, or to create one-way passages or trapdoors. (It's even possible to manipulate the destinations between unpacking and displaying the description, allowing for closable doors or bookcases concealing secret passages .....)

And now for the brazen plug: If anybody wants to write a game with a really good darkness model, I'm sure there are worse frameworks they could start with than AdveBuilder It handles all the hard stuff with rooms and objects, accepts a command and looks up the words in its internal dictionary, so you can get on with implementing the unique features of your own game -- the behaviour of verbs other than the built-in movement, TAKE, DROP, EXAMINE, INVENTORY, SAVE and RESTORE commands, and the logic for the puzzles that make up the game.

EDIT: I suppose this is also about the right time to say I've been working on adding something completely different to AdveBuilder; it's basically a simple programming language that compiles to 6502 code (at least, BBC BASIC assembler / BeebAsm source) and supports a nested IF/THEN/ELIF/THEN/ELSE/FI statement and very simple 8-bit integer maths on variables corresponding to game state bytes and other locations used by the game engine. It's just powerful enough to implement most of a game's logic, and you can always deal with the rest in BASIC.

[Beebson]

I wrote some ideas about more realistic caves and tunnels just to possibly inspire someone to make one´s old adventure ideas to come true. With or without "realistic" darkness. I think the changes in light and darkness with more "realistic" caves or rooms are things to think about, to make a different kind, interesting text adventure. Even in total darkness, even you can´t see them, you might be able to find objects, perhaps lots of them in the same room. But they may be unnecessary objects, like rocks. But perhaps they can be used as missiles. Sometimes it might be dangerous to search for objects in darkness, something may collapse, if you try to TAKE it. I don´t mean that the program will always print the usual old you-tried-to-move-in-the-darkness-and-fell, like "You tried to grab something. You can hear something starts to fall and can smell the dust in the air and feel the pain in your body. Something invisible just collapsed on you. You are dead.", but in certain rooms or in certain situations, if you try to TAKE or to MOVE something in the darkness, some existing object, what you can´t see, starts to move and will collapse.

Julie_M, I like your Birthday Adventure. Even I haven´t been able to solve it yet. I have used to the modern times where henhouses and attics will have the switches to turn the light on. I haven´t managed to do that yet. I can´t escape from the attic either, even I know how it should be possible as your game tells how it can be done, but I haven´t been able to find that certain thing what makes it possible. Though, I am not sure, if your game hints about that purposely or by accident.

[julie_m]

Julie_M, I like your Birthday Adventure. Even I haven´t been able to solve it yet. I have used to the modern times where henhouses and attics will have the switches to turn the light on. I haven´t managed to do that yet. I can´t escape from the attic either, even I know how it should be possible as your game tells how it can be done, but I haven´t been able to find that certain thing what makes it possible. Though, I am not sure, if your game hints about that purposely or by accident.

The trick is, TAKE on its own picks up the nearest object, whether or not you can see it!
EDIT: There is built-in HELP and a small clue if you `LIST` the program. This is on purpose because you won't see much with a memory editor, due to the bitwise compression scheme. It's not much, and you might miss it, but I wanted to put something there because `LIST` is something I would definitely try myself, and if I didn't leave at least a tiny hint then people might mistakenly think I disapproved of the technique or worse, was deliberately trying to prevent it. It's just an artefact, honest! -- and in any case, the Source Code available online includes all the uncompressed messages, object and room descriptions. There's also an automatic hint if you remain alive, but trapped behind the acid curtain for more than a certain number of turns. If you've `LIST`ed the program, then suitably-inspired trial-and-error ought to be enough to get you out. You'll be raving mad when you work it out ..... That might be another clue .....
EDIT 2: There's a definite Peter Killworth influence going on here, if that helps!

[Beebson]

Typing just TAKE without the object was too easy to think of..... I had tried to think of different kinds of objects what there could be in the darkness and tried to TAKE them. HELP command didn´t provide enough help in my case. I purposely didn´t want to LIST the program, but to try to solve it by thinking first. But after your suggestion I did LIST the beginning of your program and saw that it´s a BASIC code and I could cheat easily by changing few things. Didn´t do that yet, though. I tried to make things many times in attic rooms and room below the attic entrance, but automatic hint didn´t appear yet.

At first I didn´t want to write here what exactly was the purposely or accidentally put hint how to escape from the attic, as I thought there are people who haven´t tried the game yet, but perhaps I can mention that Birthday Adventure will actually print a message what tells you that after dying, you fall to the sofa from upstairs. That was a clear hint, even it might be just a bug as it sounds like it should have been printed after doing some action what will not kill the adventurer.

[Beebson]

Thank you for the private message, Julie! Unfortunately I am not able to send PMs yet, so I will answer here.

Yes, falling onto the sofa doesn´t kill the adventurer, but Birthday Adventure has killed the adventurer already before falling onto the sofa and so far, I have managed to fall onto sofa only by dying first in the attic. But as I am dead already, I can´t continue playing, it´s Game Over. That´s the problem.

You said it, that´s why I don´t want to LIST and dig the LISTing through, at all, as I don´t want to spoil my playing experience. Thank you for the spoiler too! I will have to play Birthday Adventure again, later. I haven´t heard my future voice yet.

[julie_m]

Yes, falling onto the sofa doesn´t kill the adventurer, but Birthday Adventure has killed the adventurer already before falling onto the sofa and so far, I have managed to fall onto sofa only by dying first in the attic. But as I am dead already, I can´t continue playing, it´s Game Over. That´s the problem.

How did you manage that?! That's not supposed to happen, and I can't reproduce it! Can you remember what you typed?

[Beebson]