
Running decade-old games in containers - mbrukman
https://misha.brukman.net/blog/2020/04/running-decade-old-games-in-containers/
======
simosx
You can also use a GUI LXD container for this.

1\. First, setup your host according to the instructions at
[https://blog.simos.info/how-to-easily-run-graphics-
accelerat...](https://blog.simos.info/how-to-easily-run-graphics-accelerated-
gui-apps-in-lxd-containers-on-your-ubuntu-desktop/) You will be creating a LXD
profile called `gui` on top of the default LXD installation.

2\. Launch a container with Ubuntu 12.04, an adequately old Ubuntu version,
which is still support. Command: lxc launch ubuntu:12.04 mycontainer --profile
default --profile gui

3\. Copy the deb package of Machinarium into the container. Command: lxc file
push machinarium_20121106-ubuntu_i386.deb mycontainer/home/ubuntu/

3\. Get a shell into the container. Command: lxc exec mycontainer -- sudo
--user ubuntu --login

4\. Install the deb package. Commands: sudo dpkg -i
machinarium_20121106-ubuntu_i386.deb && sudo apt-get install -f

5\. Run Machinarium. Command: /opt/machinarium/Machinarium

You can reuse the container to install more software, or dedicate a container
for each game.

------
mbrukman
Hi HN, blog post author here.

Rather than just posting the end result that worked, this is my trial-and-
error "walthrough" of building a container from start to finish, in order to
run several games from a while back.

Hopefully, this can get you started with playing these and other games again,
or discovering them for the first time! Let me know what you think and if
you'd like to see more of this in the future.

~~~
Widdershin
I think this is an excellent post, because you demonstrate an applied use of a
bunch of excellent *nix tools, combined with a presentation of the mental
model that helped you put it all together.

I am largely self taught, and I didn't touch C/C++ for a long time, so there's
a lot of stuff people might take for granted (like the use of ldd), which for
a long time I had never encountered.

~~~
mbrukman
Thank you for the kind words! Glad to hear you enjoyed it.

------
zokier
I'm bit befuddled why the author decided to use volumes for /source and
/install instead of just installing the game into the container image. That
way you wouldn't need to keep the game files floating around on the host
system and overall would have more self-contained container. You could even
get fancy and use multi-stage container so that the installer wouldn't need to
be included in the final image.

The installer could be run under `expect` so that human interaction is not
needed.

~~~
Groxx
It's covered explicitly in the "goals and principles" section. They're aiming
for a reusable environment for older games, not a single-purpose one.

~~~
jayd16
They could make a base image and then an image layer that contains the game
files only. Now you have a single file image per game with a consistent base.

~~~
Groxx
Sure, as a follow-up they could do that.

That's (very clearly declared to be) not the goal of the author though.

~~~
jayd16
My point is that by separating the layers it does fulfill the declared goals
but in a more portable way. As implemented, there could be hidden dependencies
on the local file system or across game installs.

~~~
reificator
But it then prevents redistribution of the container images in a legal manner,
because the game files themselves are still under copyright.

------
markus_zhang
I'd really love to see a similar approach but applied to games much older,
like the ones you have to pull out a DOSBOX to play, or a Win95 virtual
machine. The Win95 games are going to be much more difficult to set up because
the VM needs a bunch of stuffs to work properly (sound, video) while the
DOSBOX does everything for you.

~~~
mbrukman
Blog post author here.

Yes, I'm planning to do this for much older games in the future, and you're
also right that DOSBox does a lot of that for you!

One thing I've noticed is websites that let you play using old DOS games via
DOSBox right from your browser (e.g., see
[https://www.dosgames.com/](https://www.dosgames.com/)), so I was going to
make a blog post for how to do that yourself, from scratch.

Would that be of interest?

~~~
markus_zhang
Yeah that definitely is interesting! Thank you~~

BTW is there some way to perform save/load functionality without log-in? Maybe
we can use cookies to identify users? Just a thought as I'm not a
programmer...

~~~
mbrukman
Note that I'm not the owner/developer of that site, so I can only guess how
it's implemented there. However, I can give you a general overview for why
logins are typically required for such use cases.

While you're correct that cookies is a good way to identify users, they could
be faked by other users (to steal or change your saved games), which is why
websites typically have user accounts where you have to prove you know
something (such as a password) in order to claim to be user id 12345.

If you don't have to prove anything to claim to be user 12345, then some
creative users on the internet will write bots that will claim to be every
possible user (in sequence), and either trash or delete their saved games, or
do something else to affect them in the future.

Thus, we have the need for user accounts on websites to securely identify
users and their settings, saved games, shopping carts, purchase history, etc.

If you're interested in learning more, take a look at:

* [https://en.wikipedia.org/wiki/HTTP_cookie](https://en.wikipedia.org/wiki/HTTP_cookie)

* [https://simple.wikipedia.org/wiki/HTTP_cookie](https://simple.wikipedia.org/wiki/HTTP_cookie)

Hope this helps!

------
tuco86
i managed to run diablo2 (release 2000) on wine in a docker container. with
ffmepg streaming it as a video. Was a real eye opener moment to realize what
can fit in these things.

~~~
zokier
Why would you need docker for wine?

~~~
tuco86
i was curious if i could run diablo2 on my kubernetes clusters.

~~~
jwhitlark
That sounds lovely! Was it playable? I'd love to take a look at the manifests,
if you could make them available somewhere.

~~~
tuco86
It's kind of playable using XQuartz on mac. But i'm only using that for
debugging the setup really. This is intended as a test bed for keras bot
experiments, so controls are not important to me.

Main components are wine, ffmpeg, nginx+nginx-ts-module and xvfb. It runs
diablo2 and livestreams the screen capture.

I'd love to push this to git or docker, but it's currently littered with
blizzards game files. I'm most likely not allowed to share the current state.

I put some files together to get a rough look. I'll try to make it a bit more
usefull when i'm done with actual work and not exhausted.

[https://github.com/tuco86/docker-diablo2](https://github.com/tuco86/docker-
diablo2)

------
galgalesh
If it runs on 16.04 you could put it in a snap package. I really like it for
installing older software. I created a snap package for Scratch For Arduino
(S4A), which is a pain to get working natively, but in the snap I can mess
with multilib and weird dependencies without it affecting my main install.

I think the advantage of snaps is that you can get easy access to the host
system using interfaces. S4A requires access to the USB Serial devices of the
host. In snap the snap I just added the `serial` interface but I'm not sure if
Docker has an elegant way to do that.

------
naringas
having put a few older applications into a Docker container, this article
tells it like it is.

docker run: some error. fix this error.

docker run again: another error, rinse and repeat.

------
dllthomas
I've been trying to get Obsidian
([https://en.wikipedia.org/wiki/Obsidian_(1997_video_game)](https://en.wikipedia.org/wiki/Obsidian_\(1997_video_game\)))
to run under emulation, but so far it's been too choppy to be playable.

~~~
butz
How did you run it? WineHQ lists compatibility as "Gold", but report is three
years old. Might be worth trying it out on latest Wine version.

~~~
dllthomas
I put the most effort into QEMU. I think I tried Wine briefly first, but don't
recall what trouble I ran into.

------
butz
Machinarium and Botanicula on Steam doesn't provide native Linux versions, but
at least both games have "Platinum" support on Proton. Found a native Linux
copy of Machinarium from HumbleBundle. To get it running on Fedora 31 I had
only to install single missing dependency: `sudo yum install libXt.i686`

Well, now I'll probably have to beat the game, while I'm at it.

~~~
simosx
On of the first Humble Bundles for Linux games came with a Deb package of the
game.

The game is a Linux i386 binary, which means that installing directly on your
host will pull in all sorts of i386 libraries. If you host is amd64, it is
quite messy.

~~~
loa_in_
Looks like Proton does a better job than snap or rpm. I don't get why there is
no Linux layer dedicated to translating x32 library calls into x64 calls. The
other way around is often impossible I know.

~~~
AnIdiotOnTheNet
Because historically the Linux userland community has a willful disregard for
binary, and often source, backwards compatibility.

------
AtlasBarfed
Does Wine run well from a container? I always found bottles a bit annoying.

~~~
mbrukman
Blog post author here.

I haven't tried it myself (yet), but I don't see why Wine wouldn't work from a
container, if you propagate access to the display into the container, as I
have done in the Dockerfiles in my post.

Here are some quick references I found that suggest this works:

* [https://github.com/scottyhardy/docker-wine](https://github.com/scottyhardy/docker-wine)

* [https://blog.simos.info/how-to-run-wine-graphics-accelerated...](https://blog.simos.info/how-to-run-wine-graphics-accelerated-in-an-lxd-container-on-ubuntu/)

------
lonelappde
Is this easier than VirtualBox?

~~~
mbrukman
Blog post author here.

A virtual machine solution (such as VirtualBox) requires more CPU/RAM
resources than a container, because you're running an extra copy of the entire
operating system, in addition to your base system that you're always running.

A container is much more light-weight than a VM because it relies on the
services of the underlying OS and just provides the runtime environment, but
not the OS; please see [https://www.backblaze.com/blog/vm-vs-
containers/](https://www.backblaze.com/blog/vm-vs-containers/) for more
detains on the distinction.

In any case, it would actually be more complex to use a VM, because I would
first have to do a full installation of Ubuntu in the VM, before I could get
started with installing the game, whereas with Docker, I can just build a
container image starting with ubuntu:14.04 as a base, and have it working in
seconds (minute or two once I started installing the required i386 packages,
but that's unavoidable).

If you look at the end result, it's actually quite a simple Dockerfile, and
the installation from start to playing will take you less time than installing
a full Ubuntu distribution in a VM.

------
4restm
can those containers run Crysis?

~~~
mbrukman
Blog post author here.

Looks like Crysis
([https://www.gog.com/game/crysis](https://www.gog.com/game/crysis)) is a
Windows-only game, so you'll need a different approach than what I've
described in my blog post, which is running Ubuntu inside containers.

If you want to play it on Linux, you may be able to do it using Wine
([https://www.winehq.org/](https://www.winehq.org/)), which you can run
directly, or inside a Docker container.

Alternatively, if you are using Windows, you may be able to utilize Windows
containers ([https://docs.microsoft.com/en-
us/virtualization/windowsconta...](https://docs.microsoft.com/en-
us/virtualization/windowscontainers/about/)), but that's not what I did in my
blog post, so YMMV.

If you do try this out, let us know if it works for you!

