I have an idea for a text adventure game creation system and would like to know your thoughts on it.
It would be cross platform and be able to produce source code in several programming languages. Something like a text only ALAN/Haxe hybrid.
The main program would initially run on Windows and Raspberry Pi (as they are the only platforms I currently own), but would be able to produce source code to compile on many more platforms.
I would like it to be able to create Pascal, Nim and Web Assembly code with the option to add more languages later. I’m particularly interested in supporting 8-bit retro tape-based machines (BBC B, MSX, Spectrum etc.) and possibly other text adventure creation systems.
This isn’t a completely new idea, as Inform 7 converts code to Inform 6 source then to Z-machine code and Haxe can transpile to several other high level languages.
I would like the native language to be interpreted if possible, so that games can be tested more easily during the creation process. This would likely be a domain specific language written from scratch, with an emphasis on being screen reader friendly.
The system should be usable with almost any text editor, even if I include a specialised IDE.
Installing additional software should be optional, so that the creator can be tested without needing to install anything else (such as a compiler). Including command line tools that can run from anywhere would be okay though.
A basic framework would be included with the language to help authors get started.
Does anyone have any insight on whether this is a completely crazy idea and if not, what the best way would be to implement it?
I think this is a cool idea, but the only use I see for it beyond just using an interpreter is easily releasing your games for a storefront like steam. If you’re going to target old systems, why not just use frotz or something?
I’m not trying to shoot your idea down; it’s just that it sounds like a lot of work and if the application of the engine doesn’t solve some sort of existing problem, then I’m afraid it’ll be work for nothing.
But hey, you do you. Seriously. God knows I’ve created enough projects that didn’t really go anywhere because I was entirely focused on the “I wonder if I could” instead of “I wonder if I should.”
I would be targetting tape-based systems, whereas most of the existing tools are aimed at disk-based systems. Also, I would like to support less popular computers that never had a z-machine (or even a level 9 a-machine) created for them.
Oh. Well, I mean, I guess. You’ll have to forgive me but I never understood the whole “getting zork to run on an abacus” thing. Like how many people run tape based PCs? Like 9? It seems like a lot of work to support it.
This is a very interesting concept. A modern text IF compiler supported into the future would be welcome. However, it covers territory covered by Inform 6 / Punyinform, Zilf and Dialog. (All three work on Windows and Raspi OS.)
In the UK at least, disk drives were rare for 8-bit machines in the early days. It wasn’t until Amstrad started selling machines with drives built in at a reasonable price that they became more common.
Most of the retro machines I’ve seen on Ebay UK are tape-based.
Yeah, that’s what I meant. I didn’t mean to make it sound like I thought frotz was a compiler. I used to use winfrotz all the time before switching to gargoyle, which itself uses frotz as the interpreter under the hood for zcode.
I just meant that it’s probably easier to backport frotz (and other console applications) to older systems than it is to transpile inform 6 or 7 to super old machine code.
And all of that is before we even discuss the fact that the only games that will be supported on those tape drive computers will be the ones compiled by this compiler. The entire benefit of using an interpreter is that every time you port it to a new system, you suddenly get access all of inform’s library; past, present, and future.
How about transpiling into C, then using existing C compilers to generate code for the target platforms.
Why this can work is, the output “C” could be low-level C. nothing fancy, no high level structures or even complex loops. What you’d be doing here is making use of the code generator back-ends without having to write your own, ie register allocation etc, as well as using any existing runtime libs. Often these machines already have hand-coded c-libs, which you save you the effort.
I’m not sure what you’re trying to say. I never mentioned transpiling Inform code to this new system, just that Inform 7 code is transpiled to Inform 6 code, as an example of a system that already does something similar.
I don’t know of any system that will allow you to import games from other systems as standard, although I have heard of a few converters being available.
With the system I described, adding a new transpiler would allow any existing games to be made available on another platform.
Ah. Rereading your original post, that may have been a serious reading comprehension fail. I thought you were saying it was going from your language to inform to a binary, similar to how inform 7 goes to 6 before going to a zcode file. Now I’m not sure how I managed to get that out of the text.
I have designs like that. In my case, I just take what I want from ScottKit and transfer that to Inform 6. That should take care of any 8 bit computer compatibility. I think there’s SK2Dat ScottKit to Inform compiler, so that should make things easy.
I’m planning to reconstruct ScottKit to PAW, adding any desired improvements Adventuron manage to do. That is enough for me. I have no desire to replicate Graham Nelson effort in Inform.
Another option is to write compiler from SK to BASIC, which is what you need to do if you want to support platforms not supported by Inform.
I just wrote a Glulx to C decompiler, so it’s definitely possible to do the same for Z-Machine. The biggest issue is the complexity of the Z-Machine IO system. If you really want to target ancient tape-based systems you might want a simpler UI system. Also the code ends up much longer than the storyfile was originally.
A simpler format like Scott Adam’s would probably be more feasible. A new language/system is unlikely to gain traction, but making new compilers/transpilers for an existing system makes sense to me.
For targeting tape-based systems, I would suggest Ozmoo rather than Frotz. Frotz is lightweight and runs well on very old hardware, but Ozmoo has significant advantages for extremely limited machines.
I think I accidentally derailed the conversation by mentioning frotz. I think the goal is actually to transpile to more common languages like C++ that can then be compiled for a target platform.
This is still confusing me, for overlapping reasons that confused tayruh.
Z-machine already has a good interpreter for tape-based ZX Spectrum, ZXZVM. And we already have at least three good languages that transpile to Z-code (Inform, ZIL, and Dialog).
So, what are you hoping to bring to the table? Are you looking to build a better Z-machine? (If so, in what way would it be better?)
Or are you looking to develop a better language than Inform, ZIL, or Dialog? (Better how?)
It seems as if there is some confusion about what I am proposing, possibly because I mentioned Inform as an example of an existing IF authoring system that transpiles (translates) from one programming/authoring language to another.
This system would not have anything to do with Inform or the z-machine, as both require a disk drive.
This system would use a new programming language - let’s call it NewLang - that has its own interpreter for test purposes.
Once a game has been written in NewLang and thoroughly tested, the NewLang code could be converted/translated/transpiled to Pascal, C, BASIC etc. and then potentially to native machine code using a third party compiler.
Depending on how NewLang is created, it’s possible that it could also be transpiled to other text adventure languages.
You’ll have to forgive me but I never understood the whole “getting zork to run on an abacus” thing. Like how many people run tape based PCs? Like 9? It seems like a lot of work to support it.