 to rush through the first part because the fun part is at the very end. So, this is about how I resurrected an old text adventure game and I'm going to unpack what this means. And the first slide I'm gonna do is the one that everyone hates, which is all about the speaker. Who cared who the speaker is? But in this case, it turns out it's actually important because I was born in 1980, which of course meant that I grew up with 8-bit home computers. I also was born in Hungary and if you used 8-bit home computers in Hungary, that meant Commodore 64 or the ZX Spectrum. In my case, it meant the Commodore 64. Also, if you grew up on 8-bit home computers, that meant that text adventure games were all the rage. So, if anyone here doesn't know what a text adventure game is, it's basically one where you just read text which tells you your surrounding and your situation and then you type in some command of what you want the protagonist to do. So, these were really big on 8-bit home computers. And if you had a Commodore 64 and you were in Hungary and you liked text adventure games, there was one particular game which was the first professional great text adventure game and this was quite a big thing. And everyone who grew up around that time knew about this game. So, I thought I would reverse engineer it because I've never done anything like that. And because the Commodore 64 is a very small machine, I thought I have a good chance of actually doing that because, you know, you can see the whole state of the machine and emulator. So, I'm not going to talk about the reverse engineering part. The point from this is that it turned out that the game logic itself was written in basic and then the engine was in machine code. I didn't care too much about the engine. The game logic was what I was after because I then re-implemented that in a modern text adventure language which is called Inform. I use Inform 5 because version 6 is insane. So, version 5, after you compile it, you get something which runs in a VM, right? And then there are player applications for that VM. So, you could download a player, load my remade version of this old game into it and then you could play something and this could be the end of the story, right? So, you load this in, you play this. It also has a web player which is also, you know, this is something you download. I put it on my website together with the recreated game file. You load it in and it works and you can look at the gorgeous graphics from the original game, right? So, this could be the end of the story and then I got famous because I submit about famous. So, I submitted it to the leading Hungarian retro gaming blog which, as you can imagine, has thousands of readers, right? So, this was my first step towards becoming famous but not the last because everyone wanted an Android version. So, all the comments on, you know, the blog post, on Facebook, on YouTube video which showed the game, all the comments was, I want to play this on Android and this is where the story starts getting interesting and this is the part I want to talk about because so, if you want to run it on any platform, right? You compile this into this virtual machine like I said but the problem with that virtual machine is that there are two versions of that and only one of them supports international characters. Now, the Hungarian language has some special characters, some special accented vowels which are not available in Latin one. So, you would need something which uses this VM format called Glalks but there is no working Glalks interpreter or runner available for Android and there's a good reason for that which is if you just start writing a naive implementation it turns out that the way Android works, right? With Java and then the what's it called Dalvik layer underneath is you're going to be horribly slow. So, if you just write something which, you know, takes the next byte from your VM image, interprets it, puts out the text, reads in the input, et cetera, it's going to be slow. So, what did I do? What are you doing? And this is the money shot of this presentation. So, I promised five languages, right? So, I took the inform five source which is, you know, my recreation of the game, compile that to this Glalks bytecode and then I wrote a compiler in Haskell which emits JVM assembly in a format called Krakatau which is a Python assembler for the JVM. So, that one is JVM bytecode. I also wrote in Kotlin all the GUI scaffolding around it because you need a front-end to be able to play it. And then there's a small runtime system which the generated, sorry, this part, the generated JVM assembly links to because it needs to maintain its own stack and blah, blah, blah for technical reasons. And if you put all this together, you get the Android app. And this is what it looks like. It actually looks nicer than the real Glalks players because, you know, I was able to play with transparency and whatnot with an overlay effect on the graphics and it doesn't look so horrible and pixel-y. And this got me famed again because I submitted it to the same blog and then they ran a story on it. And then the Android app got almost 5,000 downloads which is, I think, the total addressable market for a early 80s Hungarian text adventure game. So I have cornered that market and that's it. Thank you. We have five minutes for Q&A, so go. On a scale of 10 to 10 the easiest, how easy is it for you to write the graphical interface in Kotlin? So the graphical interface was, for me personally, that was the most tedious part. I don't do GUIs normally. It's not really something I'm interested in. And basically the way this project happened is that I got everything working up to this point because this was the interesting bit, right? Especially because the Glalks VM format, it's really not suited for compilation. It's supposed to be interpreted. And then it took a long time to do this just because it was hard to get myself to put in the effort. But technically it wasn't hard. So I would say that the hardest was making an Android interface which does text, right? Because this is like serial text, so you print something and then you read back something, you print something, you read back something, like really old, or like a Unix text program. And there's no good way of, at least, I couldn't find a good way of doing that in Android. So this is like built up of small text boxes and input boxes and everything. And it was just, you used to get it right. But yeah, so I would say that technically the Kotlin part was not so challenging. But for me, because of the impedance mismatch between what I usually do and this kind of stuff. Was it important to find out the original game, how it was made? Yeah, so I completely skipped that part because it just didn't fit into the five minutes, right? So this was the most fun part of it because I just loaded up the original game in a C64 emulator and I just started looking at memory addresses, adding breakpoints, looking at disassembled code, et cetera. So this was like a huge, like an, I don't know, like an n-dimensional Rubik cube game. So how long did you actually find the original game that couldn't find mine? Oh, well, I mean, so because this game was big back in its days. So this one is very easy to find. It's on every site which has C64, like software database, you're able to download it. So this is a well preserved game. This is not, because like I said, this was the game, if you were all of these, then yeah. I'm curious, what's the game about? Oh, okay, right, yeah. So the game is called like Time Archaeologist. It's about a time traveling archaeologist who sent back in time to get a griffin egg in the middle ages or something. Yeah. Yeah, it's a bit unclear why a griffin egg would be so important. Not really, like it doesn't say that. So for example, if I want to do the same as what you did for this game called the Typing Tutorial, how would I go about finding that game? Do you have any advice? Well, okay, so is that a game from which time period? April 3, I guess. Okay, I'm pretty sure you can find it online because all the, yeah, this software, they don't... I can't remember, I think it might be DOS. Yeah, but you can find huge databases of all DOS and Windows games. They don't really disappear, really. So even something which is much more obscure than this game, you can find it. And the hard part is just reverse engineering it. But like with the Typing Tutorial game, you would probably be better off just playing with it enough to understand how it works and then just re-implementing it from scratch. Here, the problem was that because of nature of the game, there's a lot of rules. Like if you're in this room and you have this sword and you type in that you attack this guy, then this happens. So all of that had to be recovered and rewritten in inform. But now with the new format, this is like preserved for eternity. Well, for the foreseeable future because this whole inform ecosystem is a very mature thing that has existed for decades now. And there are, even to this day, there are like annual competitions on writing text adventure games in this system. So this is not going anywhere. So this is hopefully going to be like the new canonical format of this game. Yeah, we have time for one more question. I'm not sure if you have enough time to answer this question. It's okay, we can continue. Can you give more detail on how the real world engineering is done like from the memory? Uh-huh. So I keep talking like I already about it. But the starting point was I just loaded up the game. So the first trick was that I found the version of the game which was cracked back in the day. So it didn't have any copy protection and it was on a tape instead of a floppy. So you loaded it once and it was all inside memory but it didn't support the pictures. But in that version I could load it in, take a dump of the 64 kilobytes of memory, disassemble that, right? And that gave me 64 kilobytes of undocumented machine code. But it was a start because using that and in the emulator you can add break points. So what I next did is I traced, instead of breaking I first just traced the program counter and then just let the game run like without typing anything. So that gave me all the program counters that the, oops, sorry. That the game would go through if you're not doing anything interesting. Then I started typing but not submitting any command. That gave me a new set of program counters, right? And then with this set I put this aside in a log file. Then I started executing commands like nonsensical ones at first. And then I compared the set of program counters and it gave me the program counter that are only hit when you type in something meaningful. And that gave me an entry point, right? So that pointed me at a single address which is always hit whenever you type something which like grammatically correct. And then from then on I could start reading the machine code and actually figure, because it's not that hard if you know where to start. But this gave me the starting point and then I could start adding break points to find out which particular branches are hit when, and so on. But as it turns out it was mostly unnecessary because the game logic itself turns out it's written in basic which I didn't know when I started. So if instead of doing all this, you load in the game and then you do a soft reset of the virtual machine which doesn't erase the memory but resets the state, right? And then you ask for a program listing. You basically got most of the game logic in readable basic. So we are at time, but if you wanna find out more, there's always time after to take the details. But everybody, thank you very much.