Hi, I have a friend who has spent a few years writing a game in ADRIFT and wants to collaborate with other people on it. He is an amazing writer and designer, but he chose ADRIFT because there is no coding involved. He has a vision for a big, 10-hour game with collectibles and tons of locations. He has already written a lot and I’ve played it and I want to help him succeed. However, there are multiple problems:
The game is getting big enough that it is taking a while to load in ADRIFT.
If we tried to use GitHub (or some other form of version control), we would constantly be running into edit conflicts since there is only one output file.
We NEED version control because I don’t want to break the game irreparably
My friend actually, impressively, worked out a modular system to connect multiple little ADRIFT games into one big one, but basically, I think he should port it to something else so that it is possible to collaborate with other people on writing it. My husband is a professional C++ programmer and made a custom parser-based MUD back in the early 2000s, so he thinks he could port it (but he hasn’t looked at the ADRIFT stuff yet). My questions are:
Has anyone ever ported an ADRIFT game to another parser-based game engine? If so, any idea how they did it?
Adam (my husband) said that basically he would need to write a new exporter file to go to some other format. I’m not a programmer (just a Twine dev hobbiest)… should his target be something like Inform or Ink?
This is the point where you turn to your friend and say, look, it’s okay to like ADRIFT, but that is coding. :) Maybe in a cryptic way; maybe it’s extra work because the system wasn’t designed to be used like that. But thinking about a software problem like that is coding.
I haven’t done more than one line of ADRIFT, but the general theory of porting from one IF language to another is familiar. You just rebuild the game from the ground up, one room and object at a time. You learn how each feature you need works in the new language, and you implement it.
This is not particularly speedy but it works for any language. Bonus: when you’re done, you’ve learned the new language, because you just wrote a game in it.
It is sometimes possible to build an automatic translator that reads one format and generates code in another format. (For example, there’s an old script lying around the archive that turns a Scott Adams game into Inform 5 source code.) However, I don’t recommend going down that route. Because (1) it’s more work, and (2) the generated code is invariably an unreadable mess which is difficult to update further.
I’m not all that familiar with ADRIFT, so I opened a game in the editor to refresh my memory. There is some programming, but it’s minimal. I mainly use Inform 6 and could port it to that language, but I would do it the way @zarf suggested. Given the size of the game, this would be a long tedious process, but it would still be quicker than reverse engineering the ADRIFT file format and writing a converter.
There are some ADRIFT experts on here, so they may have some ideas. Otherwise, you could also check the ADRIFT forum.
If it was me, I would have a go at trying to write something port it (but I would port it to QuestJR!). I have done this for Quest 5 games, and I know it is not perfect, but an imperfect port is a BIG step in the right direction.
The big pain in the neck when porting is translating code, and it sounds like that would not be an issue.
QuestJS will tell you the exact line a bug is on usually, by the way, so that helps the next steps. Also it is all in JavaScript which your husband may already know but is certainly more like C#.
All that said, another possible way is to use find-and-replace in a text editor. Notepad++ has a very sophisticated find-and-replace that allows regular expressions and capture groups, and you could go a long way with that, if you know regular expressions well enough.
I have converted a quite small game from Adrift 5 to Inform 7 to get a feel of Inform 7. I did it exactly as @zarf described: From scratch and manually to learn how to use Inform 7. More specifically, I had both programs open so I could quickly copy/paste location descriptions, object descriptions etc from one program to the other.
Maybe, yes. You have to make sure that your friend actually likes using the target system (Inform 6 or 7 or QuestJS (Not to be confused with Quest 5!), TADS, GrueScript etc) unless you are going to take over the project completely.
There is only one way to figure out: Your friend has to try the system and preferably implement the most tricky puzzle to get an idea of how hard it is to use. For instance, I don’t like Inform 7 very much but so far I like Inform 6 (only used it together with PunyInform which might have memory limitations(?)).
Though I do agree with @zarf to some extend that you can say that using Adrift is a sort coding, we should not underestimate the power of having a tool which gives people an easy start for making something that works. It can sometimes seem hopeless at first to get started on a new scripting language, especially if you haven’t done any coding before.
Having said that, I find that Inform 7 gives the wrong first impression - that it is very easy and that it understands English. When I got to the more tricky bits I found it highly confusing whereas more classical coding is more straight forward once you learn the syntax.
Inform 7 is definitely the most popular tool and has many advantages but as mentioned above, you have to make sure your friend likes using the system. There are many alternatives to Inform if your friend does not like that very much.
I wrote all my early games in ADRIFT and I eventually ported them all to Inform because I wanted people to be able to play them in a browser, which wasn’t an option for ADRIFT games at the time. ADRIFT is a great system for beginners but Inform and TADS are much more versatile and I was able to make a lot of improvements to the games as I ported them. I’m afraid that the process was exactly as Zarf describes, there’s no shortcut.
The advantages of this method for learning a new coding language are often underestimated. You already have the functional outline, and this lets you basically browse the user manuals and references for the parts you need, which makes you comfortable with using the learning resources effectively, which then makes it easier to do new stuff in the language, which then makes you quickly gain mastery of it.
I have learned many coding languages in record time by porting different ideas around.
While it would be possible to write an automatic converter from ADRIFT 5 to something like Inform 6 or TADS 3, doing so would probably take longer than just porting the game by hand, and the resulting game file (like most mechanically generated code) would probably be a fairly unreadable mess.
So, yeah… I, too, would advise against trying to go the automatic conversion route.
I once ported a small Adrift game I’d written to Quest 4 back when I was curious to see how easy / hard it would be to do so (I think I planned to port all my games to multiple systems at some point). It didn’t go well. There were so many differences between the two systems that I think porting it to Quest actually took quite a bit longer than writing it from scratch had done, and when you figure in all the times Quest crashed on me and didn’t save my progress, it definitely took longer. It might have been easier if I’d picked a different system - Quest 4 didn’t have a very good reputation after all - but as a non-programmer the options were pretty slim: Adrift or Quest and I was already using Adrift.
One thing I’m curious about, though: how big is this game anyway? I know Adrift 4 used to suffer significant slowdown when you hit the 200kb stage, but my current wip in Adrift 5, 418kb to date, is still fine.
I was curious to see what Adrift games look like under the hood. I see they are saved as .taf files. Opening up one in a text editor, it has a small XML header, but the rest makes no sense (to a human reader!). Do you need Adrift to read it? And if so, does Adrift have an export facility? This could make porting a game much more difficult…
Porting To Hell in a Hamper from ADRIFT 4 to TADS 2 took me about three months, the same time it took to write the original game from scratch. It was the first time I’d made anything in TADS. Porting the same game from TADS 2 to Inform 7 took me over a year. I was pretty familiar with I7 at the time but the two languages handle things completely differently and I had to rethink everything. The game plays more or less the same but the TADS 2 code is much simpler and more concise. My reason for porting it a second time was the same as the first - changes to browser security meant that the TADS version could no longer be played in a browser. As of now I believe that all three versions can be played in a browser!
Unfortunately, the exported XML file does not contain everything. At least I have tried to export a game and then import it again and the game was not working properly and it was my impression that a few things were missing.
Still, if a converter could implement 95% based on the xml-file, the remaining stuff could be done manually.
As pointed out by @Denk, if you can export to XML, it might be possible to hack up a converter that will scrape out the very very basics, such as the locations and some static objects. This could save a lot of donkey work. But as everyone has also said, the rest will be done manually.
