Announcing the Mythoi Platform

This will be a long post, it will detail some new IF tools I’ve created, but it’s not possible for me to make this short, I tried several times, and have given up, so I apologize for the length, the preamble isn’t meant to frame any sort of magnum opus or anything like that, I just like stories, and I think we all do, because that’s why we’re here.

Hi, my name is bradley. I’m a 53-year-old computer scientist. When I was 12 I discovered, like many others, the magical world of Zork, et al. As a smarty-pantsed youth, fully capable of typing in BASIC programs into my commodore 64 from magazines, I made the decision that I wanted to ‘take the summer to learn how to make adventure games’. My reasoning at the time, was, they have no graphics, how hard can they be. Those of you here familiar with the plumbing and guts created by those rather clever MIT lads who formed Infocom, are probably having a good chuckle at my well-meaning hubris.

I never gave up. Like most code-monkeys I have and had several weird pet passion projects that never saw daylight outside of a debugger or napkin sketch, but I never really let go the ill-conceived promise I made to myself. I am not an IF expert, I’ve never even written a good one, because I cared more for the tooling, how they were/are made.

My day jobs have varied from systems-level programming, compiler front ends, porting, tool-writing for vfx, shrink wrap retail software. I watched the progress of the IF community on usenet, etc, without participating as a member, reading code was at the time, all the conversations about the matter I needed.

The tools I am going to discuss have all been through more design variations and prototypes than I care to admit. I’ve only mentioning them in passing to friends, I’ve never presented any of them to the community, for whatever reason, either because it wasn’t my day job, or because they weren’t really for other people, they were for the idiot 12-year-old kid in me.

I should mention too, as I’m noticing this is a sticking point for a lot of you, they are to be commercial, and I don’t mean greedy corp over-monetized loot-box subscription zomg commercial. I have no investors; it’s just me and a small team. I plan on charging a fair price, enough to support the time we spend on this, and I should also mention here, I have a lot more tools, not IF-related based on what I’ve designed that will help this arguably over-engineered platform make a little more sense once I announce them. Zork wasn’t the only silly promise I made to myself. I may open-source some portions of the platform, though I am not required to do so.

So, let’s talk about what I’ve done here. The first piece I’d like to talk about is the language, Apollo. It is like Felix Croe’s approach with his Pike language and DGD mud driver being inspired by LPC/LPMUD. Apollo is my modern take on LPC. I needed a general-purpose language that I had full control over to achieve the tool and runtime integration I needed without having to play footsy with someone else’s steering committee. I don’t want to saddle this already verbose post with too many technical details, though, as you’d probably guess, I don’t mind going into more detail than most people would consider polite. It will suffice for now to say it is yet another C/C+±like language with features and constructs suiting rule and story development.

The next piece is Prometheus; an IDE tailored specifically for Apollo that can accommodate features like graphical mapping. IF has a lot of strange requirements for debugging and authoring that would have been weird as a plugin or addon for existing IDE’s and frankly I did it this way because none of the IDE’s I created tooling for are even still around. So, you get a nice Qt app that runs on windows, macos, linux, and freebsd. No one really cares about freebsd anymore, but you should because it’s awesome.

Morpheus is our runtime. If plan 9 from outer space and a MUD driver had a baby, it would be Morpheus. I have ported it to several platforms and plan more. Apollo is a prototype-based language, and Morpheus can handle a mix of bytecode and LLVM-based JIT, depending on debugging and runtime needs on a per prototype/object basis.

Which brings me to Z-Machine compatibility. We have it* (asterix added by the programmer part of me, not the marketing part). You can use this platform to create z-machine compat games, but it will cost you, as you can imagine. If you stick to the rules, use allowed types, make allowed calls, etc then yes. I’d rather this not devolve into some sham-wow meme by bullet-pointing everything, I do mention this now because it’s kind of important. It also explodes a lot, because our test-suite is currently insufficient.

Where we are: various pieces are in various stages, we are nearing alpha. As much as I would have loved to announce and drop, I wanted to get feedback, on the tools, on the language, on the direction, as I bring this sputtering biplane in for landing, I still have time for minor course changes. Version 1.0 of a language is important so as to not continuously break backwards compat. To that end I’ll have several opportunities for feedback on the language spec if anyone at all is interested. (cue: crickets). The compiler and vm are the oldest of the pieces and have the most testing.

Oh and I should probably mention Alcibiades, that’s the command-line host for the compiler and vm and runtime. All the pieces exist as classes so they can be buried in their respective tools, so if you have no interest in using an IDE but you still kind of like the idea of Apollo, you can compile and debug and test on the command-line like all sensible people do.

I welcome all feedback, all questions, and yes really, all flames, and while you’ll notice I am not posting this on reddit (for reasons I don’t need to explain), it doesn’t mean you have to be nice. I’m a big boy, and I’ll not bother to post any of my own ‘rules’ for interacting with me. There are parts of this platform that have seen 20 iterations in as many years and have been hammered on by comprehensive test suites, and there are parts that I added a couple years ago that rattle a bit when I shake them. Kind of like me.

If you read this far, thank you. You now know more about this project than anyone other than my team and my psychiatrist.

We look forward to serving the community.
best,
bradley

7 Likes

What kind of game does it make? When it’s not targetting Z-code.

2 Likes

it can be used to make a game that looks/acts like a z-machine game, there’s a text layer that acts like ncurses, a graphics layer for presentation like scummvm-esque games. We have various templates/modules for a beginner approach, but offer full control of the presentation for anyone that wants to fiddle. Planned improvements include bringing it up to say cocos-2d for isometric RPG type games, though that’s still on the drawing board.

3 Likes

When you say you plan for this to be commercial, do you mean just the developer tools, or the runtime needed to play the games as well?

1 Like

only the authoring tools are paid, the runtime will always be free (as in beer), and authors are welcome to sell their efforts, though we will be providing no built-in drm or content protection mechanisms.

1 Like

The obvious question which you’re going to have to answer if you want anyone to engage with your platform: given the huge amount of quality IF which is being produced with free tools, what’s the incentive for someone to purchase your product? Conventional wisdom has it that new platforms need a compelling, high-quality game which showcases the unique features of the platform before anyone will take notice; do you have anything in your catalogue from twenty years of working on these tools that you think will capture the community’s attention?

This probably wasn’t the case twenty years ago when you embarked on this project, but it’s also increasingly difficult for games that aren’t playable on web to gain significant traction; do you have a web version of your runner?

7 Likes

These are all great questions. Yes to web; the runtime has no problem as web assembly, even Prometheus runs fine in a browser, though that’s not currently a supported configuration. To capture an audience? We will be offering contest prizes as it seems that is the current primary community engagement avenue. We will be offering full sets of documentation, tutorials, videos. We are seeking permission to port existing works. Some of these efforts require a certain level of UI functionality we have not yet quite achieved xD. Still, We expect we’ll have to work hard for this, and there are many free tools, but we’re not necessarily here to hock our wares to this crowd, i.e. members of this forum, we have seen potential in selling to the general public, who have almost no connection to the concept of interactive fiction in 2025. Storytelling can be a compelling lure. Easy to use tools, user education, and highly technical offerings to IF vets that want something new to play with. We’ll have a beta program, we’ll welcome any kind of author engagement.

and it wasn’t 20 years ago, it was 40 xD. I started in earnest to put this all together as a product about 7 years ago. We do have a plan, and experience in not only complex software development but marketing as well. This of course does not mean success, but I’ve been a part of companies selling much more boring products for much more money =D.

Happy to answer any additional questions you have. Thanks again for taking the time to respond.

2 Likes

The community does engage in competitions, some offering prizes, but no major IF platform has launched with a contest.

Instead, in each case, the developer crafted the first “admirable” game themself, and demonstrated how great their system is that way, and only then did a competition make sense.

For our commercial IF platform, we first published a few of our own games, made decent money doing so, and then offered publishing contracts, including thousands of dollars in advances. It would surprise me if a contest were a good way to launch a platform.

6 Likes

Thank you for your thoughts,

One of the things we want/wanted to avoid is some kind of live competitive analysis in the form of wow hey look we have a general purpose language and a modern runtime and a priority-aware task-based multithreaded scheduler and a fancy schmancy combinatory categorial grammar parser available for authors. Look how cool we are compared to these old outdated IF tools. So, to this point (and against at least a few of my team members) I’ve been against the idea of a tech demo type full story. We have a metric ton of test cases that demonstrate features. Being that apollo is a GP language with a complete toolchain I’ve been labored under the perhaps misconception that the capabilities should be obvious. So you can kind of see here my MUD background where tech trickles up to the creatives.

early mud drivers usually ‘shipped’ with a skeleton of a library, some docs, and a few prayers, and it was the muds themselves that really made them shine. So, maybe I’m leading too hard on that. I did not want the role I’m now in, I’m more comfortable as a tech director, but every person I approached for the role was immediately trying to turn it into a clown show of monetization that not only would have failed hard, would have been embarrassing the entire time. I’ve watched publishers like Microsoft destroy good games and projects including one I worked on. We all here have a great deal of respect for the art form, for computer science, for the existing tools, and for the community.

The other reason I wanted to open with a contest was to get the tool into the hands of people interested in using it, i.e. hey cash prizes, but a lot of licenses too, and free use of the tools during the contest. But, there’s no reason we can’t do both. The authors I do know, are not IF authors, and we still have a ways before they’d be able to use the tools without a lot of help, the user-facing documentation still has a ways to go. My approach to creative tooling is industry, pixar’s RAT artist tools, and tooling for vfx. My approach is going to be a bit different, but, maybe it could be less different. Also, our overhead and expectations are low, we don’t need to act like a 300 person company with a 20m a month burn rate. We can smolder for a time.

Thanks Dan, you’ve given me some good honest feedback here, and I appreciate it.

2 Likes

Yeah, but that’s a common misconception for programmers making IF tools – in practice having a general-purpose language tends to function as an anti-feature for the creative folks who are a huge chunk of a narrative engine’s potential users. They don’t need the features, and it just makes it appear (and perhaps actually be) that much less approachable than a language where you can type The Gazebo is a room. "A white canvas parasol raised up on stakes driven into the grass." and have a working hello world program.

I don’t think the vast majority of Twine or Inform or Ink or ChoiceScript authors would have the first clue what these words even mean, or would care about them if they did.

And you don’t have to make it a competition to talk about what your unique selling points are. Your audience isn’t people who consume new programming languages like pieces of popcorn, it’s mostly people for whom learning a new tech stack is a significant investment. The more reasons you can give them for making that investment, the better. Why would do the work of learning a whole new system instead of putting that time toward being better at the system they already work in? What can you tell us along the lines of “you know how X is always a headache in Twine? Here’s how it’s easier in our system.” Or show how to do basic common things and how convenient they are and how little you have to learn to get started? How easy is it to install? Can you just use it on the web without installing anything, like you can with Twine (or some of the other systems with Borogove etc.)? Can you run the tools on a mobile device: what’s it like on an iPad or Android tablet with a bluetooth keyboard? Does it have spell-check? How easy is it to share your work and changes with collaborators? Do you have to learn something super intimidating like GitHub, or can you just edit together like Google Docs?

8 Likes

so, I was clearly poking fun at overly technical language and how meaningless (and unproductive) feature comparisons are, so we’re in agreement here and I’m going to leave it at that. Answers to most of those are yes, but your goal here is to engage in exactly the kind of comparison we both agree is ridiculous.

1 Like

I think the point of what Josh was saying was that in the absence of the grounded, positive case for your system, we’re just left with the apophasis of you saying the technical specs aren’t that illuminating. It’s polite not to denigrate the existing systems, sure, but I think some degree of specificity about what weaknesses of theirs Mythoi addresses would be super helpful to the less-technical folks who make up a significant portion of the IF author base (hi, it’s me, I know a lot of vocabulary for Greek rhetoric but basically nothing about what a command-line host is and why I’d want one. It’s named Alcibiades, so I’m guessing it’s going to betray me and sleep with a large percentage of my family members, which tbh is intriguing but kind of a turn-off?)

If it’s helpful, here are some examples the things that I think most folks would agree can be pain points with many contemporary parser-based systems:

  • Easy publication to the web;
  • Automatically scalable graphics and interface elements, especially to mobile;
  • Clean out-of-the-box implementation of menu systems (including choice-based gameplay, either for a full game or for specific gameplay segments);
  • Fast manipulation of unicode characters;
  • Typo correction, autocompletion, and other streamlining of input;
  • Simple creation of a self-contained executable.

Also, you mentioned MUDs a couple of times – every year a lot of people make a run at writing a MUD-style IF game with puzzles but also combat and RPG systems, often in custom systems, but they’re very rarely successful. A platform that builds in a lot of functionality to make that kind of game could probably get noticed!

Lastly, I think the caution on competitions probably makes sense – they tend to be a big deal here since there are communities that organize themselves around many of them, and entering them tends to get attention (often in the form of detailed reviews). The big Comp has the benefit of decades of history, for example, there’s a series of ongoing jams organized by the Neo-Interactives team who’ve got a very active Discord community, and same for the Adventuron community who do an annual Text Adventure Literacy event as well as a few others… But that doesn’t necessarily mean an if-you-build-it-they-will-come approach to throwing a new competition will automatically get engagement, even if there are monetary prizes available (the people still making text games in space-year 2025 are generally not the most economically-minded individuals on the face of the planet). So thinking about some ways to seed the event or build some buzz probably makes sense.

It could be that your primary audience here isn’t the existing mainline IF community, which is of course totally cool – like, it’s awesome that you’ve been talking to folks outside of our scene and getting them interested in making text games! But hopefully this is helpful if getting some engagement from this set of folks is part of the plan.

10 Likes

Thanks Mike,

Let me hit those points. (also, alcibiades wasn’t wrong)

no promises here, though they look like it, I’m soloing today being a sunday and I don’t have anyone to glare at me for making their life harder.

Easy publication to web. The runtime runs as a web assembly, our goal is one button pubishing/preview, The runtime is also embedded in the IDE, so, instant feedback.

Autoscale, the entire runtime autoscales, all layers. if you want pixel perfect you’ll have to make choices, if you don’t care, neither does the runtime. WYSIWYG editor, web, same runtime.

Menu systems, doable with a native module, we have nothing, we can make something. Would love to talk more about this. We made an ncurses-like API for text handling.

we’re all unicode. we pretend to be ascii, instead of the other way around.

for in-editor, the editor in Prometheus is a Qt component based on Scintilla. This gives us some of that out of the box, and gives us a nice API for any additional features. Can do. Right now it has code completion. For the runtime? We can, tab-completion, autocorrect are all ‘known problems’ with available solutions, wasn’t on the list, it can be without a great deal of work.

publishing. one button. not joking.

regarding the mud IF comments, I don’t imagine an overly complex system would really aid anyone or anything by itself. I will say though, the mud elements present in the platform are available for any willing to try, but, they are for a later product. Part of apollo, part of morpheus, not an IF selling point, if that makes sense. I don’t want to neuter anything/split the runtime. If the rule engineering/testing/simulation system gets it, IF gets it.

I appreciate your feedback and candor regarding contests. You deserved a better response but I’ve been dealing with ‘feedback’ all day (not just here), and I’m a bit burnt.

thanks again,
bradley

3 Likes

A “tech demo” is not what the full story is for!

I have a standard piece of advice that I share with developers of new IF authoring systems.

Most people choose an IF platform by playing a great game and saying, “I really like this game, and I would like to make another game just like it. How did the author(s) make it?”

So, when IF platforms successfully take off, they require an admirable story (not just a technology demo) to attract new authors. Historically, the first “admirable” story for each now-successful IF platform was typically either written by the platform authors themselves, or directly funded by them. (Twine’s first admirable story by Anna Anthropy is the only exception I’m aware of.) Admirers don’t seem to directly care about any of the details of the system, except that if it’s too hard for them to learn the system and finish a game, that’s a major factor in achieving true popularity.

I think you’ll either need to write something great or hire a great writer (preferably paid in advance) to launch your platform effectively.

Writing the first good game yourself is also important not just because there are already competitive free IF platforms out there, but because your platform is also in competition with authors who just want to develop their own platform, like you did.

Finally, note that none of the most popular IF systems require authors to use a “real” programming language. Instead, since most IF authors see themselves as writers first and coders second (if at all), all of the most popular systems use a minimal domain-specific language for IF, ideally one that makes it easy to write extensions in another “real” programming language (typically JavaScript).

Why is the IF community so enamored of minimal DSLs? This isn’t like other parts of the game industry. In the game industry in general, even if people do decide to implement their own engine from time to time, the most popular game engines use popular general-purpose programming languages, the same languages everybody else uses. The IF community must be full of weirdos, right?

Well, yes, but we’re not the only weird ones. Consider querying a database. You could do it in C or in JS, and some people do, but the industry has discovered that using a declarative query language is better, and SQL is by far the most popular language for doing it, despite the fact that SQL doesn’t have much in the way of step-wise debugging support. If you’re querying a database, trust me, you should just use SQL. (At a minimum, you should learn SQL before attempting to query a database in another language.)

Text adventures aren’t like other programs that run step by step from beginning to end; they’re programs to cooperatively generate text, incorporating commands from the player while subtly guiding the player how to use the correct commands to win. Coding a parser-based text adventure is mostly about declaring data (what are the rooms and objects in the game) and a rules engine of events that fire when certain conditions occur.

The general industry wisdom when it comes to rules engines is that they all kinda suck. It’s easy to get started rolling your own rules engine, but it’s hard to write a good one, so everybody just rolls their own. And this is another area where DSLs often do thrive. (The article I linked above is by Martin Fowler, who concludes, “there’s a lot to be said for avoiding rules engine products.”)

Then, when you add in the fact that most IF authors see themselves as writers first and coders second (if at all), you start to see why a community has formed around minimal DSLs for text-adventure rule engines, and why good programmers keep writing their own IF-rules engines rather than use anybody else’s.

Until you have a great game in your system, hardly anyone will give it a serious look. Nothing else matters until then.

15 Likes

Hello Bradley, I’m interested in looking at your system. I love IF systems. Do you have a Discord channel to talk? Best of luck.

2 Likes

Well, speaking as someone not familiar with any of the existing IF systems who is most comfortable programming in C++ and who’s ideal would be a C++ library that lets me add parser IF functionality to existing code and the name drop of C/C++ in the opening post, my biggest question is how much work is required to translate code from C++ to Apollo?

1 Like

Hey Jeffery, sorry for the late reply, I’m running into the new user post limit. You asked a quick question, so here’s a quick reply. Our CCG module, it’s possible you could link and call it? I never thought about that use case.. but yeah Apollo/Morpheus have a plugin system as well, you can write native C++ and do a little type dance, there’s headers, keep to the naming contract and during Apollo compile (preprocess) of any prototype that references it, it’ll load, and call during run. As far as syntax I will post the PEG if you want to take a look, you’ll notice two things right off, one, Apollo is prototype-based (we call them archetypes), that clone to objects, and there’s a lot of built-in rules to accommodate certain use cases, there are a smattering of OO features, some nice debugging (we keep meta including the ABT throughout, even after compile, including source annotations). The kind of programming ‘model’ we used is a lot like LPC/LPMUD, but yeah if you want, write C++, follow the rules, implement the registration hook, call it from Apollo, that’s our internal process and well supported.

and if you ever get tired of all this tech heavy stuff we have a front end that’ll parse natural language ala inform style and output Apollo, because you know, turing-complete and computability theory and all that.

1 Like

Uh. How do you figure that? I think that kind of comparison is very important: that’s why I brought it up.

What I was trying to get at was that, as Mike said, most of what you’ve told us so far is tech specs that are largely irrelevant to the use cases and user experience that I care about, and in most cases couched in language so vague that I feel like it probably means 4 different things to any 3 programmers who know what you’re talking about.

In addition to the things Mike pointed out, I think one big thing that Inform 7 does well that a lot of new systems overlook (and that I haven’t seen mentioned yet? maybe I missed it?) is good text substitution: being able to write [a favorite fruit] and have it output as “a banana” or “an apple” or “the Grand High Kumquat of Doom”, or things like generating plurals or person (first/second/third) etc. (and IIRC Inform has extensions to do similar things for a few other languages, maybe Spanish, Portugese, German, French??)

Also you mentioned graphical mapping. Hmm, wait, is that talking about things like Twine’s node graph, or Inform/Trizbort’s room/world maps? Or both? Anyway, Twine’s node graph is a popular convenience, but it also puts text in separate little boxes (which can get tedious in the long run) where something like Ink puts everything in a single piece of text (or multiple files) for easier editing, and I don’t think we’ve seen a tool that combines both smoothly…

5 Likes

Hey Josh,

Thanks for the questions.

We haven’t landed on a text substitution strategy, we wanted to get some feedback on expectations which (thank you) we’re doing now. I don’t see any reason we can’t match inform, our natural language front end is still being worked on, a text-replacement system would be part of that, and I don’t mean to make it sound easy, but all of that happens in one place in the system, and it’s parsing, so it’s in our wheelhouse.

the graphical mapping in the IDE is optional, you can turn it off, if it’s on you can draw (and name) nodes for rooms (we call them scenes) and edges/vertices (i.e. lines) for the exits. The UI keeps track of user changes and adds code to the editor to the correct scene that mirrors the layout, and it’s bidirectional, meaning if you add_exit() in the code editor it gets added to the layout using reasonable assumptions. Gimmicky? Maybe, but for the ‘I’m a writer and I just want to fill in attributes and draw rooms’ user scenario it can be pretty important. For a ‘power user’ it can be turned on or off, it won’t handle say dynamic exit adding, or won’t represent it in the UI, so even basic tricky stuff it won’t even try to mirror, just static exits.

The reason you haven’t seen it done smoothly is because it’s difficult, UI state management isn’t a lot of fun to do, and it needs a lot of testing. The only reason we had a good head start is because of a similar tool I wrote in the age before time began. So, UI draw/mapping, updates in the code, write code, updates in the UI (with reasonable layouts). We also have a tab in the code editor that does the same back and forth with natural language but it needs a lot of work, and might end up just being one-way, because writers get really upset when you format their work or move text around, which is a requirement for that system. i.e. a pure writer uses natural language but needs some code help for something they want, pastes it in the code editor, their natural language updates. You can imagine what that would feel like to a lot of writers.

the syncing sounds like magic, and when it works it looks like it, but anyone that’s familiar with UI work is twitching right now imagining the state management problems and fragility, personally I talk a lot more flippantly about my awesome compiler skills than juggling everything I just described, but we feel it’s important even if it takes like 90% of the UI testing.

To handle something like what ink does, that’s possible too, with the same kind of system, but it’s not on the drawing board right now.

thanks again for feedback,
bradley

1 Like

My question at this point would be, not to put too fine a point on it: what is supposed to interest me about this project? What should make me excited about this new system?

Right now, the main points you’ve listed are:

  • It’s a commercial project
  • It uses a custom C++-esque general-purpose language
  • It uses LLVM, and can compile to the Z-machine
  • It has a custom Qt IDE

The problem is, none of those are things that especially excite me about a project. Learning a new programming language, and especially one that requires me to learn a whole new IDE instead of using the ones I’m comfortable with, is a pretty big investment of time and energy—and since this is a commercial project, there’s also money involved.

So my question is: why should I do that? What are the killer new features that would make me want to use this system instead of Inform or TADS or Dialog or Ink or Twine or ChoiceScript? What are the problems it’s meant to solve?

I’m sure the new system is very cool! But right now, you haven’t really shown us what’s cool about it. There are a lot of languages out there that can compile to the Z-machine, for example, and a lot of IDEs; what’s special about this one?

7 Likes