Cheese talks to: Linux using 7DFPS participants (originally published on

Last month, hundreds of developers from around the world came together to challenge themselves to make first person games in seven days for the 7DFPS game jam.

This year, I not only had the pleasure of participating again, but I also spent some time talking to other Linux using participants and wrote the article below, which was first published in December 2014 on as part one of a two part look at 7DFPS (part two listed all of the Linux compatible titles at the time of publishing and can be viewed here).

Last week, hundreds of game developers of all skill levels, from professional published developers through to people who've always dreamed of trying their hand at game development, dedicated 7 days to make first person games.

In this first part of our two part recap, we're going to take a look at why 7DFPS is important and hear from some Linux game developers. In part two, we've put together a list of all the titles currently supporting Linux to give you a head start on sifting through the list of entries.

About 7DFPS:

Starting with its inaugural event in 2012, 7DFPS is now in its third year, daring developers to make something awesome with nothing on the line but their own limitations in a no-rules, no winners, no-prizes challenge.

This year, IRC activity and the number of submitted games has been noticably lower than 2013, but this has in no way effected the breadth and depth of games to come out of the event, with a truly inspiring collection of games ranging from experiments and tech demos to proofs-of-concept and well polished experiences.

Of this year's 145 submissions, 59 offer some kind of Linux support (this figure includes several titles using browser based technologies that support Linux)[1].

As with last year, an overwhelming number of Linux supporting titles are using Unity, although we do see SDL, Pencil.Gaming, Flash, SFML, Godot, Colorado Game Library being used, as well as developers rolling their own tech from scratch. This year, Unity, Game Maker Studio (plus another engine that doesn't offer Linux support) offered developers trial keys for professional versions of their development environments[2].

A snapshot of the 7DFPS titles offering Linux builds at the time of writing, and the respective technologies used.

For the first time, 7DFPS games have been hosted on, giving developers the opportunity to have their games visible alongside thousands of others and providing pathways to monetisation should developers want to pursue that.

↑return to top↑

Why This Matters:

Last year, I wrote some thoughts on why 7DFPS might be of interest to Linux users, and I feel that that all still holds true:

"Sure these hurriedly made and for the most part underpolished games are nice, but why is this of interest to Linux gamers?" There are two reasons I've put this together. The first is to highlight and inspire people who're making or considering making games on Linux - the communities that have made F/OSS strong are all geared towards empowering people to be creators ahead of consumers, and that's something we shouldn't lose sight of as more software from other platforms is being published on Linux.

Just as importantly, it's worth putting what we have here into perspective. The majority of the titles that support Linux were developed by people on other platforms. That participants have taken time out of their crazy short schedules to provide Linux support for what aren't generally considered "serious projects" (even if it's via Unity) says something.

If it's to be a positive one, the future of Linux gaming won't be in ports of legacy titles for other platforms, it's in those who believe that Linux is a viable enough platform to warrant equal footing, and those people are worth recognising and celebrating! :D

With two 7DFPS events firmly in the past, we can now unequivocally say that 7DFPS has had an impact on Linux gaming. Titles like Probably Archery, Superhot, Receiver, Hunting Anubis and Catlateral Damage have gone on to be recognisable and/or anticipated games that are supporting Linux.

↑return to top↑

The Developers:

As with last year, I reached out to several Linux using developers to get some thoughts and perspectives on participating in 7DFPS.

Andy "Hero" Conrad, Nemoder and beansmyname were programmers on the SteamLUG 7DFPS game, a rewrite of the Haunt project (an asymmetric team based multiplayer survival game) from last year, moving away from the Source Engine to Godot. fanzyflani worked on a solo project, creating a real-time raytracing engine from scratch in C++ and Lua for a small non-euclidean maze game called pwnfps. ReactorScram worked on Phone Fighter, a first person fight to survive against never ending hordes of phones using the Colorado Game Library. Attitude[3] and myself (Cheese) worked on an unreleased first person text adventure written from scratch in C++[4].

What attracted you to 7DFPS?

Nemoder: It's great fun to work on projects with other Linux gamers.

Hero: My growing aspirations to make a game and the companionship I found in SteamLUG convinced me that 7dfps was a perfect opportunity to get involved in developing something with a team.

beansmyname: The opportunity to collaborate with fellow SteamLUG members on a community project.

fanzyflani: I think Sos mentioned it in #ludumdare and I liked the concept. The challenge of making an FPS in a short amount of time, something I have actually achieved in 24 hours in the past, appealed.

ReactorScram: I'd never made an FPS before and I also wanted to try re-learning Bullet Physics.

Attitude: Cheese

Cheese: Having participated in previous years, I was keen to be involved again. 7DFPS is the only game jam I currently participate in (it's hard to find time), and I really like the notion of a no-rules blank canvas.

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

Nemoder: Just personal projects. Only released game was the puzzle game Swapto.

Hero: The only other game I'd made, AntigoMe, was something I put together for a class in lieu of writing a longer paper. It is a choose-your-own-adventure computer game adaptation of an illustrated book, which is itself an adaptation of a Greek play. It was made using Panda3d and is so small that I don't usually count it as a game...

beansmyname: Haven't worked on anything that was published and never on something in 3D, but the combination of free time and a desire to learn something new led me to participate in the 7DFPS.

fanzyflani: Too many to count, there's a few on my page @ I also have a few QBasic games which are on a floppy disk somewhere.

ReactorScram: I've entered every Ludum Dare since LD26, so that's 5 games. I entered a few miniLDs too, I think that's another 2, or 3 if you count the filesharing "game". So 8 games? All very small-scale games that I made in 2 or 3 days.

I entered LD31 after 7DFPS, too.

Attitude: I have not worked on any titles in the past. In the 80s and 90s I did transcribe a number of games from a book.

Cheese: I've worked on a bunch of games, mostly community oriented stuff. After messing around in the 80s and 90s with smaller scale stuff, I worked on a couple of Half-Life 1 mods and contributed to the F/OSS game Neverball. Over the past few years, I've been splitting my attention between coordinating community projects like Bad Golf: Community Edition and SteamLUG's Haunt, working on 7DFPS games like FLAT, Dance and Winter's Wake, and giving time to some unannounced games.

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

Nemoder: My favorite part was working on the official concept art. I learned that I shouldn't show certain people concept art unless I want it to show up in the game. My biggest hurdle was not knowing the language we are coding in and not knowing how scenes should be setup in the engine.

Hero: I enjoyed every little triumph the team made throughout 7dfps. Many of us had minimal game development experience, so each task completed added to the feeling that "we are really doing this!" My knowledge was expanded regarding git and the Godot Engine, but I learned the most about how to plan the development of a game. Our biggest hurdles were probably inexperience and sometimes unclear communication, but everyone did a great job despite these.

beansmyname: Being part of a team that was all running Linux as their primary dev machines and getting practice with git. I learned that I know even less than what I thought I knew about the process of making a game.

fanzyflani: Favourite part was watching it take shape surprisingly quickly.

Biggest hurdles? Possibly getting rotation working with portals. An unfinished hurdle is getting the objects to render properly across portals. I shove them on a grid to speed things up.

What I've learnt is that pretty much anything made this decade can handle a simple realtime raytracer. Except for an Intel Atom. Those things suck.

ReactorScram: I got to try a new style of programming. The game is technically a Lua program which runs in the LuaJIT shell, but it links dynamically with my graphics library (Although I could have just as well used plain OpenGL) and it links with the game's Bullet-based physics library.

So most of the game ended up being the physics library, in C++, which does all the game logic, and then the Lua program does OpenGL and tells the physics when to run.

Attitude: Favorite part, hmmm, I am not sure. What did I learn? That I still have a lot to learn, and not to try to do to much at one sitting. Biggest hurdles, the adoption of a technology that was new to me, too close to the start.

Cheese: My favourite part of working on this year's game was the sense of empowerment I got when writing an OBJ loader and a simple renderer with mouselook controls. I'd often felt that I didn't want to get bogged down in doing stuff that low level, but the buzz from that "I can do this!" moment is pretty awesome.

So far as hurdles go, I (again) didn't manage to clear my plate properly and didn't see signs that the project was lagging severely behind by mid week. I switched gears from writing to focus on engine tech, but with the time remaining, I just wasn't able to pull everything together (it took me another two days to get something even vaguely presentable). This is definitely a project management failing on my part rather than any meaningful problems caused by other contributors. The takeaway here for me is to be more mindful when communication is low and not assume that things are on track.

Do you plan to continue developing your 7DFPS game?

Nemoder: I'm a man, I can code, if I have to, I guess.

Hero: We are continuing development on Haunt! It is far from finished in its current state and we are excited to create a complete experience. Development updates will be posted to

beansmyname: Yes.

fanzyflani: At some point. I'd like to get this to be a proper FPS.

ReactorScram: I don't have plans right now. The last time I tried to continue a jam game, I was not able to make changes to the core gameplay, and I ended up with a game that was technically impressive, had decent graphics and local multiplayer, but nobody actually wanted to play it.

Attitude: Very much so

Cheese: I haven't really stopped yet \o/

It's my hope that I'll be able to release a game and an engine that others can use to make their own "first person text adventures" in a similar style.

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

Nemoder: Start simple. If you are new to programming make a text game. If you are new to game design make a simple 2D game. It might not be what you really want but you'll learn enough to move onto bigger things later.

Hero: Specifically on Linux, game developers must be familiar with the tools available for their entire workflow. I say this because many developers will be accustom to Windows tools that might not be available for Linux, so alternatives must be used which may have different behaviors. For our team, this was not an issue as all of us use Linux as our primary operating system and the technology was entirely native.

fanzyflani: Congratulations on picking an OS that's not designed to make development look like only the rich and elite can do.

Learn VIM. It's great and it saves you so much time and so many keystrokes. It's not vital, but it's worth it. ^[:w^Mo

For more traditional languages and whatnot (such as C), install Wine and MinGW, and if you don't have a Windows box or VM, ask people to test. Most people run Windows, so you'll want that audience.

While we're at it, to most people, the OS isn't Windows, it's Firefox or Chrome or whatever. For "traditional languages", learn how to use emscripten.

Easiest way to get started with C or C++ is to learn how to compile a pre-existing game, then modify it to do things. I did that with Rocks 'n' Diamonds.

Finally, if you hate Winsock as much as I do, and you need to use good ol' fashioned Berkeley sockets, and there's a chance you'll want it to run on Windows, use SDL_net.

I could go on but I think that's enough for now.

ReactorScram: Please use OpenGL 2 so I can run it on my old laptop.

If you're making a 2D game, LOVE is a really good option because you can run the same .love archive on any OS, and it will be hardware-accelerated.

Attitude: Start small. It is easy when you do not know a lot, to have grand plans, and try to make the next big thing. This is unrealistic. To be able to complete a game in seven days, requires that you have a lot of skills before starting. Code lots. The only way to get better at coding is to code.

Cheese: I feel like my advice from last year still holds true: get yourself familiar with your workflows before you start so that you can know what limitations or hurdles you might face, and try to design your game and its systems with a modular approach that lets you get your bare minimum up and happening first that you can gain the insight you need to iterate and improve.

↑return to top↑

Cheese's Favourites

So far, my favourites are:

These flying oriented games are also super awesome (I have stars in my eyes for flying games):

And to close out, I see a lot of good potential in these titles:

A note from cheese

A note from Cheese

Thanks for reading!

Please do take the time to check out some of the games listed on the 7DFPS game list on If you're looking for somewhere to start, I put together an collection of Linux supporting titles to accompany this article when I first wrote it.

I've also put together a Twitter list of 7DFPS devs supporting Linux, which can be found here. If you know of anybody who's not on there, but should be, let me know!

[1] The title counts includes Phone Fighter, a game created for the challenge, but not submitted to the official games list by a Linux user.

As seen with titles like Superhot and Probably Archery, the number of Linux supporting titles may increase over time as developers improve their games and expand platform support. In fact, South East Games (developers of Probably Archery) alreay have their 2014 7DFPS game Paint the Town Red up on Steam Greenlight with Linux support offered.

[2] More details of engine developers supporting 7DFPS can be found on the 7DFPS info post.

[3] Attitude is my Dad, who after contributing a small amount of prototype code to Dance in 2013 was excited to be more involved in a project this year.

[4] For better or worse, I didn't get my project presentable in time for the end of 7DFPS. I've written a little about it here and here, and have been continuing work in the hopes of having a more polished game worthy of a proper release next year. I also took the learning I'd gained from working on my 7DFPS game and put together a tiny example game called Hover Drive for a LUG talk (sources and slideshow are available on GitHub).

This article was first published on the 11th of December on as the first part of a two part look at 7DFPS from a Linux perspective.