Cheese talks to himself (about the Linux Game Jam 2018)

Last month, I was invited to help judge this year's Linux Game Jam. After being a participant last year and having a bunch of positive outcomes from my submission, I was both excited and honoured to accept the role.

Picking and rationalising favourites was a formidable task, and even now, I have a hard time narrowing down a list of interesting titles that's smaller than ten (and even then, there are some left out!).

Beyond judging, I also tried to give some actionable feedback on every submission and have pulled together some stats and insights from all of them, which you can find scattered across this article.


About The Linux Game Jam

The Linux Game Jam was inaugurated in 2017 by Gardiner "The Linux Gamer" Bryant as a way to bring together creative Linux users. Over the past three years, Gardiner's successful YouTube channel, The Linux Gamer, has become the focal point for a sizeable community of Linux users.

In 2017, the jam attracted 53 submissions from first-time as well as experienced developers from around the world. Gardiner's 2017 recap focuses on 6 notable games from that jam:

Of the developers of those games, only WebFreak and myself participated in this year's event, but it's likely that the short lead time on the announcement of the 2018 jam played a role in how many people were able to participate (more on that later).

SpaceD and Retro Island War received some post-jam development, with SpaceD getting graphics, music and physics updates, while Retro Island War received tuning for ship movement and AI.

At the time of writing, Olymporian 4x's game page notes that an update is expected to be released around the middle of 2018.

In September 2017 thanks to the kind of reception I'd received, I re-launched The Spicy Meatball Saves the Day with improved audio, a voiced "readme", puzzle logic fixes, text fixes, and a slew of enhancements that came from updating to the then-latest build of the Icicle engine (including initial gamepad support, cutscene pausing, and save/load bugfixes). Gardiner also did a post-jam interview with me about Spicy Meatball and other bits and pieces.

For 2018, Gardiner brought on three other prominent figures within the Linux community as judges - myself, Cassidy James and Bryan Lunduke. Cassidy is a UX Architect, who currently works at Linux focused OEM System76, and co-founded elementary OS. Bryan Lunduke is a Free Software/tech commentator, who co-founded the Linux Action Show and Jupiter Broadcasting, has been an openSUSE board member, and created the games Linux Tycoon and Linux Tycoon 2. I do lots of things, but the hats I wear that are most relevant here are that of a Linux based game developer, a Linux gaming evangelist, a game porter, and a person who writes a lot of words about games.

A scant 15 hours after the end of the jam, the event's four judges came together for an hour long round table chat, in which we discussed the games that stood out as interesting to each of us (likely with a high degree of overlap), including:

I also went through and left feedback on every submission, attempting to judge each game on its own merits and putting effort into providing actional advice. This was easy for some games and harder for others, but I think I managed to do a decent job of balancing reinforcing each project's strengths against highlighting possible areas for improvement. Across 2018's 34 submissions, this came to 8,600 words in total.

I'm both proud and gratified to see every single submission. It's been wonderful to experience and do my best to understand everybody's work.

↑return to page top↑

Organiser Interview

The Linux Game Jam's origins lie in a desire to see creativity flourish on Linux and among Linux users.

To give a little more insight into where the Linux Game Jam has come from and where it might be headed, I invited Gardiner to share his thoughts on his experiences as the event's organiser so far.

What motivated you to run the Linux Game Jam, and have those motivations changed over time?

I did the game jam in 2017 as a way to encourage us talented Linux folk to create content for our platform. It turned out to be a ton of fun! I got a ton of questions about the next one, so I set this one up with the same goal in mind! I was not disappointed.

What's involved with organising an event like the Linux Game Jam, and how are you hoping to improve this for 2019?

I honestly feel like I did't do the greatest job organizing this year's jam. It's only the second time I've done something like this, though... so I'm not going to beat myself up over it. Next year I hope to give everyone much more of a heads up. I heard a lot of people say "I wish I knew when it was going to be so I could've taken time off from work." 2019's jam already has a date!

What benefits do you feel game jams offer for developers, for players and for the industry?

For developers, I feel game jams give you a chance to challenge yourself. I feel, as a creative person, that limitation breeds creativity. The limiting factor here would be the timeframe in which to make your game. Plus, we are a group of uniquely qualified people, being Linux users. I mean, if you're running Linux odds are you've probably written a line or two of code in your life. I saw that as (perhaps) untapped potential. My hope was that, folks who had experience with coding but not with game design might take the opportunity to expand their horizons and have a blast.

For players, it gives you a chance to see what's possible in just a few short days and it gets you exposed to ideas and mechanics you might not otherwise try. I feel the same is true for the industy at large.

What surprises did you encounter along the way in the Linux Game Jam 2018?

I was surprised by the number of people who wanted to take time off of work in order to participate. I was also surprised by the variety of ways people interpreted "Versatile Verbs." Some folks made their games limited to only two buttons that did a huge variety of things. Others chose to embrace a more traditional control set but gave you the ability to be expressive with your inputs.

What outcomes have you seen so far, and what outcomes do you expect to come from the 2019 Linux Game Jam?

I've seen several of the developers promise to continue working on their submissions past the jam, and that's fantastic! For 2019, I'd love to have more participants and a wider and more open prompt.

↑return to page top↑

Games

For my coverage of previous jams (7DFPS 2013, 7DFPS 2014, AdventureJam 2015), I've typically provided a short list of cross-platform/Linux supporting games to make those easier for my readers to find.

Since all of the Linux Game Jam's submissions are playable on Linux, I'm going to skip that and just link to the jam's list of submissions. My feedback for each game can be viewed on the relevant game's submission page, so if you're interested in reading my thoughts on a particular one that's not mentioned here, you'll find them there!

To round out this section, I want to draw attention to the titles that resonated the most with me personally. Initially I had wanted to get this to a "favourite three", but found it very difficult to find any combination of three games that didn't leave me feeling like I was ommitting something important. Paring my shortlist down to five titles proved to be equally difficult. Long story short, here are ten submissions that I found particularly interesting in alphabetical order.

Not included here are ~Woguey Wikey~, a rogue-like presented through a lens of vapid cute speak (which I submitted a minor pull request to), and Flopper, a minimalist tower climbing platformer that does a lot with two buttons. Both of these were hard to drop from my list of favourites, so make that twelve, I guess.

Audible Dribble - murks

A screenshot of Audible Dribble

In Audible Dribble, players use audio input to control the shape of the floor in order to bounce a ball into a box.

Audible Dribble is, hands down, the most original submission this year. It is always enjoyable to come across unconventional, out-of-the-box, or subversive experiences that ask me to think differently about what games can be, and jams are a great environment to experiment and explore the space beyond games' typical identities.

There is some awkwardness present that goes beyond the unfamiliarity of something new. As noted in the "caveats" section of the game page, certain frequencies represented within the game are difficult for a human to make via phonation (larynx-produced sounds), and some calibration options for input sensitivity/granularity could go a long way toward making the game feel more controllable and less susceptible to noise interference.

The gameplay as currently presented is limited to maneuvering a ball into a box by bouncing it off a segmented floor that acts as a historgram of detected sounds. The combinations of ball position, velocity and direction only provide a small amount of variation before exhausting what the game has to offer.

It would be interesting to explore these kinds of controls in different contexts, such as guiding the ball around obstacles, hitting a moving target, or rolling the ball to specific positions without exceeding a maximum height. I could even imagine similar controls being interesting for a "platformer" of sorts where every platform had a sound controlled surface that the player used to guide a ball through more complex environments.

I'd also be interested to see whether an interpolated curve gave more control than the discrete bars present in the game at the moment.

I've played and seen a number of voice controlled games before, but nothing that attempts to implement this level of vocal control over manipulating an in-game world to influence entities. What's here is still pretty rough, but it's inspiring!

ENDUSER - Samsai, Tumocs and Tuubi

A screenshot of ENDUSER

ENDUSER is a text adventure in which players explore and work their way through problems by using various body parts as inventory items to interact with the world. For example, "use eyes" would be equivalent to "look" in a more traditional text adventure, and "use hands on keys" would be equivalent to "pick up keys".

As someone with fondness for and personal investment in text adventures, I was delighted to see this entry. ENDUSER is well written, and its balance of humour, self loathing and a familiar-but-odd view of its world makes for a delightfully surreal experience.

The "gimmick" of using various body parts as a verbs is fun, and a great exploration of the jam theme, but does get a little cumbersome over time. I'd love to see the game accept plural/singular variants for body parts (eg: "use brain" or "use hands") and have accelerators like tab completion and command history, but these are areas for potential polish rather than fundamental issues.

The game doesn't provide much in the way of directional cues, which on one hand makes it difficult to intentionally make progress, but on the other hand supports an air of aimlessness and awkwardness that I think supports the game's atmosphere.

The use of minor sound effects and music/ambient audio are great, and imbue ENDUSER's environments with a sense of oppressive indifference.

After exploring the apartment, venturing into the outside world, and diving into a dumpster, I eventually stopped after experiencing a crash. I'm looking forward to playing more though (especially after the post-jam stability updates the game has received), and hold ENDUSER as one of my favourite submissions this year.

KILLALL - Willbl3pic

A screenshot of KILLALL

KILLALL is an abstract action platformer with melee combat, in which players progress through a horizontally oriented level to defeat a boss.

There's a cool glitch aesthetic at work in KILLALL that I dig. From the hexdump-esque text in the in the menu and level background to the noisy platform textures to the minimallist representations of the player and enemies, there's a "rawness" at work that feels compelling.

The exploration of the theme is interesting and provides a lot of opportunities for skillful play to feel really powerful (reinforced by screenshake and particle effects), and that's a cool thing to land on in a game jam.

There are some issues with the player controls feeling a bit floaty and it being easy to inadvertently lift off the ground and not be able to jump, particularly when travelling downhill, but also sometimes when changing direction while at speed on a flat surface (a common problem that most physics based platformers overcome). I think that the game is still playable as is, but could be a lot stronger with tighter, more reliable controls.

The audio effects are appropriate and functional, but I'm on the fence about how well the music fits with the rest of the game. It feels bright and happy in a way that doesn't seem to reflect the kind of darker, abstract subvertive hacker vibe that I get off the rest of the game.

The single level feels like a good introduction to what a larger game like this could be like. It has solid pacing and provides some interesting challenges to master as players become familiar with the game.

Laser Temple - alesegdia

A screenshot of Laser Temple

In Laser Temple, players must reposition totems in a series of sokoban-esque challenges in order to progress through an alien temple to rescue a lost team of explorers.

The four colour CGA palette is wonderful, and coupled with chip-style sounds and mysterious music, does a great job of communicating the feel of an ancient alien temple. The puzzle elements found within the temple are distinct, but also carry a sense of vagueness in a way that make their purposes feel like a mystery until they've been encountered.

Puzzle complexity ramps up nicely, but doesn't really progress into challenging territory, leaving most solutions easy to discover without moving a piece. I don't think this is a problem for a jam game, but a larger scale game could benefit from dead-end solutions and more temple elements that change/affect the puzzle layouts in ways that aren't identifiable until they're interacted with (for example, perhaps moving a totem onto a switch tile could make a new section of floor appear).

The story of a lost team of sentinels in need of rescue leading the player deep into an alien temple feels like an evocative start, and though it was a little disappointing to not see that expanded upon I don't think that really detracts from the game that's here. In a larger version of this game, it might be interesting to have narrative breaks along the way as you find evidence of Kisaka's team that give players a moment to think about what they've done, what happened to the people you're trying to rescue, and what all this alien temple stuff might mean (without removing the mystery, of course).

Another possible consideration would be to switch the colour palette from the cool cyan/purple dominated CGA palette to the warm red/green dominated palette to communicate progress deeper into the temple.

There are also a number of grammatical issues and typos in the text as well that would be worth looking into.

Laser Temple is one of this year's most complete and cohesive submissions, and I'm looking forward to seeing where the project goes from here!

The Lord of Sands - Michael Miriti

A screenshot of The Lord of Sands

In The Lord of Sands, players take on the role of a tank to defeat what I assume is the titular Lord, in a bullet hell style encounter.

I have a lot of love for the game's minimalist style. The articulated "cute" demon is wonderfully animated. Parallaxing clouds and screenshake are executed well and give a great sense of scale. There's a high bar set here, but it's one that makes the player's tank feel out of place, with its flat sprite popping out against the perspective implied by the rest of the game's visuals.

The two firing modes are a nice attempt at interpreting the theme, but I can't help but feel that this would be much stronger if the default small shot had some tactical value that wasn't dramatically outweighed by the power of the super shot. I'd be interested to see how the game would play out if the hand smacking phases were accompanied by waves of small mobs or homing projectiles that the player needed to use the rapid fire small shot to take down.

The audio has a retro feel to it, established by the opening rumble as the demon emerges. The player and enemy hit sound effects almost feel like drum samples, and there's a fun kind of rhythm that emerges from the bullet patterns when taking damage while firing back. Music is notably absent, and might add a lot to the game's atmosphere, but I think that The Lord of Sands stands up well enough without it.

All up, The Lord of Sands stands out as one of the more polished submissions this year, and presents an experience that is well paced and feels whole.

Project AL - ObsidianBlk

A screenshot of Project AL

Project AL is a vibrant, retro styled platformer in which players must traverse challenging environments while collecting "coins".

I had a lot of fun playing Project AL, and to me, it stands out as being one of the most complete experiences offered by a submission this year.

The game has a wonderful look and feel that evokes a late 70s/early 80s feel that I really dig. Juhani Junkala's public domain music really pushes the 80s feel with its chip synth sounds and driving rock beat. Gameplay is challenging and feels nicely rewarding when secrets are discovered or a tricky move is pulled off.

It took a while for me to discover/get the hang of some of the more nuanced controls such as crouch jumping and ball mode, but once I worked them out, they were cool additions that felt like they opened up the game, not only by enabling more nuanced traversal of the game's environments, but also by exposing access to hard to reach and hidden areas.

The window for double tapping feels like it might be a little too large. I often found myself accidentally dodging, particularly when trying to position AL close to the edge of a platform (which meant unintentionally flying off). AL also doesn't "stick" to sloped surfaces when travelling downhill, making jumping while descending more or less impossible (a common problem that most physics based platformers overcome).

It's difficult to find significant areas for improvment in Project AL. There's definitely room for polish and refinement, but I think the core of the game is pretty solid, and the two (or one and a bit if you prefer to count the introductory level as lesser) levels do a good job of showcasing that core.

Siege Trooper - Compulsive Studios

A screenshot of Siege Trooper

In Siege Trooper, players take control of a tank-like man and his back-mounted cannon, which can be used to destroy enemies as well as navigate the game's platformer style environment by rocket jumping.

Siege Trooper was one of my favourite submissions this year, not only in terms of it being enjoyable and interesting to play, but also in being a thoughtful exploration of the "versatile verbs" theme, and in feeling like a complete and cohesive experience.

The two-stage power bar communicates a lot with little, and the controls are a lot of fun to learn and master (getting to the end felt pretty rewarding!). The level in the build I played does a good job of exploring and showcasing the type of experiences/maneuvers the game's mechanics offer.

There are some counterintuitive physics behaviours (particularly with regards to how momentum is preserved when sliding along surfaces), and I think there's also a little room for further tuning charge time, knockback and "jump" height. That said, I feel like these are areas that have already been given at least a little design attention, and I also appreciate that they're working well enough to be serviceable.

As with Project AL, what's shown here is solid and polished, and does a great job of showing of how the Siege Trooper's mechanics work while giving players a chance to explore them.

Two-Button Knight - Vladar

A screenshot of Two-Button Knight

Two-Button Knight is a slow paced one-on-one fighting game in which players control a knight and use combinations of minimalist keybindings to attack, parry, move and dodge.

I have a lot of fondness for the swordplay in the original Prince of Persia game, and playing Two-Button Knight started to evoke similar feelings once I'd gotten the hang of it. The implementation here is also a great expression of the jam theme, with two buttons being used to control a total of seven actions in a way that (after some time) feels pretty natural.

Audio and visual assets are simple, but fill their roles and do an adequate job of presenting the game. Character animations are rough, but charming. The attack animations do a nice job of conveying a sense of some of the weight of a sword.

There are two small, but noteworthy points that I think hold the game back a little bit.

The first is intermittent input inconsistencies, which seem to mostly manifest when transitioning from walking into another action, and can leave a player unexpectedly vulnerable at a critical moment (typically when approaching to attack). My impression is that when this happens, any key pressed during the double tap window will be ignored and will restart the double tap window from that point. Since button mashing feels like the Wrong Way to play this game, it's not something that feels like it crops up often, but when it does it feels significant.

The second relates to timing and signalling. The kind of game that I'd love to play this as would allow for players to reactively block incoming attacks. Currently, the amount of advance warning given by the attack animations before the window to effectively block closes feels too small to take intentional advantage of, leaving the game feeling more luck focused than skill focused.

Two-Button Knight was one of my favourite submissions this year, and is very close to being a game that I'd play for fun with friends/in my own time.

VING (VING Is a Nice Game) - ErikProW

A screenshot of VING

VING is a top down multidirectional shooter in which players must fulfill objectives while facing off against ghosts and slimes in the woods.

At first, I didn't expect to get much out of VING. Sure, it's a nice game, but the controls feel a little awkward and the enemies are a bit floaty. There's no audio, and the background sprites are repetitive.

What I found unexpectedly appealing about VING is the way that attention has been given to the experience as a whole. Instead of focusing on polishing individual facets of the game like enemy animations or fluid player control, the game embraces its rough edges and invites the player to master them.

I'm going to spoil what makes the game special here and talk about the way that I came to understand VING. If anybody reading would like to experience that for themselves, stop reading now!

This clicked for me when objectives shifted from "Kill X enemies!" to "Traverse the environment quickly." The role of enemies immediately shifts through the change in context, and the game stops being about getting projectile alignment just right for enemies who're creeping closer just below your line of fire and becomes about careening through the map's obstacles. At this point, damage rates and the relationships between enemy movement and player movement feel far more deliberate.

The objectives continue to reframe the game, culminating in a challenging bossfight that requires awareness and use of all of the game's nuances.

At this point, it's easy to assume that the game has revealed all that it is, but at the death of the boss, the player's attacks change to a supercharged auto firing version of the charged shot as all of the previously inanimate obstacles come to life and charge at the player with gaping maws and glowing eyes.

This final sequence requires far different behaviour than the single-focus boss fight and has more in common with a survival objective from earlier in the game. It's an absolutely wonderful moment where, for the first time, the game changes its mechanics in order to give a new experience that smashes the expectations that have been built up and morphed through the preceding stages.

I'm hard pressed to think of much that I would recommend changing or adding to VING beyond audio and some variation in the background sprite to make tiling a bit less prominent. There's definitely room for smoothing away some of the other rough edges, such as player movement controls, the "stickiness" of obstacles, the speed of the boss' "sprint" action, and the lack of enemy animations, but I feel that such changes would need to be handled delicately and thoughtfully in order to preserve the game's identity, challenge and charm.

VING was one of my favourite submissions this year, and I really enjoyed the challenges it offered and the surprises it gave me.

Wereshift - Clipsey and Shramper

A screenshot of Wereshift

Wereshift is a survival stealth brawler in which players take on the role of a werewolf with constantly draining health, who can transform between wolf form, werewolf form, and human form in order to survive the night.

There's a lot of cool stuff going on in Wereshift. On the surface, it has solid visual design and a lot of cool atmosphere. The "versatile verbs" theme is expressed through three different forms that respond to the same controls in different ways: human (stealth), wolf (movement speed), and werewolf (attack speed).

Looking deeper reveals a bunch of systems at work. Health drains over time, but hiding in bushes will halt that drain, and killing enemies will restore health. Enemy AI has several alert states that change how and whether they react to you in your various forms. Alerted peasants will occupy buildings and fire arrows, but will leave when they are no longer alert. Transforming into human form is only allowed when in the shadow of a house. AI will not react to you when you are in human form unless they have seen you transform. All of these elements end up playing into each other in ways that encourage and reward a variety of approaches. It's rare to see this level of (game) design thoughtfulness in a jam game.

That said, there are several issues and areas that feel like they have room for improvement. Wereshift doesn't communicate objectives to players very clearly, and many of the game's nuances aren't apparent without spending a length of time with the game that will likely far exceed the amount of deaths a player is likely to give a jam game before moving on (this isn't a problem with the game per se, but instead lies more with its framing here).

Unfortunately, a bug also prevents nights from ending unless all humans have been killed, which takes away some of the stealth/pacifist gameplay options, and limits the opportunities to players to progress to the next night and feel like they're making headway enough to pay attention to the game's smaller details.

With the high production values of everything else, audio feels notably absent (I understand that currently this is a limitation of the in-development engine, Polyplex). There's a big opportunity to enhance the game's atmosphere and push tonal shifts between the player's different forms (for example, human form could be accompanied by eerie and unsettling music as you pass among and mingle with your enemies, while werewolf form could have a driving beat that carries the energy and excitement of your most powerful form).

Since Wereshift is such a strong title, I believe it can stand up to some extra scrutiny of some of its mechanics that feel like they need some extra tuning. I've offered some suggestions over on Whereshift's jam submission page. If you're interested in those, you can find them over there.

Wereshift was one of my favourite submissions this year, and I'm very much looking forward to seeing what comes next. I am a werewolf, awoo!

↑return to page top↑

Participants

The Linux Game Jam 2018 attracted a total of 34 submissions. Unfortunately, we don't have any solid numbers on team size beyond where developers have chosen to include those details in the game description or a credits file included with the game. My anecdotal impression is that a majority of submissions were by single person teams, often drawing upon Creative Commons licenced or Public Domain assets to help fill in skill gaps.

Games from participants with prior participation.

Participants' prior games, based on submitting itch.io accounts.

Over two thirds of this year's participants were new to the Linux Game Jam. With less than a week of lead time between the announcement and the jam start date, it feels easy to infer that this had an impact both on the total number of participants and the number of people who were able to return this time around.

The following participants participated in both the 2017 and 2018 events. JaredLevi submitted two games in this year's event, and is counted twice in the Games from participants with prior participation chart above.

The event had 126 registered participants. Scrolling through the names, I recognise contributors to the few multi-person submissions I am aware of, but it seems that most people who had registered interest didn't end up submitting a game.

Over one third of submitting participants had not previously released a game on itch.io (where The Linux Game Jam is hosted). Assuming that this is generally indicative of their level of experience, it's great to imagine that The Linux Game Jam has been responsible for helping a whole bunch of first-time developers find their feet.

As with all endeavours, "success" (whatever that means) isn't guaranteed, and invariably there will be some submissions that are more fully realised than others. I want to touch on those ratios here, but before I do, I want to be clear that my intention isn't to draw negative attention to the games that appear to need more work than others.

It's my firm belief that anybody who participates "wins" if they made an attempt and learned something along the way. Comparing the work of a newcomer taking their first steps with game development to that of an experienced game developer doesn't make much sense, and if anything, the less experienced developer has more to gain from support and encouragement than the more experienced developer does.

These numbers also don't take into account further work that games have received. Notably, Cube Slide was uploaded without game content, and Jump Shot didn't have a gameplay loop, but both were updated after the jam submission deadline and are now playable games.

Completedness of games at the end of the jam submission deadline.

For the purposes of this chart, I'm using "unplayable" to represent anything that doesn't run or doesn't have an identifiable/functional gameplay loop, "polished" to represent anything that feels well executed or gives the sense that it has been iterated upon, and "playable" for everything else. The boundaries between these are subjective and for the most part arbitrary, and are only useful for getting an indication of the distribution of polish/iteration across the jam's submissions.

The ratio of "unplayable" games in this jam feels notably lower than many others that I've participated in. It's hard to say whether that is likely the result of more successful projects or fewer people submitting incomplete work, but within the community spaces that participants were active in, I didn't see indications of a significant number of people who had been working on games but hadn't submitted them, though the comparatively large number of registered participants definitely suggests that there was at least interest. It's possible that the short lead time on the event announcement also led prospective participants with less confidence to avoid the event.

The high ratio of polished/well executed games seems to support the notion that the jam submissions were primarily dominated by participants who had realistic goals and understandings of the skills, tools and availability.

↑return to page top↑

Participant Interviews

For some first hand perspectives on participation, I invited the developers behind my favourite ten submissions to share their thoughts and expeirences (at the time of writing, ErikProW, developer of VING is yet to respond). These are:

What attracted you to the Linux Game Jam?

alesegdia (Laser Temple): I wanted to join a game jam and I use Linux, so it was pretty clear when I saw this jam announced!

Clipsey (Wereshift): I'm a friend of Gardiner (The Linux Gamer), while talking about my engine he asked me if I was going to join the jam. Which I at the time, did not know about. He told me a little about it and it sounded cool. So of course I joined, Linux being my daily driver.

Compulsive Studios (Siege Trooper): The fact that this was an opportunity to make a Linux application was hard to pass up. I've been a Linux user for almost 10 years now and its always great to see the platform get some gaming love. Game jams really aren't my thing so the requirement had to really stand out in order for me to do this.

Michael Miriti (The Lord of Sand): I'm a long time Linux user and also Gardiner's "The Linux Gamer" long time subscriber. I support anything that helps in popularizing Linux (especially as a gaming platform) and also I just LOVE making games. So there was no reason to not participate in this jam :)

murks (Audible Dribble): Version 11 of Löve, my favorite game engine, was released and the Linux Game Jam got announced a few days later. It was the perfect opportunity to try some of the new features.

ObsidianBlk (Project AL): Simply... I'm an exclusive Linux user at home (Arch and Xubuntu). When I happened to see a "Linux" game jam, my mind said... Yes! Yes! So much YES! Lol.

Samsai, Tumocs & Tuubi (ENDUSER): Tumocs and I participated in Linux Game Jam 2017 and we had quite a bit of fun making Sauna Simulator 2018, so we decided to try again and see what we could come up with. We also considered it a chance to improve our coding and writing abilities. Our third team member, Tuubi, kind of just tagged along since the two of us were going to participate (not to downplay his contributions though!).

Shramper (Wereshift): I didn't know the Linux Game Jam existed, as I'm a Windows user. Clipsey invited me to take part in the game jam, and I don't care which OS the game is made in, as long as a game is made!

Vladar (Two-Button Knight): Having both Linux and game development among my interests the answer is pretty obvious =) Also, it's a good excuse to work on my current game engine - Nimgame 2.

Willbl3pic (KILLALL): I wanted to write some code but didn't really have much motivation to work on any of my current projects. I decided to have a look at itch.io's jam page, and I saw the Linux game jam. I loved the idea, because I feel that Linux really needs more recognition in gaming.

Have you worked on any games previously? If so, what are they, if not, what's inspired you to try?

alesegdia (Laser Temple): I used to work on game things a few years ago but never finished anything. Then I discovered game jams and felt motivated to join one so that I was forced to finish something, even if it were something awful. Finishing the first jam as a one man army was a big hype and made me want to join even more of them, so I really got hooked to game jams for like two years. Then for personal reasons I lost the habit and desire to compulsively participate in jams, but I still do it from time to time.

Apart from game jams, I have worked on unfinished prototypes that I'd like to continue some time in the future and also a few little complete games. Regarding the question about which games, here you can see all the game things I've worked on, but beware! some of them are unfinished prototypes or very old as previously said!

Clipsey (Wereshift): I have worked on quite a few jam games over the years, generally Ludum Dare. But the games never got far enough to be... Well, actual games.

You can see games like Twotler, which was just about mashing your keyboard, you couldn't win. And the game would crash shortly after writing a bunch of "tweets".

I got inspired to make games, by DOOM for MS-DOS. It was the first game that really got me to feel what was possible to make with computers. And there, I was hooked. I went on to learn a bunch of APIs, like XNA, SDL, Gl 1.0, etc. While experimenting.

Compulsive Studios (Siege Trooper): I've always made little prototype games in my spare time like most hobbyists do. The only other game I released was a Gulag for the Ouya XD. It was a nice free 2d sidescroller that I believed the console needed, and for the most part I was given a lot of positive feedback on it from the community. I wanted to at least jump start that challenge of making another game, so I believe that the jam was definitely the inspiration I was looking for.

Michael Miriti (The Lord of Sand): I make games as a hobby for about 15 years now. I participate in different game jams and compos like Ludum Dare and also in a lot of more obscure ones. No major success yet though. Rather successful jamwize was my LOWREZJAM2017 entry 64 FISTS which got 20th place out of 233. Also I participated in the last year's Linux Game Jam with another bullethellish game. It got 5th place out of 53 but I still don't think it was that good.

murks (Audible Dribble): I have made a couple of small games, mostly for our local game jams. They can all be found on murks.itch.io but I'm not particularly proud of any of them.

ObsidianBlk (Project AL): I've only done one other jam besides the LGJ, and that was the Fantasy Console Jam #3. As for games in generally, I've always had a project or two I would start related to games, but I always had the tendency to program "from scratch"... no engine. Needless to say, that's lead to a LOT of dead end projects. I decided I needed to break that failing cycle of mine and figured game jams could help... force me to use engines and design quickly. I know devs have been saying this for years, but, it's really true, start small and use tools. Don't try going from scratch[1].

Samsai, Tumocs & Tuubi (ENDUSER): None of us in the team has any formal game dev experience or education. Tuubi has worked in the software field while Tumocs and I are still in the process of learning. But we did make the aforementioned Sauna Simulator 2018 in last year's jam. In addition to that we have just made some personal hobby projects.

Shramper (Wereshift): This game was my 11th jam game I've made, but I've also made 3 others, with one being shipped to mobile Android called Tram-Panic. Otherwise my portfolio site has all my other games that you're welcome to try out.

Vladar (Two-Button Knight): Aside from participating in LGJ 2017 (with Glorious Glacier Grotto), I've created a decent amount of games through my years of programming addiction (and haven't finished even more, probably). Nothing serious and worth showing off though; mostly enthusiast's experiments and a couple of unsuccessful attempts to enter Flash market during its prolonged demise.

Willbl3pic (KILLALL): I've taken part in Ludum Dare 38, 39, 40 and 41, and also the xkcd jam. My entries for those are my only completed games, but I have two other incomplete games.

The first is a singleplayer game called Haunt, where you play as a ghost and have to make your way to objectives using abilities such as possessing people, turning invisible or firing energy bolts at people. Almost all of the core gameplay is there, but I haven't added any textures or models, and there are few levels.

The second is a multiplayer team-based FPS called holo-match. This is very early in development, but the idea is that there will be many maps, and each one will have a gimmick, such as changing gravity, which players can use to their advantage.

Both of these games are open-source, and available on my GitHub.

What was your favorite part of working on your Linux Game Jam game? What did you learn, and what were the biggest hurdles you faced?

alesegdia (Laser Temple): In terms of general jam feelings, I always like when the game starts to take real shape. Also getting feedback is always very nice in order to learn a lot from players.

Talking specifically about Laser Temple, I spent a lot of time working on the editor, and I couldn't start to make levels until the very end of the jam (last few hours!). My favorite part was when I started to notice that the idea felt kind of interesting, since when I started to work on it, not much expectations were held.

A kind of hurdle I faced was the need to cut off some block types that I had in mind in order to be able to finish the game. At first I thought the game wouldn't work if those blocks were missing, but as I worked on the game and thought on possible levels, I noticed there could emerge nice patterns on it. I was a bit sad to not be able to work on more levels, since the ones that there are feel quite simple and easy, but this can totally be patched in the future :Þ

As in all game jams, I learnt a bit more of good scheduling practices!

Clipsey (Wereshift):My favorite part was being able to use my own engine I had written from scratch. As well trying out new tools to increase efficiency while working, like Trello. Aswell, the challanges that arose when stuff broke in Polyplex, which I had to patch mid-jam (The entire first day was spent getting VBO buffers working again so that I could draw stuff)

Compulsive Studios (Siege Trooper): My favorite part of the jam was probably the workspace situation I put myself in haha. I dug out an old core 2 duo office desktop, put linux mint on it and set up my dev environment. This machine was literally only used for the game and it gave me that "work" feel when I was on it. I'm not sure if this makes sense but in order to kind of avoid distractions, I wanted to make sure that this machine was all I had running during the jam. I didn't really have much free time for this project so the only way to manage my time was to find a way to focus on that time slice. So I learned time management is key!

Michael Miriti (The Lord of Sand): I think the core idea of the game was good. I had a lot of fun developing it in my head :) Unfortunately I had only a couple of nights (and one full sleepless night) to get it done so I could accomplish only like 10% of what was planned. Learning about the versatile verbs was a great bonus and also discovering Mark Brown's youtube channel was like finding a treasure. Absolutely essential channel for everyone who wants to get deeper into the game design.

The biggest hurdle was the theme itself. I failed miserably to deliver anything substantial on it.

murks (Audible Dribble): My favorite part was figuring out the audio processing. It was an ambition of mine to do audio programming but it just never happened, so this was again a nice opportunity to dabble a little. I found a FFT library that helped a lot but it took me a bit to understand the output. It all worked out OK for the game but it is probably a prime example of how not to do audio processing. Both audio and physics require a lot of tweaking, which takes time. Time is something you usually don't have during a game jam. This is the third game where I made the mistake of using proper physics.

ObsidianBlk (Project AL): Programming is my #1 favorite thing and it still holds true in the jam. I'm a barely passable artist, but it's hard for me to keep my attention when working on the graphics. This is why I mostly used simple tiles in my game. As for hurdles... I'd say the biggest one was getting so distracted by the multiple moves AL could do, that I nearly ran our of time to code up obstacles. Even then, I only managed "spikes" and those rotating wands. I has tracking lasers, ground monsters, and a Boss battle in mind in the very beginning. Originally, AL was suppose to even have a blaster (I even spent the time drawing it)... but time... time is the biggest hurdle of them all. That's fine. I just had to think quick.

Samsai, Tumocs & Tuubi (ENDUSER): Considering our game was a text adventure, it probably doesn't surprise anyone that we really enjoyed the writing process. It was fun to just dive headlong into writing some humorous descriptions for rooms and items. It was also extremely satisfying seeing the small pieces here and there coming together to form a (more or less) cohesive game.

During the development the biggest hurdle we encountered was how we could effectively divide the game into multiple, roughly equal sized pieces for each of us to work on in parallel. Initially the game consisted of a single content file, which we loaded from our "engine". When we split the content into multiple files we were having some trouble sorting the dependencies for the various rooms we were writing until we just decided to concatenate all the individual content files into one big content file at runtime. That way we wouldn't be stepping on each others' toes every time we pushed our changes to Git and Python didn't complain about circular import statements.

Post-release we also learned that we hadn't actually done quite enough testing and we shipped with quite a few bugs. After having watched some people try our game we also realized that a fair amount of people don't actually know how to play text adventure games and our game being a bit eccentric even on that front certainly didn't help.

Shramper (Wereshift):Wereshift was special because we had a prior prototype of it that I personally wasn't satisfied with. This time around, I really thought about the art style and how it can be fed into the game. It was certainly something I didn't really try before, but it turned out really well. Even if the sprites are small, it made it more rewarding to animate them, and place them in an environment. It was hard to make sure that the player character and the background didn't obscure anything important or were conflicting, and that players can understand the game's mechanics in terms of stealth. It's still something we need to iterate on, but I felt we did more than we expected, and I'm content with that.

Vladar (Two-Button Knight): As I mentioned previously, working on a real-life project helps me see what to improve in the engine, exposes its hidden bugs and imperfections, and shows what features need to be added to amend the development experience.

Willbl3pic (KILLALL): My favourite part of developing KILLALL was getting all of the screen shake and particle effects just as I wanted them, then jumping around attacking things to test them out: I really wanted it to feel like you slam into the enemies hard when you attack them.

I learned that particle systems aren't as difficult as I thought they were: they're actually pretty easy to use once you get the hang of it!

As for the most difficult part, I would say that it was making the boss work correctly. It was initially just a scaled up version of the regular enemy, but it just didn't want to move correctly (If I remember correctly, some raycasts weren't hitting the correct things). I ran out of patience and just decided to copy and paste the enemy controller script and multiply all the numbers by five. It worked: when you're in a hurry, doing things in a "bad" or "messy" instead of spending time debugging it can be better, because it lets you spend more time on the more important stuff. But when you have the time, you should always go back and see if you can do it in a better way!

Do you plan to continue developing your Linux Game Jam game?

alesegdia (Laser Temple): Yes! I never plan on doing this in other gamejams but I think Laser Temple can have a good reception given the feedback it got from the jam players. Therefore, I am planning to polish it a bit and add more levels and features. To keep in touch with updates on the game, you can follow the itch.io page or the Laser Temple's twitter (@lasertemplegame).

Clipsey (Wereshift): Possibly. Me and the artist will be trying out a few game ideas before settling on the one we'll focus on first. But we do expect to finish Wereshift, some day.

Compulsive Studios (Siege Trooper): I definitely want to expand on the core gameplay mechanics of this game. I think that it would be fun to see this kind of gameplay in a finished product. It's way too small of a game with a lot of potential so hopefully I can get back into gear soon and see what other ideas I can add to it.

Michael Miriti (The Lord of Sand): Most likely not. I rarely come back to my jam entries to continue working on them. But sometimes I do, so who knows :)

murks (Audible Dribble): It is more of a tech demo for audio input than a game so I probably won't continue it in its current form. The scheme didn't work well, it was very hard to control the ball. A lot of tweaking or configurability could help, maybe. My current thoughts are that it might work better if I simplify it somewhat, either reduce the frequency input to a few controls, for example lows/mids/highs, or just go with different volume levels. I can see such a simplified audio control scheme working in some quirky little games. Local multiplayer could be fun too. I have a few ideas, so stay tuned ;)

ObsidianBlk (Project AL): I've been seriously contemplating it. Not sure exactly the direction I want to go with it though. Do I want to spend time to upgrade the graphics? Do I want to keep it a "coin collecting" level maze? Do I want to give it a story of sort. As I'm brain storming this answer, I thinking a cross between Mega Man and Abe's Oddysee. If I do continue work on it, though, it'll definitely still be open source (the code, anyway).

Samsai, Tumocs & Tuubi (ENDUSER): We have been planning on overhauling the game and a proper, more noob-friendly terminal user-interface is being developed right now. The pace of development is dictated largely by our motivation though, so we have no timetables regarding game updates. But when it's done, all the changes will be on our Gitlab and on Itch too.

Shramper (Wereshift): Clipsey and I do, though we have other ideas we want to pursue, and we usually take a fair bit of a break. I'd imagine Clipsey wants to flesh out the Polyplex Engine some more, while I have some of my own stuff I'm trying to work on. I'd expect to work on Were-Shift again in the future, but when in the future isn't known yet.

Vladar (Two-Button Knight): I think so, though finding both motivation and free time for this is pretty tough sometimes. It would be great to use Two-Button Knight to experiment with networking through SDL2 (which I haven't at the moment).

Willbl3pic (KILLALL): I'll probably add more levels at some point and improve the movement to make it less floaty, then release it as a v2.0. I'm not sure whether or not I'll continue working on it after that.

What advice would you have for anybody wanting to develop a game using Linux?

alesegdia (Laser Temple): I don't really have a linux specific advice, since there are as many tools to make games in Linux as there are in Windows or Mac (Unity is on linux nowadays!), but talking in general terms of participating in a game jam, I'd recommend to aim short and know your tools. If you aim short enough, you're more likely to finish something, and of course knowing your tools leads to spending more time in the game and less in guessing how your framework, engine or library works.

Final words: thanks to all the jam organizers for the Linux themed game jam! It has been pretty cool to get in touch with other Linux game developers.

Clipsey (Wereshift): Learn more low level game development, especially if you are trying to give an native experience. Toolkits like MonoGame are good starting points as they give that extra level of control and optimization, while still being easy to code in.

Compulsive Studios (Siege Trooper): Linux is a tricky platform to work on, whether you are developing a game or an application. For the developers, I would advise they stick to a well known framework or engine that runs nicely on at least the major distributions of Linux (Fedora, Debian, Ubuntu, Mint). Building an AppImage or Snap pack of your game would also help a lot of end users out with installation. I chose löve2D simply because the engine runs on most major distributions of Linux. So choosing an engine especially if your developing for a jam will save you a ton of time.

Michael Miriti (The Lord of Sand): Just do it :) Linux a great platform for gaming as well as for game development. There are plenty of tools to get started. My personal choice for 2d games is OpenFL framework. You can get started on any OS you like (Windows, Mac) and continue on Linux.

murks (Audible Dribble): I don't think that developing for Linux is all that special. Make sure your engine, libraries and tools support the OS. Figure out how to build and distribute on the target OS. Test it, early and repeatedly. The usual way to distribute a Löve game on Linux is to just ship the Löve file and tell the user to install the appropriate Löve version. The problem is that many distributions only provide old and thus incompatible Löve versions if you develop using the latest one. Löve is a bit awkward for commercial games where users expect a smooth ride, even on Linux. It's doable, 'Move or Die' did it by shipping the engine and dependencies with the game, with all the possible trouble that entails[2].

ObsidianBlk (Project AL): I'm only a hobbiest, and have no professional background in game development. In my opinion, however... if you're already committed to making a game (small, big, or somewhere in between) there is nothing about Linux that makes that endeavour necessarily any harder (or easier) than if you were to develop on any other PC platform, except, perhaps that... most Linux tools are seemingly built with not just Linux, but all other platforms in mind. If you aren't already dedicated, why not build your game using tools that will allow you to share your creation with EVERYONE (Linux, Windows, Mac, and possibly many others).

Samsai, Tumocs & Tuubi (ENDUSER): Speaking largely as non-developers our advice would be that there are quite a few nice tools to develop games on Linux with. Cool game engines like Godot in particular come to mind. But we think it's also important to emphasize that you don't always need to master a whole game engine to make something. Our game was written mostly with Python's standard library functionality, stuff that you'd learn in the first couple of weeks of studying the language. So, just getting something you know and trying to make things with it is better than making nothing at all. And if you want to try and make something for other's to enjoy as well, game jams like Linux Game Jam offer a nice place to experiment with things and also to learn about deadlines, planning, teamwork and all things related without having to risk anything but some of your free time.

Shramper (Wereshift): I couldn't help with advice USING Linux, but for those not using it, be patient and understandable. You might have to download some things here and there, or use command prompts to load things, but it's not so bad when you start to test the game and see all the work put together.

Vladar (Two-Button Knight): Can't say anything about 3D,but if your aim is 2D, then SDL2 is pretty great if you want to work really low-level, otherwise there is a plethora of high level cross-platform engines and tools. I feel that Linux is a solid choice as a development platform. Also, look into AppImage for a cross-distribution compatibility, if you haven't already.

Willbl3pic (KILLALL): I'd say firstly, to know your tools. Unity is a good engine choice, and I've heard good things about Godot. As for textures, many people use GIMP, but I'd say that Krita is better for texture creating. Other tools I use include Blender and Bosca Ceoil.

My second piece of advice would be to remember about WINE. Quite a lot of software is unfortunately Windows-only, and sometimes you just can't find a Linux-compatible alternative. WINE is amazing in these circumstances: for example, the sound effect creator bfxr, which many people use in game jams, runs beautifully through it.

Thirdly, I would say that one thing you should always bear in mind is that there are loads of things already installed in your computer which can be useful. For example, to generate the backgrounds in KILLALL, I ran less /dev/urandom and copied and pasted the output into Krita.

↑return to page top↑

Code and Tools

While not unique to the Linux Game Jam, one of the things that I enjoy about this event is the encouragement to share sources under a permissive licence. This is not a requirement, but most participants embrace it. This year, over three quarters of submissions included sources or included a link to sources as a part of the submission.

Source availability by distribution platform.
Anything without a licence that doesn't explicitly advertise source availability is
listed as N/A even if source is included with/extractable from the game's data files.

The most popular licence this year was the MIT licence, used by 35% of submissions with source available. 27% of submissions with source available used GPL version 2 or version 3. A further 23% of submissions with source available didn't include any kind of identifiable licence terms. The remainder were spread between the Apache License 2.0, 3 clause BSD, CC BY-NC-ND and WTFPL.

Licence choices typically reflect the philosophical alignment of a developer, and the level of importance they place of preserving the freedoms that the Free Software movement is anchored around. Typically, those aligning hard towards the importance of preserving those freedoms are more likely to select a GPL variant, while at the other end of the spectrum, those who don't see these freedoms as important will either choose to not make their works available under a specific licence, or will opt for something similar to the MIT licence.

Distribution of licences across all submissions.

The most popular languages used by participants this year appears to be driven primarily by their choice in technology. The three most prominently used languages (GDScript, Lua, and C#) correspond directly to the three most prominently used engines (Godot, Löve, and Unity).

That said, these only account for 53% of submissions, C and Python occupying the middle ground and a remaining 24% spread between C++, Haxe, Java and Nim.

Distribution of languages across all submissions.

Looking more directly at engines and middleware, Godot, Löve, and Unity were used to create 53% of submissions. With the level of maturity/accessibility and the feature sets offered by these tools, it's great to see all of these being recognised by the community.

SDL2, including satellite projects such as SDL_Image, SDL_TTF, etc., was used directly (SDL is used indirectly by many other submissions via higher level technologies, such as Löve and Unity) by a further three projects, leaving a remaining 35% of entries spread across a diverse range of tools and environments.

Distribution of middleware across all submissions.

In particular, it is interesting to note that four submissions made use of middleware previously created by their developers. Not only do the presence of these tools demonstrate that participants are making tech that is larger than a game jam submission, but actively making games in these tools also provides real-world use cases that can help further development and refine said tools. Every project projects listed here includes feature or bugfix commits referencing Linux Game Jam 2018.

API2 was used for VING and developed by ErikProW. API2 is a game framework written in C that uses SDL2, SDL_image, SDL_ttf, GLEW and BlueZ, and exposes convenience functions for 2D and 3D rendering, networking (TCP and Bluetooth), windowing and input. It appears to still be under development and does not have a visible licence.

Nimgame 2 was used for Two-Button Knight and developed by Vladar. Nimgame 2 is a 2D game engine written in Nim, making use of sdl2_nim, which provides access to SDL2, SDL_gfx, SDL_image, SDL_mixer, and SDL_ttf. It is currently in an alpha state, and is available under the MIT licence.

Polyplex was used for Wereshift and developed by Clipsey. Polyplex is written in D, making use of imageformats and d-colorize, as well as Derelict to expose functionality from SDL2, OpenGL, and OpenAL. Polyplex is a general purpose game development framework aiming to provide functionality simiar to XNA/Monogame/FNA. It is currently under development, and is available under the Boost licence.

Pydler was used for ENDUSER and developed by Tumocs. Pydler is a terminal based text adventure engine with audio support, written using the Python standard libraries, and is available under GPL version 3 or later.

Also of note are the games which effectively created their own project-specific engines, either using lower level libraries or creating all of their functionality from scratch using language APIs.

Cheer was developed in C using SDL2, stb_image, stb_easy_font, OpenAL and OpenGL.

Exchanges was developed in JavaScript using common browser functionality.

Signal Bounce was developed in C, using SDL2, SDL_image and SDL_mixer.

XO was developed in C, and uses GLFW and GLEW

↑return to page top↑

The Future

Looking ahead, the 2019 Linux Game Jam is locked in for the 10th of April. Further details are vague, and will remain so until the week preceding the event. At this point in time, the Linux Game Jam feels set to continue as a regular event. Gardiner seems keen to continue to iterate and build on previous years, and I am confident that we will see further refinement of the jam's identity and organisational processes.

The lower submission count this year may be a step backward, but if it is solely the result of short lead time on anouncement, it is not likely to have an ongoing impact on participation rates. That said, there have not been enough events to draw a baseline from, so the impact of this year's jam on the growth of the event will be very difficult to measure meaningfully.

A number of developers have indicated a desire to continue working on their games, and we may yet see more from the likes of Laser Temple, Juan's Saga, Siege Trooper, ENDUSER, Gunship: Tactical Munitions Capitalism and of course Stickmans Journey.

Beyond that, the Linux Game Jam's real legacy lies in the learning opportunities and empowerment participants have received from trying their hand at making something, with some side benefit to Linux-supporting tools in the form of bug fixes, showcases and increased community mindshare.

I had a great time being involved with the Linux Game Jam this year, and whether its in an organisational capacity or as a participant, I'm certain I'll be around for the next one.

↑return to top↑

A note from cheese

A note from Cheese

Thanks for reading!

Big thanks to Gardiner, alesegdia, Clipsey, Compulsive Studios, murks, Michael Miriti, ObsidianBlk, Samsai, Shramper, Tumocs, Tuubi, Vladar and Willbl3pic for their contributionsto this article, to the Linux Game Jam, and to the culture of making games on Linux!

Thanks also to the other judges, who took the time to play and share their opinions on this year's submissions, and to every single participant who submitted something.

Some work-in-progress shots and discussion of Linux Game Jam submissions can be found in the #linuxgamejam2018 hashtag on Twitter and Mastodon

I also created a guide to getting the most of participating in a jam, which was presented to participants before the event began, and I've created a Twitter List of Linux Game Jam 2018 participants who were readily identifiable from use of the #linuxgamejam2018 hashtag or who had a Twitter handle on their itch.io page.

More information on past, present and future Linux Game Jams can be found here, here and here (though further details on the 2019 event are not likely to become available until much closer to the start date).

[1] It's worth noting that creating things "from scratch" can be a rewarding and empowering experience. Beyond the submissions for this jam that were created from scratch, a few of my own games have been created from scratch for jams and jam-like events. There's definitely an additional degree of risk involved and experience/knowledge thresholds that make make creating games from scratch more accessible, but it's something I'm happy to personally recommend as a learning exercise if nothing else.

[2] Distributing dependencies with games is currently the de-facto "best practice" for shipping proprietary games on Linux. It is the approach that a majority of active porters (including myself, Ethan "flibitijibibo" Lee, and Ryan "icculus" Gordon use, and is the approach that Valve use with the Steam Runtime and their own games. Popping dependencies in their own folder and using a launcher script to set $LD_LIBRARY_PATH to that (preferrably with an optional launch argument for skipping setting that environment variable) is what I use and recommend to other developers, as this gives users more control over removing/replacing shipped dependencies in the (hopefully) unlikely event that environment or user-specific dependency maintenance might be needed in the future.

In an ideal world, everything is Free Software, and distro package maintainers will handle making sure that your game is compiled and distributed in a way that fits with users' environments, but for proprietary software distributed deps and $LD_LIBRARY_PATH feel like the best tools we currently have available.

If you've got any thoughts on or questions about this article, you can email me at cheese@cheesetalks.net.

This article was first published on the 14th of May 2018.