This post mortem has two parts!


I actually wrote the first part ~6 months after the release of the game, but the opportunity to publish it never really came up. So here it is!

And a second part, to talk about the French translation and what's next, which at that point weren't really part of the picture.

I hope you enjoy reading them!



================================================================================

On November 20th 2020, I released "Tristam Island", my retro text adventure made in the mold of Infocom's, on 36 different platforms. It was my first foray in commercial text adventures and in the retro scene, and I had to learn a bunch of things rather quickly; in the end, it sold fairly well for such a niche title, and players seem very happy with the game, so I'm going to declare this a success. What went well, and what went wrong? Time for the traditional post-mortem!


*** The beginnings ***

It all started with Stefan Vogt. Stefan is a retro enthusiast with a huge collection of systems and a love for text adventures; you may know him as the author of the award-winning Hibernated 1, or the graphical adventure "The Curse of Rabenstein", or as the man who worked with Tim Gilberts to recover and digitize all sorts of Quill and DAAD-related things, included the English version of DAAD. Stefan has a pretty large following, and makes quality text adventures; I naturally came across him at some point (early 2020) on Twitter.

Then, Stefan mentioned he was going to attempt to develop a brand new text adventure for retro systems using Inform 6. My ears perked up: I'm very well-versed in Inform 6, which has been my tool of choice for the last 13 years (and 17 I6 games); I wrote some extensions for it, I ported the Vorple libraries to I6, I worked on the French translation of the I6 library: it's my wheelhouse. And it's been a bit lonely: a lot of anglophones switched to Inform 7 and its natural language syntax, and very few people seemed interested in Inform 6 in the community anymore, to the point where I was the only one doing it in French for close to 10 years. So, naturally, I was interested in this project, and I messaged Stefan. And he was delighted! I think he was secretely hoping that more people would join him in making Infocom-style text adventures; as he says, any new retro text adventure feels like Christmas to him, except you don't get that feeling when it's your own game!

Stefan was very nice, and offered to share the tools and interpreters he was setting up so I could get a head start with them, in exchange of my own tools and scripts. He initially had a plan to use his own version of mInform, a minimal Inform library, that he pared down further to create MetroCenter'84; but we ended up switching to PunyInform, an I6 library written from scratch to maximise speed and minimize size, by Johan Berntsson and Fredrik Ramsberg, who were very happy to get two more users for their library. At the time we started this, too, we needed an I6 compiler; the 6.15 version from circa 2000 was the last one which could output z3 files (the format of choice for Infocom 8-bit releases), but Stefan and Fredrik prodded Zarf, who quickly patched the issues that had prevented z3 compilation from succeeding all these years, and voilà, we had a modern z3 compiler. By June 2020, it all looked pretty good.

We also needed to figure out the various interpreters, and how we were going to port the game to that many machines. The bulk of the work was done by Stefan, who spent a lot of time searching for the best interpreters for each platform (including sniffing around in old databases), hacking them to display the correct names, and finding the right tools to be able to build automatically our versions. That took a lot of time, and even if he probably thought it was fun, it involved a lot of fighting with a lot of different machines. I helped whenever I could, most notably with finding and testing the interpreters and conversion scripts for the Oric, the TRS CoCo, and the TI-99/4A, but also for the GameBoy Color, GameBoy Advance, Nintendo DS, Dreamcast and TI-84+CE versions. I don't think these were on Stefan's list originally, but they're among my favorite retro platforms, and you wouldn't expect them to play text adventures, so I figured if anything, it would be fun for marketing purposes.


*** The game ***

Right, so let's talk about the game itself, shall we? "Tristam Island"'s pitch is simple: you are on a deserted island, and there is a mysterious white house. This is great if you want to attract fans of retro text adventures: the white house is an obvious nod to Zork, and the deserted island setting is a very classical one too. However, from the get-go, I had my vision: this wouldn't be a fangame, it wouldn't have all those Infocom jokes and funny spell names; it would be my own story, just with familiar elements and nods to the past, and a structure and a length similar to Infocom games. I then studied the Infocom games, and the wealth of data and reviews there is out there on them, in order to give myself some guidelines: evoke a good sense of place; have a polised experience with lots of testing; the writing can be funny and have fun responses but can have a touch of darkness too; not too wordy; there are 70 to 80 locations and 35 to 55 takeable objects, and the walkthrough is usually 200 moves.

You'll note that in the end the walkthrough for "Tristam Island" is more like 400 moves. This doesn't, however, mean that the game is twice as long as an Infocom game; in fact, I'd argue it's the same length, or maybe even shorter. The main reason, in my opinion, is that Infocom's games took time because they had hard puzzles (and sometimes unwinnable states that would force you to restart); but "Tristam Island" doesn't have hard puzzles, just a long storyline and quite a few things to work on at the same time. There is a reason for this: I am not very good at solving hard puzzles (and thus, not very good at making them), and I do not have the patience to think a puzzle over for days until finding the solution. In fact, I'd argue that nobody really has that kind of patience anymore, and game design has moved on from some of the puzzles found in 1980s adventures. "Fairness to the player" (no "oh, come on!" solutions) and "not wasting his/her time unnecessarily" (no "I have to restart because I locked myself out of victory on the first move???") are two very important concepts in adventure game design that made the genre grow and the games better, as some argue that's how LucasArts took the crown from Sierra in the 90s. This is a principle that is very important, and I believe Stefan agrees with me on this: our customers want a smooth retro experience, one that is fun in all the right ways, but also acknowledges they aren't pre-teens with only one game to play anymore. Who would be unpleasant or cruel to a player in this day and age, where players own dozens of great games on Steam they haven't even started yet, and can find any game from the 20th century online in a matter of minutes? Anyway, for me, it's even more basic than that: I don't want to make a game that I wouldn't like playing myself; and as a result, the puzzles are on the easy side, are all all fair, have multiple solutions, and you cannot get stuck or die.

As for the idea of the game, I had a basic and interesting pitch for years in my "pitches" folder:
    A castaway on a deserted island. Survive, explore, maybe meet Hermann Toothrot. Then you climb at the top of the island, and see a concrete bunker. It's hard to get there, and it's closed. You sleep there. At night, soldiers come out of the compound. You sneak in, and you investigate; you make it explode as you flee the island in a helicopter.
It was interesting, but it didn't really feel Infocom-ish. I kept working on it some more, and it became something like this:
    A castaway on a deserted island, you have to solve a lot of real-life problems to survive and make shelter, etc. You find a secret government lab working on bad technology; using your primitive tools and techniques, you break the lab. Basic low-tech from nature overtakes fancy lab and destroys evil
This is a bit closer to what eventually became "Tristam Island"; I kept the survival aspect, and the secret government project, but not the destruction of technology. It's when I determined what exactly could that secret government project be that everything clicked (directly inspired by the fact that the game was set on an island - and I know my islands pretty well), and it became really easy to assemble the setting. I also wanted to make it realistic, because the twist I was setting up relied on a specific time in history, and dove into research; I'm not sure people will notice, but it did feel good to include period-appropriate songs, books, textbooks, and even posters. The downside to this approach, and to the twist I chose, is that it is a bit pedestrian and lacking in high stakes; as one reviewer put it, it lacks pizzazz, in that "Infocom games tended to be over-the-top, with wild circuses or exciting spy thrillers or time travel. This game is completely grounded in reality, and in fact seems to have entailed a great deal of research.". It is a quieter game about exploring and taking your time to progress; I'm not sure it's a bad thing, but I'm not sure I want to make it a habit either, and I think my next game will be more exciting!

As for how I wrote the game, this is an area where I had almost no trouble, thanks to my years of experience writing parser games. Over the years, I have developed a method that works really well for me, allowing me to make progress quickly and get a good idea of the scope of the game; the guidelines I had decided in order to get a game that was of a scope and structure similar to Infocom's really helped, too. Basically, I mapped the whole game first, switching between maps of the different areas of the game and a puzzle dependency chart, a really fundamental technique to write an adventure game (especially if you want to provide the player with several independent puzzles to work on at the same time, which is good practice but can hit a snag if you don't realize parts of one puzzle depends on the resolution of another one). I spent a lot of time on this, making sure that the game was basically all there (and it was - very little is changed in the final version compared to these maps that I made in July). Once this was done, I had a solid base for coding, and a perfect representation to start writing. I always write the game first, then worry about implementation; and, to be honest, I got lucky there.


*** The technique ***

One aspect that I will not discuss here too much is how you program an Inform 6 game. This is something that is documented in numerous places on the Internet, starting with the Inform Beginner's Guide all the way to the amazing Inform Designer's Manual 4: the material is all there for you to learn, and quite frankly, Inform 6 is a rather clean language, with (I feel) easy-to-read code directly relating to the game itself. I have been working with it for 13 years, and it was, in a sense, lucky, since I didn't really do this because I wanted to some day make retro games, but just because I liked the language (and disliked Inform 7's huge code sizes and bloat, although it does make it very easy to hook onto a lot of parts of the engine rather cleanly, which is cool).

Instead, I will focus on the parts that were new to me in this project: writing for the Z-Machine version 3, which was necessary to fulfill the promise of playing it on the same systems as Infocom's games. One of the fundamental, and nail-biting, aspects of it is the technical constraints. Some of them are relatively painless if you use PunyInform: for instance, thanks to heavy aliasing of properties, you are under the limit and even have a few available should you want to use them. The most important ones are the limit to the number of objects (255 max) and the file size (128kb); PunyInform does help in that respect, freeing dozens of objects and about 20kb compared to Inform's standard library, but I still had some problems and had to be creative to solve them. This is purely my fault: I could have planned a smaller game, with fewer objects, and never encounter these problems at all; but this is the game I wanted to make. And, let's be honest, that technical challenge was fun; had I been way under the maximum size, I probably would have added more easter eggs, or puzzles, just to push the format to its limit and give the player their money's worth.

After I wrote my maps, complete with the mention of which objects were in which location, I had 254 objects. That was close! The number fluctuated as I was coding, removing some that weren't needed, fusing a few scenery ones together, and adding more because of some detail I forgot or to enhance the atmosphere. My game never went under 245 objects, and I think the final game has 253 objects. In fact, it could be seen as having many more than that (maybe 275 or 280), as I used some techniques to create more objects than the Z-Machine 3 could hold, to make the world and the experience richer. For instance, most of the doors you will see on the island are represented by the same two objects: one for lockable doors, and one for doors that cannot be locked. The description and the status are updated every time you enter the location, in order to give you the illusion they are different objects, but they really aren't. Another example is the scenery objects such as the sea, the sun, the sky, the island, etc. - they're all the same object, that just determines during parsing how it should behave, and adapts the replies and descriptions accordingly. Finally, all the locations in the sea are the same, except the sandbank; my code just keeps track mathematically of which directions are available, and which objects you should see from there. These objects add quite a bit of code - not necessarily complicated, but take up space -, but they are smart solutions to a practical problem; if I hadn't used these, I would have had to cut the whole of Act 4, for instance!

And then, there's the file size; this was a major source of worry, and I wasn't quite sure it would work out until the end, just because of the way I created the game. I decided to just write the game I wanted to make, then worry about file size later, reasoning that because I had scoped my game like Infocom's, it would never be outrageously more than the limit; I could then always cut material or hack at it until I finally got under the file size. My intuition was right, but I definitely had underestimated the amount of creativity and coding skill that would be required of me to get the game under the file size. My biggest mistake was probably not really accounting for the size increase needed to fix all the bugs uncovered by my amazing betatesters. But hey, it all worked out in the end, so will I learn from this experience? Maybe not.

PunyInform takes 23kb of space; my demo, which is act 1, is 55kb. When I finished writing act 2, I was at 104.5kb - dangerously close, but I knew Act 2 was the bulk of the game. I finished writing Act 3 and 4 and got to 126kb - but I was not out of the woods yet, as Acts 2, 3, and 4 required testing. And of course, as expected in this kind of endeavor, there were hundreds of bugs - I had half a dozen testers, and they did an amazing job, from just playing the game to telling me to fix some unclear descriptions or puzzles (Act 3 was even less comprehensible originally...), or just messing with the game. It really is thanks to them that the game plays so smoothly and has relatively few bugs, as they noted everything that wasn't quite right, to bring the game up to a high standard of quality. Quality here meant adding 5 to 15k to my code, and I had to switch to the z5 format (which allows a size up to 256kb) for the rest of the testing, while I figured out how to squeeze more out of the code.

"Tristam Island" uses almost 100 string constants, that are stored once and for all somewhere in memory and printed as needed, instead of writing them explicitly in code. This makes the code slightly less readable, although it can be mitigated by explicit constant names. I used  this technique heavily: any time there were substantial groups of words that were reused in two different messages, I would create a constant holding that group of words, and print that constant. (Sometimes, some groups of words were close enough that I changed the text so they would be exactly the same, to be able to reuse code.) This is a basic technique - Infocom used it too, of course - but it saved between 20 and 200 bytes every time, which is nothing to be sneered at. Another thing that allowed me to make great improvements in the file size is the optimization of abbreviations: abbreviations are basically the same idea as the previous one, except the interpreter handles everything for you and saves you even more space - particularly handy, as it allows you to save space on each "the ", for instance. Inform can use 64 abbreviations, and 32 more at the cost of making your code absolutely unreadable, so I coded a Python script that would translate my source into something unreadable, which was then fed to the compiler. Furthermore, all abbreviation-finding algorithms (Infocom's and Inform's) were sub-optimal: again, I coded my own Python tool, that uncovered much better abbreviations, and tried to get it close to the optimal abbreviations. This meant extra work on tools, but it was worth it: I calculated it saved about 5kb, which is huge.

And then, there's Fredrik Ramsberg - co-author of PunyInform, but also of Ozmoo, the C64 Z-Machine interpreter. Fredrik has a very deep understanding of the Z-Machine at a low-level, and of the code patterns produced by the Inform 6 compiler; he was also very generous with his time, looking at the source code several times and offering advice and improvements to save space. I could write a whole article on his optimizations (and I probably will one day), but they were great advice; just by improving the code patterns I was using, at no cost whatsoever to the game itself, his precious advice gave me an extra 2kb, which (especially near the end of development) was just an amazing help.

I finished writing the game on November 7th. I finished implementing the game on November 10th. I had settled on a release date of November 20th. I had a ton of things to do, such as loader screens, tweets, etc, but the bug reports were coming in hard -- and I had to struggle to keep the file size under control. (I literally spent an evening doing repetitive cleanup on my code to save 300 bytes - and it was a good thing.) Then Samuel Verschelde, a long-time French IFer and a veteran beta-tester, started testing in his usual style - very, very thoroughly, trying anything that could trip the game up, progressing very slowly. He found dozens of bugs the other testers hadn't seen before, which was a blessing and a curse, and he literally spent every evening that week testing the game, with amazing dedication, constantly going back to the same pain spots to try different things. Then he tried to complete the game with full score - and found more bugs. I had to fix everything, and the day of, after fixing a few bugs, I had the game done, with no bytes to spare. And as I was ready to publish, he said: "Do it again. I know you tested the full game yesterday, but since then you fixed a few bugs, so you have to re-test. Do it.". I sighed and did it, because I knew he was right - and sure enough, there was a game-breaking bug in Act 1. I fixed, I tested, and the game was completable with full score. I was absolutely exhausted, but I had done it. I pushed the button.

This wasn't the end of the fixing, though: there were still a few bugs and typos to fix, that players found the first week; and several improvements were found, most notably by Fredrik, who rewrote my light system and saved 400 bytes. This meant that the new bugs, and some of the minor things I decided to not fix because of the lack of space, could be fixed; Release 2 was out a week later, and that's were the game is at right now.


*** The graphics ***

I know, I know, there are no graphics in a text adventure; however, some versions have title screens. This is where I got extremely lucky.

My original plan was to take a photograph, and put it through some kind of filter to simplify it, thus making it easier to adapt to small palettes. I probably would have needed to fiddle with Multipaint, but that was manageable. There weren't that many photographs that matched, though; an island, with chalk cliffs, with nobody on the picture. I found one on Flickr, to which I applied a filter to make it look pixellated, and it ended up being the cover art for the demo.

However, I was having a really hard time converting it into a picture that would look good on a retro computer. The beach was messy, which made it blurry; the cliffs had shadows that appeared too much on the transformed image; the sky was of so many colors between blue and white I would have to manually dither it expertly. It just wasn't working.

I had amazing luck here. I went to the AtariAge forum to talk about my demo there, and ended up stumbling on a user, Stephen Winsor, who was from the same city as me. We chatted via PM and it was fun to connect and learn more about each other; he casually mentioned that his wife was a painter. And actually, she had painted an island recently that looked a bit similar to "Tristam Island"... It actually looked perfect!! I was very excited that Karen Christie let me use the painting as the cover art. It ended up working out very well for the conversion to retro computers format, too; a painting has much more homogenous colors than a photograph, and I got rather good results with 8bitworkshop. I had to tweak a lot of the graphics, of course, going over some details in Multipaint so it would look even better, but overall I'm very pleased with how it all looks.

Oh yeah, and as it turns out, Stephen is a graphic designer, and he offered to create a logo for me! It looks much better than what I could have made myself, very legible and striking, and still simple enough to downgrade gracefully on retro platforms. Stephen's help was also invaluable to figure out export formats and how to apply specific palettes to images; he saved me many headaches!

Then, there's the task of putting them in the games... and Stefan Vogt to the rescue, again! Stefan was able to figure out much of what was needed, and once again found the perfect tools for the job, and shared them with me! He even did it for me when I was tearing my hair out 2 days before the deadline because it wasn't working on Amstrad CPC...

Sorry if this section feels more like "credits to people who helped me" rather than "lessons learned". Maybe the lesson is... surround yourself with talented friends who can help you ?


*** The marketing ***

In this last section, I need to talk about a pretty important point: how I marketed and sold a text adventure in 2020. This is a tall order, and I'm not even sure I got it right; but the sales have been pretty good, considering the niche the game is in.

One question that was important for me was whether I could sell the game - as in, for money. I wanted to sell the game, for two reasons: I knew how much work it was going to take me, and I was unemployed at the time and could use some money. I almost talked myself out of it, because I had heard some bad stories of supposedly people in the retro community who would be very angry and think all games for retro platforms should be free because they are "passion projects". In the end, I am glad that I stuck to my guns, because nobody complained!

That doesn't mean that it would never happen; in fact, I took some measures to prevent such hypothetical attacks. First of all, the price was low - very low, in fact maybe a bit too low, since over half of the people on itch.io gave a tip. I kind of regret pricing it this low, but at the time I had no idea if there was even a market for it; usually, in gamedev circles, you will hear "you should always price your game higher than you think", and, well, maybe I should have? On the other hand, maybe nobody complained about having to pay because it was such a steal... Other measures that I took to make people feel like they were getting a good deal was including digital feelies in the game, including a hint book, and having a free demo. The demo had a lot of downloads overall, which I am pretty happy with; it's also great for dissemination, in places like CSDB for C64 users and Aminet for Amiga users.

But, well, a new game with a free demo isn't worth anything if nobody hears about you. I knew that I had to make myself be known well before the game came out, so I had to do some marketing. I had two plans: going on forums and Facebook groups to tell people about my projects, and posting regularly on Twitter. For the first point, you can only do this when you have a big update - but, to be honest, thank God, because I literally had to post to three dozen communities, writing personalized messages and taking the time to interact with everyone; it took a lot of time and effort, but it was actually pretty successful overall, as there were a lot of enthusiasm. (As a bonus, some people offered their help and expertise on some tricky parts of the process, which definitely helped.)

As for Twitter, I already had a few hundred followers, but they weren't really overlapping with the retro scene all that much. I had some help with Stefan, who has a lot of followers and retweeted me pretty often, but I couldn't just rely on that. I thus made a plan to tweet daily until the demo came out, to talk about the game and my progress making it. That was a very ambitious plan, and to be honest it really took a lot more time than I thought - about 30-45 minutes to have the content in the game ready, go to it with the right emulator, take a screenshot, and schedule the tweet. Repeat that 90 times... Anyway, it's hard to say if that was necessary or not; I did gain quite a few followers, but most of them followed me when I had big tweets, like announcing a new platform or the release of the demo or of the full game. I don't honestly know if posting about the game's content, like fun replies or interesting moments, helped in the same way; some tweets bombed, but others, even if they weren't popular, elicited some genuine interest or cheeky comments from people who were getting really into the game. (Also, maybe tweeting every day helps with Twitter's algorithm? I really have no idea.) I dialed it back after the demo's release, but resumed a month before the game's release. In the end, I'm not 100% sure tweeting every day was worth the work and the hassle; at best, it helped engage an audience that was already receptive, and made them fans (but who knows, really). I think I might have gotten the same result with "tweeting every other day", so I might just do that next time.


*** Final thoughts ***

"Tristam Island" took close to 450 hours of work, which is a lot for a passion project. It hasn't sold very well [175 copies in 6 months, 350 in 3 years] in absolute numbers, thus making my hourly wage [total of $1850 USD, before itch's cut, 3 years later] quite low; however, this is more money than I expected making from a text adventure in 2020, let's be honest! [Plus, as of November 2023 the free demo was downloaded over 3,500 times, which (even if you take into account the multiple platforms) means a few hundred people were interested enough to give it a spin!] I also learned a lot of things, from managing social media to diving in all these retro platforms and their specifics. I am quite proud of the final package, as I feel like the game is very good, and the releases work very well; I am also happy I have a robust toolchain which will help for my next game. Finally, I have made a lot of connections in various communities, and seeing people talking about the game, being very interested in it, and offering their help, was an amazing experience. The retro community is definitely very welcoming and warm, and I am happy so many people know about my game.

What's next? I am currently working on the French translation of the game, which also involves more fiddling for the accented characters to display properly; but there are quite a few French people excited to play it. The physical version will be handled by Poly.Play, who have done such a great job with Stefan Vogt and Davide Bucci's releases; I am excited to have it in my hands one day (and many other players are too, or so they tell me!). And, well, I should probably start thinking about a new game! I have several ideas, but I want to let them mature first, and find a great one that'll make a worthy followup to "Tristam Island". I've also started a job in 2021, so I'm not sure I can finish a new text adventure this year; so maybe see you all in 2022!


================================================================================

Additional sections, written in November 2023:


*** The French translation ***

Because yes, there is one, that came out a year after. It came out on exactly the same platforms, and it was actually tricky to do so! And then in the end it sold 37 copies, and made me a grand total of $170 of revenue. I tried to drum up publicity and talk in French retro forums and Facebook groups, just like I did with Tristam Island, and even got a few retro Youtubers to talk about it, but unfortunately this was much less popular. Was it a failure then? Not entirely, and let me say why. However, one thing is for certain: I am not going to translate future retro games into French. By my count it took me about 160 hours, and doing that to reach essentially nobody was very disappointing.

For the translation, I used a tool that I had built a few years before for that purpose, which extracted strings from the source code into a separate file that I could just work on separately, and get them back in. (We then translated Andrew Plotkin's Shade in French with it.) It did require some adaptation of the code, for specific phrasings and adding variations of verbs; and in the end, this means that PunyInform got translated to French.

But translating wasn't even half of the battle! French is a more expansive language than English, so after the initial translation, the 127.5k file had turned a bit larger - which wouldn't fit in the z3 format! Even with abbreviations, it just wouldn't fit. However hope wasn't lost: by some conjunction of factors, there was some hubhub around abbreviations. I don't dare to say that this was my doing, as I think others were looking into it for ZIL/Infocom projects, but nobody cared about abbreviations for 15 years and all of a sudden, when I start posting about my Python script on intfiction including on a thread about making improvements to Trinity (I think?), something seemed to be in motion. The excitement led to several people creating competing, and ultimately better and more optimized, abbreviation-finding tools, for ZIL and Inform 6, like Matthew Russotto and Henrik Åsman, whose ZAbbrevMaker I ended up using. My contribution to it came when Matthew Russotto found/discussed an algorithm by Wagner from the 1970s that would improve how abbrevations are applied; this ended up being my first contribution to the Inform 6 compiler! See the thread on intfiction. It was a fun time!
https://intfiction.org/t/highly-optimized-abbreviations-computed-efficiently/48753

The other part of the fun was the display of accented characters in 30-40 year old interpreters that had never seen a single game in French. This was a super fun time, getting to understand each of these old computer's character tables and the possibility to modify them to display accents correctly; going from fixing up a 20-year old Atari ST terp to redrawing the font for a Dreamcast interpreter and getting the interpreter's creator to add it to the repository 20 years later, to tricking some computers into displaying accents by leveraging unused characters... The details are mentioned in an article for fiction-interactive.fr (https://www.fiction-interactive.fr/ecrire-un-jeu-z-machine-version-3-en-francais/) although some things are obsolete - for instance, Shawn Sijnstra's Vezza interpreter was born since then, and displays accented characters natively on most platforms, such as the Amstrad CPC (which I unfortunately couldnt get to work before the release).

Maybe one day these details will be important to someone else, maybe not. I'd love for someone/somewhere to adopt this as a project, and to maintain/grow the resources needed to run text adventures in non-English languages on as many retro platforms as can be done, so please do if you're interested! But for now, it was a learning experience and kinda fun to mess around like that :)


*** What's next? ***

The game came out 3 years ago, and since then, I haven't written another parser game. What next indeed?

For a while I was working on another idea for a parser game, "The Caves of Time". The idea came pretty clearly, and to be honest I still think it's a strong concept; plus, it'd be fun to see how I could add NPCs to a z3-sized game. I have a rough map, some puzzle ideas, but this hasn't really gone past that stage.

There's lots of reasons for that. The main one is that, unlike when I wrote "Tristam Island", I have a full-time job; that whole freelance writing thing never really came close to paying the bills unfortunately. As a corollary, when I got a job I also tried to hang on a little bit to that life - having multiple writing projects on the go, chasing client work, having time for my own project, maintaining community duties and writing articles, etc. And the truth is, predictably, I couldn't balance everything in my life and I was close to burnout!

Jacquard Entertainment is now closed, and for a while I dropped basically every project, except my involvement with IFTF. Now, I only have time for one project, so I chose the one I was most excited about: an experimental game that will not run on retro platforms, which will probably come out in 2025. "The Caves of Time" is still a viable game, however I'll be honest: I've lost the momentum I had with "Tristam Island", I've lost part of my audience when Twitter broke down, and the retro text adventure scene is different - still there on the PunyInform Discord, however the ambitious releases with 6 hours of gameplay are few and far between now (Stefan's Hibernated 1 DC, Davide's Silk Dust, and Tristam Island at the same period was really the stars aligning I think!). I'll be honest, I'm not sure another retro text adventure of mine would generate as much interest (and I'm not sure I'd have time to make sure it reaches everyone), and so it's hard for me to see a viable path to "The Caves of Time" being a thing.

But who knows? Maybe there is still interest and a player base out there. Maybe the release of this source code and this postmortem will help; maybe the source code will be interesting and will inspire someone. I'm releasing it as a way to preserve it, to give it a chance to live on in others' code and game ideas. This has been a lot of fun and I'm extremely proud of it; thank you very much for being along for the ride! 

Hugo