Introducing KIAVC!

This is an amazing time to be alive, if you’re a fan of point and click adventure games. Ron Gilbert and Dave Grossman shocked us all when they announced they were working on a new Monkey Island game, but as if that wasn’t enough, a sequel to Flight of the Amazon Queen (one of my favourite games of all times) was announced by John Passfield too! Not to forget other nostalgic comebacks, like the upcoming Simon the Sorcerer: Origins prequel and the Colossal Cave 3D Adventure remake, or soon to be published games like Old Skies by fantastic developers like Wadjet Eye.

All these exciting news eventually revived an old dream of mine, that is writing my own engine for an adventure game. I actually tried to start one a couple of decades ago, which ended up nowhere, but this time, taking advantage of the summer break from my job, I decided to focus on that more seriously. Eventually, I got to a point where most of it is there, and even if there’s still a lot of work to do, I decided to share this first shape of my new engine, called KIAVC! And to make this even juicier, the engine is completely open source, and available on GitHub.

This post will provide a brief introduction on the motivation and the choices I ended up making, without going in much detail: in fact, time permitting I plan to then write more detailed blog posts on different aspects of the engine (e.g., structure, rendering, scripting, pathfinding, etc.), in hope that other developers may look at it and point at things I’m doing exceptionally wrong!

Another engine? Why?!

I think I should clarify something right away: I have absolutely no ambitions for this project. I’m not interested in making it profitable, making it grow, or even see it “succeed”. I do have a job, working on things I love that are quite fun too, and I’m not even remotely considering a change in “career” (which is why I’ve waited for my summer break to work on this). The only thing I wanted to do with this project was trying to figure out how to write a point and click adventure game, studying the giants from the past and trying to understand how to replicate the same set of features. As such, it’s been a hugely educational and fun experience for me so far, as I’ve learned a lot in the process (and I’m sure I’ll learn even more going further).

As such, if you’re looking for a professional engine to create your commercial game, by all means this is NOT the one for you (or at the very least, not yet). There’s a ton of excellent options out there, like AGS, Escoria (Godot), Adventure Creator (Unity) and many more. These are all excellent solutions when you just want to start creating your game, which again was NOT my objective: while I may end up creating a game to validate my efforts on KIAVC, sooner or later, what I really wanted to do was check how an engine works, what parts you need, how to make it configurable and flexible enough for different use cases, and so on. If it turns out people like it and start using it, all the better, but that’s not what I’m aiming for (even though I would appreciate contributions and feedback!).

Now that this is out of the way….

What does KIAVC stand for?

As for many projects, I created the name first, and only worried about how to make an acronym out of it later… 😉 Technically speaking, it stands for “KIAVC Is an Adventure Videogame Creator”, but the truth is a bit different!

I’ve mentioned Monkey Island before, and that’s not a coincidence: that was indeed the game that made me discover adventure games, and made me fall in love with the genre, way too many years ago. That game, as many others published by LucasFilm at the time, was written using an engine created by Ron Gilbert called SCUMM (Script Creation Utility for Maniac Mansion), which included a set of tools for different purposes. I always loved “SCUMM” as a name, which as most of the tools they wrote was named after a bodily fluid. Since I wanted to write an engine that tried to work a bit like SCUMM itself, I decided to call it “KIAVC”, which is a Neapolitan word that has pretty much the same meaning :mrgreen: (NB: it’s actually “chiavica”, but in Neapolitan the last “i” and “a” are basically muted!)

Learning from the best!

Before starting, I of course decided to first delve in some studying, starting from videos that would address SCUMM in a bit more detail, like this very interesting post-mortem on Maniac Mansion (that provided interesting insights on some engine choices and/or limitations), this really look deep dive in the Monkey Island code (where some scripting examples where provided too), and this overview of what led to Thimbleweed Park (which again provided interesting bits here and there on some technical aspects). Of course, there’s only so much you can learn for videos apart from a generic overview, so I soon started looking at some other material as well.

This blog post, for instance, was really enlightening and helped me better grasp some fundamental concepts like “rooms”, “actors” and, most importantly, the role of scripting in all this, especially for automated actions. That blog post also contains a link to a complete tutorial on SCUMM itself, in the form of a technical document that I assume was used internally at LucasArts at the time for new hires: that document was also very helpful for understanding some of the mechanisms a tool like SCUMM was based upon, and how people could interact with it or implement the scenarios they wanted to realize.

That said, there’s not just SCUMM out there, and one of the most interesting source of information I could find was the Thimbleweed Park blog. If you’re not familiar with Thimbleweed Park, it’s another amazing point and click adventure game authored by Ron Gilbert and Gary Winnick a few years ago, and partly crowdfunded via Kickstarter: as part of the crowdfunding interactions, a good chunk of the development process was partly documented on the blog, which provided interested developers with a ton of precious information. You could read about Ron and Gary talking about their choices for rendering, or scripting, how they dealt with pathfinding or dialog puzzles, and much more. Of course, there’s only so much they could write in a blog post, but all the information they decided to share was always quite precious to my hungry mind! Most of the choices I made for my engine were blatantly inspired by what Ron and Gary talked about here.

Looking at how other games from the past were written was also quite refreshing and interesting, especially to understand how people not working at LucasArts approached their development instead. I anticipated before how I adore Flight of the Amazon Queen, and I was exctatic when I managed to find a very long and detailed blog post that John Passfield (one of the authors of the original game, and of the upcoming sequel) wrote on the FOTAQ development process. This article is particularly interesting, since John shares what his process was in trying to write a new engine from scratch to try and emulate what SCUMM could do, and it’s often a very interesting read. Just to make a simple example, I loved the insight on how you could use walkboxes as triggers to scale characters (e.g., when you’re going further away in a location), which helped me better understand how you can use different resources for different purposes.

Last but not the least, I also had a look at how other fellow developers handled problems similar to mine, and so I must give a special kudos to Mic Urloon and Jaap who shared a LOT of information on an adventure engine they were imlementing a few years ago in a dedicated blog: not sure if they eventually finished it, because there’s no other post after December of 2015, but they seemed to be at a very good point. In particular, the information they shared on how they approached the challenges of scripting, pathfinding and dialog puzzles was really fantastic, and while I ended up making different choices in some cases, their articles were incredibly educational, detailed and fun to read.

So, how does KIAVC work?

I’m a C developer (it’s what I code in my job every single day) so I decided to use C for my engine as well. I realize many will be frowning now (“Why not C++? Why not Rust? Why not Go? Why not <insert-my-favourite-language-here>?”) but again, this is a pet project, and so you use what you’re already familiar with. For rendering I relied on SDL2 and its companion libraries (SDL_image, SDL_ttf, SDL_mixer), which made sense since: (i) I had already tinkered with SDL a bit, in my first attempts at coding a game ages ago, and (ii) it does make it incredibly easy to get something working on different platforms (I work on Linux but managed to target Windows as well already; who knows, maybe MacOS in the future too!). So far I’ve been very happy with it, and reading the above mentioned Thimbleweed Part blog, it looks like Ron does rely on SDL2 for some aspects too, which means it definitely cannot suck!

I chose a single thread and event based pattern for the engine. While this may come back biting me in the a$$ in the future, it looked like the simplest way to get started, and not worry too much about race conditions, locking or other threading problems (that I’m all too familiar with, since my daily job project is heavily multithreaded). So far it seems to be working nicely, and is quite lightweight too, but of course things may differ once I get the engine working on more CPU intensive activities (e.g., high resolution graphics). This also allowed me to follow what seems to be a common pattern in videogame development, though, that is:

  1. dealing with user input first (e.g., mouse, keyboard);
  2. updating the game “world”, using a specific unit (e.g., ticks)
  3. actually rendering the game using a predefined framerate (independently of ticks).

There’s a single exception to the single thread approach, which is related to audio management: in fact, as anticipated I’m using SDL_mixer to deal with audio streams (whether it’s background music or sound effects). Since I added features like support for fade in/out (e.g., to emulate iMuse, *wink* *wink*!), this means I rely on functions like Mix_ChannelFinished to know when some channels have finished playing: since SDL_mixer uses a separate thread for audio than the main thread in my application, though, this forced me to add some limited locking functionality to the audio related code, so that I’d avoid incurring in ugly race conditions.

For scripting, instead, I decided to use Lua. While in the TP blog Ron explains he chose Squirrel for his new engine, and that he’s not very fond of Lua, I once more chose the “devil I knew”. In fact, a few years ago I had already worked on integrating Lua with C code (for the WebRTC server I authored), and so I already had some familiarity with it. I do like its syntax and how easy it is to write code in it, and also getting it to interact with the C side of things (and viceversa) was easy enough for my needs. This is an example (using well known assets of well known games just for testing purposes, I swear!) of a cutscene I wrote in Lua, for instance:

startCutscene()
fadeIn(1000)
activeActor:walkTo(306, 133)
waitFor(activeActor.id)
waitMs(800)
activeActor:look('right')
waitMs(800)
activeActor:look('left')
waitMs(800)
activeActor:look('right')
waitMs(800)
activeActor:look('down')
activeActor:say('This place looks eerily familiar...')
waitFor(activeActor.id)
stopCutscene()

As you can see, it’s relatively trivial to write a sequence of steps, and functions like waitFor or waitMs ensure that we only proceed at the next step when the engine itself has finished performing what we asked it to do, or after enough time has passed. The same wait/signal kind of approach is also used for dialog puzzles, for instance, where we may need to wait for things to happen in the engine before the script can go on. Thanks to the use of Lua coroutines, we can launch multiple scripts at the same time to do different things without keeping the engine waiting.

Eventually I may have relied a bit too much on Lua, as Lua code is sometimes responsible of things that may actually belong more to the engine itself (more on this in a dedicated post later on), but overall I’m quite happy with how flexible it is, and my first attempts a writing a demo mini-game (which the snippet above is from) have been quite successful in taking advantage of the features I implemented in the engine so far. I even ended up implementing a simple in-game console I can open, from where I can write Lua code to be run: this allowed me to quickly test and prototype functionality in a quick way, without a need to restart the game and reload the scripts. A simple and dumb example is presented below:

What’s in there already?

Without bothering you too much with details (which again may come in future posts), these are the functionality that I have implemented so far (in some cases partially, or as a WIP) as part of the C/Lua integration:

  • support for configurable (via scripting) resolution, scaling and framerate, plus window title and icon;
  • support for fullscreen and dynamically rendered scanlines (to be improved, though);
  • support for mouse (left/right click) and keyboard interactions (script is notified, in order to perform the required action);
  • support for registering static images and animations (even though animations currently lack a dynamic configuration of timing), to be used in different contexts;
  • basic support for timed fade in/out;
  • support for playing multiple music tracks and sound effects at the same time, with fade in/out support;
  • support for dynamically changing cursors;
  • support for concepts like rooms, actors and objects, and how they can interact with each other;
  • support for room backgrounds and multiple “layers” (currently used for z-plane purposes, but in the future they may be used for parallax effects as well);
  • support for changeable “costumes” for actors (which was definitely “stolen” from SCUMM!);
  • support for following actors with the camera (room scrolling);
  • support for text rendering for different purposes (e.g., actors saying things, dialog puzzles, generic text, etc.) and using different fonts (text placement, e.g., splitting on multiple lines, needs work though);
  • support for room-, actor- and object-scripts that can be launched for automation (e.g., an NPC that must do something in the background, or activity in a room that is independent of user actions);
  • ability to start and stop cutscene-mode (which disables the cursor and any interaction);
  • basic support for dialog puzzles (which at the moment are hardcoded in the game, which I definitely want to change);
  • A-star pathfinding on rectangle-based walkboxes (I’ll probably change this to more generic polygons in the future, but using rectangles made it MUCH easier to get something working);
  • walkboxes that can also be used as triggers to change the scale factor of actors, or launch generic scripts (e.g., to have a bouncer stop you when you hit a walkbox, until you solve a puzzle);
  • basic support for translated text (where you provide different translations for the same sentence, and in the code you just reference their ID so that the right translation is used/displayed);
  • very basic support for objects to be used for UI purposes (which I plan to use for stuff like inventories, settings, etc.);
  • basic support of storing game assets (scripts, fonts, images, audio, etc.) in an archive format called BAG (which I’d like to obfuscate in the future, since at the moment it’s just a structured collection of all the files as they are).

As you can see, the engine ships a lot already, which is quite exciting (to me) to see working in the demo mini-games I’m working on to test the functionality as I implement it. That said, most of the features are far from complete and do need some work before they can be considered really done.

What’s missing?

Apart from improving the existing set of features (which are often either incomplete or a bit too complex/byzantine to use at the moment), there are some features that, at the time of writing, are sadly still missing. The two main ones I can think of are savegames (the ability to save a game state, and restore it later) and proper tooling.

Support for savegames is, to be honest, not that important at this stage: while it’s definitely a fundamental feature to support in a shipped game, for a quick demo where I’m prototyping stuff it’s way less needed, which is why I’ve neglected it so far. That said, I do have it in the back of my mind, and I do have a few ideas on how it could be implemented. Once more, the TP blog provides interesting info on how Ron solved this for his own needs: I think I’ll probably choose a slightly different approach, though, mostly because of the different ways we’ve implemented our own engine. In fact, from what can be seen in the blog post, Ron is actually saving the game state in the C++ code of the engine itself, accessing the Squrrel resources from there. As I anticipated above, I’m delegating quite a bit to Lua scripting for keeping state, at the moment, in particular using pre-loaded utility scripts (e.g., for creating rooms, actors, etc.) that can be seen as a Lua “extension” to the C engine itself: as such, while it’s indeed possible to read the Lua objecs from the C code of KIAVC as well, it sounds much easier to lazy ol’ me to implement a Lua utility (that game developers can use) to automatically create a Lua table with the info we have to save, encode it to a string (e.g., a JSON string), and then just pass that to the engine, so that it can be saved somewhere; restoring might work in a similar way, where the engine feeds the Lua script with a string blob, and the Lua utility that deserializes it and enforces it on the objects it has access to. Assuming that only some specific properties of each object needs to be saved, this looks like a potentially viable approach.

Tooling is another problem that will become substantial in the future. In most cases, wiring rooms, actors, etc. in a Lua script is not that hard (you just set some properties for what you want to be used and done), but there are cases where help from some tool would be quite desirable. A simple example are room walkboxes: in the current version of the engine, you’re supposed to provide a list of rectangles that constitute the different walkboxes of a room, as a set of “from” and “to” coordinates (top/left corner, bottom/right corner). It’s clear that, while you can manually write them on your own, this can quickly become a nightmare when you have to match them to the room background you’re using: sure, you can use an image editor to check the coordinates to use (it’s what I did for my demos), but it’s still a very slow and cumbersome process. The SCUMM suite itself made an extensive use of tooling for different purposes, allowing artists and editors to work on aspects of the game independently of the scripting itself (e.g., to place objects on top of a background, specify interactions in a visual way, and so on). This is one area where I expect to be quite slow, not only because I probably lack the proper skills, but also because I may not know exactly what people are used to: engines like AGS, for instance, come with their own tools as well, so there may be best common practices I’m completely unaware of since I’ve never used engines like those myself. Hopefully, should enough interest grow around KIAVC, generous developers may contribute some tools in the future 😉

Finally, as anticipated I can already create executables for Linux (I’m a Fedora user) and Windows (using cross-compilation on Linux via MingW), but not MacOS yet. I’m admittedly completely ignorant on that matter, and don’t know if getting a MacOS executable might be as easy as I did for Windows, but at least in theory it should be possible (my Janus WebRTC Server can be compiled on MacOS too, for instance, and I did nothing to make that work!). Again, this is an area where I hope I’ll get some help from interested people, e.g., with fixes to my ugly Makefile.

That’s all!

I hope this first intro picked your interest enough to give the engine a look. There’s not much in the existing repo in terms of scripts to use (just a few mini-games aimed at showcasing features) but hopefully, despite the current sad lack of proper documentation, they’ll be enough to get you to play a bit with the engine and get a quick demo of your own running! And, who knows, maybe someday someone will write a complete game in KIAVC too: I know I want to, but that may take a while, since while I’m an average developer, I’m most definitely a crappy artist 😛

Stay tuned for upcoming posts that will go a bit deeper in the engine features!

Advertisement

4 thoughts on “Introducing KIAVC!

  1. Just to let you know: it works great on MacOS. Just need to install the necessary packages using “brew”. Then just “make”, and it builds the kiavc binary, which works perfectly.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s