I recently started playing with a Z80-based single-board computer, as I noted in a previous submission:

https://news.ycombinator.com/item?id=26843660

Of course I immediately started working through some of the classic text-based adventure games (zork, hitchhiker's guide, etc), and that made me think I should write a game of my own.

This is very basic, with only four locations, and maybe 1/4 of the code is related to easter-eggs. Parenting means that Paw Patrol is a big deal, so there are some good references.

Anyway I had fun writing it.

Thanks Steve, that's a great little project. Thanks for clear comments in the code too!

>This is very basic, with only four locations

I see 5 :)

Five implemented, but four visible to the player!

My one experience programming for a Z80 based SBC was an industrial controller we used as the onboard computer for a high altitude balloon. A mix of C and asm. Wrote the code on a PC connected to the board through the RS-232 port.

Was one of my favorite projects - had to interface with a packet radio and a GPS receiver, along with various sensor attached to the controller's analog ports.

Now back to Java... :(

There are plenty of jobs where you don't have to touch Java.

Java pays too damn well.

> The implementation is mostly concerned with creating the correct series of data-structures, which are essentially arrays of objects. Because if we can make the game table-based we simplify the coding that needs to be done - we don't need to write per-object handlers anywhere, we can just add pointers to tables/structures.

Interesting model, could you share how this worked out for you? Good and bad?

It worked out really well, saving me from writing a lot of fiddly code.

For example imagine you wrote an "EXAMINE" command, and you wanted to allow all objects to be examined. The horrid way to do it would be something like this:

     if target == "desk"
       print( "The desk is ..\n" );
     if target == "book"
       print( "The book is ..\n" );

With a table-based approach you just define your struct (in C) or item-table (in assembly) and your code now looks like this:

       item = find_item_by_name( object );
       print( item.description );

Sure you have to write the lookup function to find the object, but it means you don't have to duplicate the logic for every action (get, drop, examine, use, etc).

Using tables for items, and locations, basically saved me a lot of custom code, cut down on repetition.

The most interesting text adventure I saw years ago (with online connection", was a person who had written a fairly good frame of a text adventure, and was also sitting at the keyboard choosing which macro to hit or typing things in. It took me awhile to catch on, because it was mostly automated.