I’m not arguing against VMs in general. But it’s a valid question to ask whether a VM for IF is a good idea today. It definitely was a good idea 40 years ago. But my contention is that new IF systems do not want a VM.
Absolutely it’s a valid question! And worth exploring. I would actually argue the same applies to the use of artificial intelligence (with LLMs as one subset of that). Not everyone is going to like that, which is fine, but I would much rather see experimentation in it than not. Likewise, I think it’s always good to question patterns that have persisted. That’s why I pointed out VMs that succeeded but also others that failed. It’s not a given that VM means success, but it’s worth recognizing that what “success” means can be contextual and situational.
I would argue that compatibility is a valuable thing regarding IF. Games authored up to 40 years ago are still played and loved. As I remember, Bee, one of the best IF games ever, was unavailable a time because the system it was written in got obsolete.
4 Likes
I’m sorry, but the information contained within this sentence is “Virtual machines have not stood the test of time; it’s just that virtual machines have stood the test of time”.
If people are still using them, then time has tested them, and they passed. That’s literally how it works.
Nevermind, Henrik’s got it. This is what I get for replying before reading the whole thread.
Okay, but withstanding time’s many quizzes and exams doesn’t require competence, yeah? The human body still has an appendix, after all.
Also, sorry, but unless I’ve grievously misunderstood something for years: TypeScript, JavaScript, C# all run on virtual machines. I’m not sure how a technology running on these would count as “not running on a virtual machine”.
EDIT: Sorry if I sound aggressive, but this thread has taken a very confusing turn, and “I fear I’ve lost the plot”, as the kids say these days.
7 Likes
From what I know, Virtual Machines and interpreted languages can run on variety of platforms. So, you don’t need to compile the program for various architectures. There are advantages and disadvantages of this approach.
ADL and AdvSys are examples of VM with bytecode. The compiled code is interpreted by special program. The compiler and interpreter are native C programs.
Nowadays people use interpreted Python, because its code can run everywhere without porting/compiling and offers many libraries.
Every platform has its C/C++ compiler though. Also “make” utility simplifies the porting. Dependancies and link libraries are satisfied during compiling and linking. Sometimes run-time libraries are needed too.
It’s a matter of libraries I think. I read, that the topic system “Sharpee” is based on TypeScript. It’s alright in my opinion. Popular “Adventuron” is based on web languages as well. The deployment is easy, and it’s very important.
JavaScript from what I know is a object-oriented language similar to C++ (in concepts) but it’s running on VM. I don’t have experience with JS, only Java.
If there are available appropriate libraries, any language is OK in my opinion.
2 Likes
Yep, JavaScript typically runs on a VM. Or, rather, JavaScript is usually executed by a JavaScript engine, which can be considered a virtual machine. V8, SpiderMonkey, and JavaScriptCore, for example. While JavaScript engines are VMs in a technical sense (they abstract hardware and provide a runtime), they’re not always labeled as such in the same way as the CLR or JVM. This is because the JavaScript engine is part of browsers or runtimes (like Node.js or Bun) and because the internal bytecode is not always standardized or portable between engines. This is, of course, also why JavaScript’s VM-like engines don’t guarantee the same long-term binary compatibility.
TypeScript does not run on a VM because TypeScript doesn’t really run on anything. It’s a superset of JavaScript that compiles to JavaScript. TypeScript is just a development convenience to have type safety mechanisms over JavaScript, as well as certain language abstractions.
As far as “losing the plot,” I think it’s on point if people agree that talking about the design decisions of Sharpee matters for their engagement with it. If someone is against the idea of working in an IF context (Sharpee) that shuns the idea of virtual machines, it feels worth the creator knowing that as a possible roadblock. It also, however, gives the creator a chance to engage with the community about the possible benefits of breaking from that tradition or at least encouraging people to give the idea a fair hearing.
2 Likes
TypeScript is comparable to Inform, I suppose. Inform compiles to ZVM or Glulxe VM code, but Inform has changed a lot over the years, and source code written for one version of Inform can’t necessarily be compiled by another version.
1 Like
I’m taking this very seriously. One option might be to compile Sharpee stories to Inform’s Inter then to glulx?
This is the reason Inter exists.
[Edited]
After looking deeper at this issue, the best way might be to create a WebAssembly package, but this assumes browsers will work forever. There is way to embed the browser in a package, but chromium is huge. Tauri might be a better solution. It’s an interesting IF-centric problem, though I may punt this and allow someone smarter to implement something. My current goal is to build a platform that can enable me to create my IF stories fast and be able to easily test them.
I think that most IF/Text-adventure authoring systems work this way (ADL, Inform, Alan, TADS etc.), using the Story files. The difference may be in how the core functionalty is built. The goal of each authoring system is to provide Parser and simplify the creation by providing specialized language.
Note that for example in C there are written C compilers that produce low-level mnemonics, other language compilers that produce Story files and so on. Not always next language has an abstract layer introduced, it depends on how core routines are built.
JavaScript has its “just-in-time” interpreters and other mechanisms. I’m interested in the authoring-tools, how they are built, but have no experience with JavaScript.
I just had to quote this part. This is like the most perfect description with nuance of the current state of LLMs. I agree with it totally. I don’t want to derail your thread! But man, Dave, you nailed it.
2 Likes
If you pick a standard interface for your WASM IF (rather than every game having its own ad hoc JavaScript), you could survive the death of the browser by reimplementing the WASM spec and hooking it up to whatever inputs and outputs your interface specifies.
If I were building a new IF system today, I’d use WASM as the VM and build a DSL that compiles to it and a web-based front end that interacts with the WASM code through a standardised API.
2 Likes
There’s an argument to be made that web apps in general leverage the browser as a virtual machine.
4 Likes
And this is exactly my plan and reasons for IF-Octane! 
And I will say nothing further because this is the Sharpee thread!
2 Likes
Please understand the idiom, “stand the test of time”.
The idiom includes the sense of it being good and worthwhile over and above just being still used. That was my point.
Taking detailed discussions to Discord: sharpee
Whatever you use, don’t use electron. As for glulx output, you could always use @dfranke’s WASM2Glulx, though I don’t know how well tested it is, or if there have been any other use cases than the port of colossal cave already uploaded to the archive. Just a suggestion.
1 Like