The ADOM build system

Hi,

this week I'll cover the ADOM build system - something I've started working on shortly after I got more involved with ADOM development.

As you know we provide ADOM for many different operating systems (e.g. Windows, macOS, Linux, NetBSD, OpenBSD, FreeBSD, Raspbian and AmigaOS). It would take (too) much time to manually build an ADOM executable for each operating system, so we decided to fully automate this task.

What were the requirements?

We wanted to be able to build all executables on a single computer. This would make it possible to build a new ADOM release everywhere without having to carry around a lot of hardware. We also wanted it to be fully automated without having to do manual steps.

What is the ADOM build system?

The ADOM build system (that's what we call it) is a combination of virtual machines and shell scripts that automates the creation of all the ADOM executables/packages.

We use 14 virtual machines (one for each operating system) and utilize VirtualBox for virtualization. 

How does the build system work?

Since ADOM is programmed in C we use makefiles to build the ADOM executable.

1. everything starts with a single "make" command in the shell
2. this make command then calls other shell scripts that each create a single executable
3. these shell scripts execute the following steps (4-8)
4. start the virtual machine
5. get the specified revision of source code from the repository
6. execute another makefile that compiles the source code
7. download the resulting executable from the virtual machine to the current computer
8. stop the virtual machine

We can build all or a single executable depending on the parameters. Since the Git migration we can also specify the revision(s) of source codes for each repository (ADOM source code, NotEye source code and Steam SDK), so we can build every version we once built again without much hassle.

How long does it take?

To speed up the creation process we start 4 virtual machines in parallel. This reduces the time required to build all 28 executables/packages to around 20 minutes.

The executables for AmigaOS and Raspbian are cross compiled to make the compilation faster (it takes around 15 minutes to compile ADOM on a RaspberryPi 1).

What are the benefits?

Automatic building of executables is less error prone than building manually. Since we can build all executables on a single computer we don't need a "server farm" with lots of different computers.

What are the drawbacks?

Keeping all the virtual machines up to date can be a time consuming task.

What about continuous integration?

In theory we could use the build system for continuous integration. But since automated testing of ADOM is not really possible (it's not a technical problem but caused by the randomness of the game) we don't use it that way.

Will you add other operating systems?

If the demand is high enough we might consider adding more operating systems.

Until next time!

Animation and Line of Sight live previews

As Jochen moves on with the community server (I hope we can get some more details soon as it seems to have sparked some interest ;)) the graphical side has been progressing nicely these past two weeks.

First of all we wanted to give you a quick high quality sneak peek of what animations feel like in action. Take a look at a lone PC wandering through Dwarftown. We added some extras just to keep things interesting. Don't worry, it's just created in Exploration Mode with a Wand of Wishing. Killer Bugs won't be part of Dwarftowns' fauna in the next patch ;)

Create, Discover and Share GIFs on Gfycat

The technical side of ADOM

Hi everyone,

my name is Jochen and I'm the co-developer of ADOM. I've been working on ADOM since 1996 where I started to port ADOM to the Amiga computer. In the following years I've ported ADOM to different other operating systems like BeOS, Windows and macOS.

Since the crowdfunding campaign (about one year earlier actually) I'm also working on the ADOM source code itself. This means adding new features (e.g. the NotEye integration, the animation and sound system, the event system, etc.) and also fixing old and new bugs. ;) I'm also responsible for the ADOM infrastructure, e.g. our repository servers and some websites.

So, what did I do in the last few months?

• I migrated all source code (and other) repositories from Subversion to Git
• I updated the ADOM build system (which creates the binaries for all the different operating systems we support) to use the new Git repositories
• I also updated the build system to use the latest version of each operating system
• I prepared a Team ADOM cloud where we can share files more easily

Since last week I've been busy working on the new ADOM community server. We already started this in 2013 and also had a working prototype. But we weren't quite satisfied with it and there were some difficult decisions to make, so we decided to postpone it. It's quite shocking that it's 2017 now, but I promise that it won't take another 4 years until it is available.

The old prototype used TCP/IP socket communication between ADOM and the Java server. The new server will provide a REST API for ADOM, so we have to rewrite some of the code. Thankfully we already used JSON for data transfer in the prototype, so we can reuse this part of the code. The new server (at the least the part that ADOM will be "talking" to) will be based on Node.js.

We still need to decide which framework we will be using for the corresponding community website. But more on that later. ;)

That's it for now... until next time!

Ever expanding soundscape - where no roguelike has gone before.

Lucas isn't messing around when it comes to weapon sounds :)

Lucas has been hard at work digging into ADOM sounds. This week's focus was on combat audio, making the sounds clearer, easier to distinguish, and generally more detailed and pleasant to the ear. As you can see from the twitter pic above, Lucas is really going to town with this :) Given that rouglikes in general aren't known for their sweeping soundscape, Lucas' attention to detail blows me away every time.