Linux

by Ron Gilbert
Jan 15, 2015

What flavor of desktop Linux should I use for the initial port of Thimbleweed Park? I realize this is like asking what religion is the right one, and in some ways it might even be a thornier and more contentious issue, but I am fearless in the face of controversy. I ask the questions everyone else is afraid to ask.

I use CMake to generate the Xcode and VS projects, so what IDE should I use on Linux? Or just have CMake build make files on Linux? I tend to spend 99% of my time on the Mac in Xcode, switching to Windows just to do a build or for compatibility issues. Windows and Linux won't be platforms I do a lot of core work on.

I'm currently using SDL for window creation and input and I don't see any reason to switch. It runs on Linux and works pretty well on the Mac and Windows. I don't use any of SDL's rendering, I only use it to create the windows and then get a context back and do everything in OpenGL/DX from that point on.

OK, that's a lie. I do use their font lib because I don't want to write font rendering code. Every OS seems to do it different, and it's nice to have it consistent across devices.

I'm no stranger to Linux as I run Ubuntu on all my servers, but those are all headless machines I SSH into and I've only dabbled in the desk top a few times.

I'l probably run it as VM on my Mac using Parallels, at last for a while, then I'll get a dedicated machine.

I figure it might be better to get the core of my engine running on Linux early on.

- Ron

Thomas Arnold - Jan 15, 2015 at 12:58

Great to hear.
Just target the SteamOS SDK, it is the only stable thing you will find in Linux land.
I would use Ubuntu and probably the LTS(14.04) version, the others are quite buggy nowadays, because Canonical is focusing on their phone stuff and don't care for the non-LTS versions desktop that much anymore and they are only supported for 9 months not 5 years like the long term support versions.

Marcelo Staudt - Jan 15, 2015 at 19:38

In my experience SteamOS was far from stable.

Kai - Jan 15, 2015 at 13:00

At work I mainly use Fedora Linux 21 with the KDE desktop. I tried the Gnome 3 desktop a couple of times but just could not get used to it (Gnome 3 is the default desktop for Fedore, but there is an ISO that uses KDE as default. It's called the "Fedora KDE spin" if you want to give it a try). Good hardware support, has been rock solid for me, eye candy can be configured. For coding I mainly use the Netbeans IDE, it's primarily a Java IDE but there's a C/C++ plugin that handles Makefile-based projects. You may want to see if this works for you. The package manager is Yum, which is essentially the same as apt-get.

Lennart - Jan 15, 2015 at 13:03

I guess Ubuntu is the obvious choice. It comes with both sdl1.2 and sdl2. For test builds you can dynamically link to the system libraries. For the final release you probably want to ship your own version of the SDL libraries. Most games do.
Most game that do have problems, have problems with audio. That is a mess on linux that slowly gets sorted out. Most current distributions use pulseaudio, but you probably want to target alsa, as pulseaudio has an alsa compatibility layer.
Linux tends to have trouble adjusting to the correct Monitor resolution. It's probably best not to switch to your game resolution, but instead scale to the desktop resolution to avoid trouble.

MS_abuse - Jan 16, 2015 at 01:12

Hey Lenny, how is systemd coming along?

Lester - Jan 21, 2015 at 14:50

+1 for not switching resolutions

Gabriel - Jan 15, 2015 at 13:12

Qt Creator and Jetbrains' CLion have CMake support, I've had mixed luck with them but I recommend you take them for a spin. Kubuntu LTS and KDevelop are what I use in particular, but not as a full project management solution (just to link to GDB and step through code).
As to which Linux to target...I would focus on the Steam runtime environment, maybe the latest Ubuntu LTS, any more than that is probably going to stretch you thin (also considering the varying degrees of performance and annoyance you'll get out of Intel/Nvidia/AMD based graphics)

Pietz - Jan 16, 2015 at 12:07

Ron, Qt could be a nice choice for programming the core app, which is starting up the game. The benefit is ONE code and it runs nerarly automatically on Linux, Windows, Mac, and also Android and iOS. Then, in that Qt application you can execute your engine code. Qt Creator is a nice IDE and comes on all three desktop platforms. One code, one IDE ... if you like, just an idea.

Kayamon - Jan 16, 2015 at 21:14

Qt Creator is about the only sane choice for IDE on Linux, even if you're not using Qt.

Marcelo Ellmann - Jan 15, 2015 at 13:19

Close your source for the engine/assets and hand us the source for the executable so we can build and run anywhere we want.

Lennart - Jan 15, 2015 at 13:24

I didn't know about the SteamSDK. That's probably best then. As for the distribution. Use the one where you're comfortable with the package manager. Marcelo Ellmanns suggestion is also something you might consider. It ensures, the game will always run as long as x86 is still around.

JamesB - Jan 15, 2015 at 13:38

I've not used any IDEs on Linux aside from Emacs+makefile. The makefile support for CMake is great as this is one of the first generators supported by CMake.

As far as distro to use, for a cross platform project I work on we try to find the oldest version of Linux that supports what we need then statically link against libstdc++ and glibc (use -static-libstdc++ -static-libgcc with GCC). This gets more tricky if you have lots of libraries you depend on (you could recompile those projects to add these flags, though). I would probably select a LTS version of Ubuntu as mentioned, though SteamOS seems an intriguing choice.

I know Parallels for Mac had built in support for Ubuntu (it was presented as an option when creating virtual machines), but I haven't used it personally.

FredP - Jan 15, 2015 at 13:51

Ubuntu! Ubuntu! Ubuntu! please ;)

MattG - Jan 15, 2015 at 13:53

I would probably say Ubuntu. You will probably get the most reach with that. Probably next is Debian or Fedora. I think if you still with any of the main distros you won't be in trouble.

Karl - Jan 15, 2015 at 13:55

Maybe its really to late now, but why not code the game in HTML5? Wouldn't this be possible? Than the game would be run in every browser?

Lennart - Jan 15, 2015 at 13:59

This would make not using a walkthrough figuratively impossible.

Ron Gilbert ✓ - Jan 15, 2015 at 14:06

There is too much HTML can't do and it's a pain to work in and browser compatibly is horrible, plus it won't work on consoles or handhelds like the DS or Vita. Plus you have to remain connected, no playing on airplanes. I realize there are ways a round this, but I enjoy programming in c/c++ and I'm doing this game because it's fun for me to work on.

Gabriel - Jan 15, 2015 at 15:13

Once the project is done and you get bored of counting your millions, if you are building on top of SDL2 and have an OpenGL ES 2 graphics backend (which you must have since you are doing mobile), then you can probably spend a rainy afternoon trying to run the game on a browser with emscripten...it should work without too much pain (SDL2 also has Native Client support, though it's less mature, and it's more complex to get all the pieces working together).

Ron Gilbert ✓ - Jan 15, 2015 at 15:16

I don't use SDL on iOS or Android, just for Win/Mac/Linux. Window management on those platforms is pretty simple.

Nicolas Noble - Jan 15, 2015 at 13:55

Target SteamOS. That'll basically target Debian, Ubuntu and SteamOS.

Oldtaku - Jan 15, 2015 at 14:14

Ditto SteamOS. It's the gaming Linux. And I guess you probably won't have any trouble getting on Steam, but it would certainly help.

Christopher - Jan 15, 2015 at 14:25

For development, I recommend QtCreator, even when not using Qt.

I've worked with non-Qt CMake-based applications in QtCreator for several years, and I haven't found anything better on Linux. Currently I'm giving VS in Windows a go, and I miss the snappyness and the precise code-completion engine of QtCreator.

Stefano - Jan 15, 2015 at 14:44

You should target Ubuntu (trying not to use some single graphic toolkit) and then leave the packaging for other distros to the community.
If you'll distribute it via Steam, it is packaged but not officially supported on various other distributions.

Soong - Jan 15, 2015 at 14:44

If you absolutely need to pick a distribution, then I would go with Debian.  Many other distributions are based on it (such as SteamOS and Ubuntu), so you get a pretty wide range from targeting Debian.  Debian also tends to be conservative when it comes to including packages such as libraries so if something runs on Debian, chances are it is compatible with a whole range of non-Debian based distributions with newer libraries.  Then again, I guess you will use statically linked libraries anyway.

Either way, I don't quite see the need to pick a specific distribution.  As long as it doesn't require any bleeding-edge or totally outdated libraries, everything should be fine.  The best solution would of course be to release some code under a free software license so it can be adapted to future changes (like Marcelo Ellmann already suggested).  I don't know if you're willing to do that, but releasing the code of the VM/interpreter that will then run your scripting language would be great!  Otherwise people will eventually have to reverse engineer it just like SCUMM/ScummVM. :-)

As for the IDE:  I use Netbeans, but I would say that's mainly a matter of preference.  I like your suggestion of using CMake to build makefiles.

Brian Ruff - Jan 15, 2015 at 14:47

Based on popularity alone:

Last 6 months
1 Mint 2377>
2 Ubuntu 1854>
3 Debian 1589<
4 openSUSE 1403>
5 Fedora 1314=
6 Mageia 1128<
7 CentOS 1126<
8 Arch 1048=
9 elementary 939<
10 Zorin

Source:
http://distrowatch.com/dwres.php?resource=popularity

Roberto - Jan 21, 2015 at 01:52

Distrwatch stats are a joke. Wikimedia shows some diffesent stats (Ubuntu 920 M, Mint 6.9 M):

Breakdown per platform for Mac and Linux
Linux Android 28,394 M 14.06%
Mac Intel 10,656 M 5.28%
Linux Other 1,507 M 0.75%
Linux Ubuntu 920 M 0.46%
Mac PowerPC 47.1 M 0.02%
Linux SUSE 8.2 M 0.00%
Linux Mint 6.9 M 0.00%
Linux Fedora 6.8 M 0.00%
Linux Red Hat 5.1 M 0.00%
Linux Debian 4 M 0.00%
Linux Mandriva 3.4 M 0.00%
Linux Mips 3.3 M 0.00%
Linux Gentoo 2.2 M 0.00%
Linux Arch 1 M 0.00%
Linux CentOS 963 k 0.00%
Linux Epiphany 725 k 0.00%
Linux Kubuntu 217 k 0.00%
Linux PCLinuxOS 102 k 0.00%
Linux Slackware 44 k 0.00%
Linux Motor 31 k 0.00%
Linux Oracle 31 k 0.00%
Linux openSUSE 31 k 0.00%
Linux Xubuntu 31 k 0.00%

Source: https://stats.wikimedia.org/wikimedia/squids/SquidReportOperatingSystems.htm

:wq - Jan 15, 2015 at 14:57

Vi and Makefiles

David Cruz - Jan 15, 2015 at 15:45

I will certainly go to any debian based. Either SteamOS or Ubuntu are of this sort.
Seeing that valve release it's client to Ubuntu and has it's steamOS also out based on debian, this seems like obvious choices for better support for gaming in Linux.

Daniel - Jan 15, 2015 at 16:01

I use Ubuntu both at home + work; would be happy if it was supported.

General advice: There aren't that many commercial desktop Linux apps; long-term I'd try to support whatever they're supporting.
Examples:
- Steam client: deb packages. They only mention Ubuntu by name.
- Google Chrome: Debian/Ubuntu/Fedora/openSUSE (which I think translates into deb + rpm packages)
- LibreOffice / OpenOffice: deb + rpm packages

Pedram - Jan 15, 2015 at 16:13

Which distro:

My answer would be to go with Ubuntu or Mint. As you can see in distrowatch, they are the most popular ones. Fedora is more enterprise oriented than the Debian based. My impression is, if anyone who is a "casual computer enthusiast", who would give Linux in general a try, he/she will be recommended to try Ubuntu/Mint. Fedora is more enterprise stuff in my opinion.

Which IDE:

I think Qt Creator is great and comes the closest to VS (many people say it supersedes it). It can handle CMake files very easily. And if you get used to it, you open up the opportunity to also use this on Windows, because it is inherently multi-platform (I do not dare to suggest replacing XCode, because you seem to be quite fond of it ;-)

One request:

One honest request (please, please): whichever distro you choose, please use the libraries that come with the distro. This is the single biggest advantage of Linux altogether: from the version of the distro (e.g. Ubuntu 12.04 or 14.04), you know which version of the libs are being maintained (e.g. libsdl2.0.2). Please don't dump a on us, which is supposedly self-contained. Make a .deb, which has dependencies to the packages in the distro and e.g. in Ubuntu we can go:

dpkg -i thimbleweed1.0.deb
apt-get install -f
dpkg -i thimbleweed1.0.deb

Lennart - Jan 15, 2015 at 16:30

You do realize that shipping your own libraries usually increases compatibility. After all, should they brake, you can always delete them and use the system ones instead. Otherwise you have to hunt for the right version.

Pedram - Jan 15, 2015 at 16:58

Hello Lennart,

sorry for not getting your point. If for example you'd link boost and you want to support Ubuntu 14.04 you can make your .deb depend on version 1.54 or 1.55 as both are supported. You will depend on the specific version, so even if a newer version is introduced, the old one will not go away. In Linux it is not a problem to have many versions of one lib in parallel (it is called .dll hell and not .so hell ;-)

Lennart - Jan 15, 2015 at 17:19

Yes, but if ten years pass, no distribution will ship this old library. Yet, if you ship your own boost, it will just be there. I agree that linking to the system libraries is best for open source software that you can always recompile against a newer version. But for closes source software that option isn't there so you want to make the breaking point as little as possible. Best only to depend on libgl and libegl for example.

Pedram - Jan 15, 2015 at 16:16

P.S.: Qt Creator is easy to try

apt-get install qtcreator

Manoel - Jan 15, 2015 at 16:19

I think Linux From Scratch should be a good choice... ;)

Just jocking

keith - Jan 15, 2015 at 16:25

I think SteamOS and Ubuntu are the two logical targets for Linux.

Colin Doncaster - Jan 15, 2015 at 16:40

Qt Creator is a great cross platform option - I find anything Java based is just too slow/doesn't feel nimble enough. We actually use CMake to create Makefiles on both Linux and OSX (out of source) and then tell Qt Creator where to build/run (and make -j x for concurrent builds) as it seems quicker to iterate on CMakefile.txt changes (ie. you don't need to refresh XCode) and makes jumping between platforms a little more comfortable.

Of course, XCode is way sexier - especially if you have build bots set up.

Mau - Jan 15, 2015 at 16:50

I should scream Slackware!

I know is not a smart decision for a commercial software in Linux but when you release the game and I will be forced to install 2451 libraries I can say that I asked for Slackware and you ignore me.

Choose anyone, I am already used to suffer.

Davide - Jan 15, 2015 at 17:09

I suggest to not use an IDE on linux, just sync with the updated svn/git repository (or use a script to "scp")
with the last version on a linux machine and "cmake". A simple script to update then compile could help wasting time (not so much btw)).
Just develop on your prefered machine/OS/IDE. In my exp. compatibility problems between mac and linux are way fewer
than mac / win.

Test the build on Ubuntu (should be enough for Mint, and quite compatible with Debian), Fedora (enough for CentOS) both using
proprietary drivers than pre-installed pain-in-the-ass-to-disinstall-for-the-average-gamer-yet-low-performance open source drivers like nouveau for Nvidia cards.
I don't believe SteamOS is very used, and still beta.

Tin Tvrtković - Jan 15, 2015 at 17:40

I'm a developer as well, but not in the game industry. I use the default Ubuntu pretty much exclusively both at home and at work. I'd suggest the latest release (14.10, Utopic) or the LTS (14.04, Trusty). If you go with Utopic, you'll probably get asked to upgrade during the game's development since it's only supported for 9 months, so maybe it's worth it to go with the LTS to avoid the hassle.

I guess the LTS could be less buggy, but in my experience they're about the same.

Ubuntu by default uses the Unity desktop environment, which some people really dislike (not me, I like it). Mint uses a different desktop environment, Cinnamon, which is pretty popular nowadays. (Both can use others as well...) That's the big difference, the default Mint is a derivative of Ubuntu, just like Ubuntu is a derivative of Debian.

As for an IDE, I personally use JetBrains products myself (IntelliJ Idea, PyCharm) for my work and recommend them. They have a C/C++ IDE as well, https://www.jetbrains.com/clion/, but I see it's still in early access (beta I guess) and it's not free, and I've not used it so no direct experience. I'm not a stranger to the traditional editors - I maintain and use my own Vim package manager - but honestly I'm not sure I'd recommend Vim or Emacs nowadays if you can use a great IDE out of the box, like JetBrains offers.

I'd actually be interested in what you end up going with, tool-wise. I'm a contributor of Ubuntu Make (https://github.com/ubuntu/ubuntu-make), which is a project to make setting up a development environment on Ubuntu easier. It'd be interesting to get a real game developer's perspective and maybe make the experience better in the future.

Good luck with making the game, and thanks for supporting Linux!

-A Backer

Fuzzy Box - Jan 16, 2015 at 06:39

I understand why not recommending Vim or Emacs, but just have to comment that at least Emacs is quite capable for "modern" software development. I'm sure Vim is also, just a different philosophy there. There's lots of reasons why people think they are not. I'm not using Vim so I can only speak for Emacs. I think the main reason is that you don't get intellisense, project management, intelligent code/project browsing etc. straight out the box, you have to find those yourself from different places.
  Some really good things can be hard to find. Couple of weeks ago I found RTags - a C/C++ indexer package/plugin using clang - when someone commented it on some forum... so yeah. But it's great and now I have true intellisense completion and intelligent code browsing, instead of regex parser/indexer.  I also have instant error checking with combination of RTags and Flycheck and much more.
  At least FSF people don't want to promote any clang-stuff so that is one reason for hard to find things. I hope FSF gets GCC Abstract Symbol Tree politics sorted out so we can have intelligent code indexing with GCC too. I don't use refactoring but that's should be possible with clang too.
  Sometimes I try to switch to "modern" IDE. I've tried QtCreator, KDevelop, NetBeans, Code::Blocks, Eclipse but always get frustrated when I can't change the mechanics of the IDE myself, which I can do easily in Emacs with Elisp. I've written little Elisp programs for Emacs that allow me to compile, run visual debugger, run Valgrind memory checks, run tests, run profiler etc. The only IDE I've used and liked was Visual Studio in school, but I don't have Windows and I have all the things I liked in Visual Studio now in my Emacs.
  So, sorry for the long post. I don't think I would recommend Emacs or Vim as the only option for anyone - you get everything done happily with KDevelop or QtCreator or something else I'm sure. I just want to say that Vim and Emacs are really powerful tools and if someone is interested using those she/he shouldn't think these programs can't do things that "modern" IDEs can because there's lots of things these editors/environments are capable of.

Marko - Jan 15, 2015 at 18:45

Having worked for one of the two major commercial Linux distributors, I would definitively like to encourage you to target Debian GNU/Linux as it is one of the most conservative distros. If you get the engine ported to Debian, it will definitively work on all its 130+ active derivatives (including Ubuntu, Mint, SteamOS), but as the majority of other desktop distributions are slightly quicker in adopting newer packages, it is pretty much guaranteed that your stuff will run on these, too.

Mattias Cedervall - Jan 15, 2015 at 21:52

Raspberry.

Meee - Mar 04, 2016 at 07:09

Yes, Raspberry!

Ben Widawsky - Jan 15, 2015 at 23:58

Only because I didn't see a similar response...

I work on Linux graphics drivers, and I use Arch.

I recommend Arch. I've been using it for almost 4 years, after about 8 years on Gentoo. I think rolling distros make life so much easier, and the Arch devs do a really great job of keeping all the important packages up to date. It didn't get totally rick-rolled by the insane systemd debate. The LiveUSB ISO is easily the best of the modern era. Pacman is the least disgusting of all the package managers I'm familiar with. There is a great community of people who publish "out of tree" packages to the AUR.

Do it. And if you find GL bugs on Intel hardware, send them to me :P

Matthias B - Jan 16, 2015 at 00:13

Please do not force full screen. Allow me to play in windowed mode, but with scaling because I have a 4K monitor.

Orcan Ogetbil - Jan 16, 2015 at 00:38

Ubuntu and Mint are considered adequate for enthusiasts, and they do a good job to address a large user base. However, for serious development, cool kids use a real (!) distro, like Debian or Fedora. Of course, if you want to go totally bad-ass and shut everyone up, Gentoo, Arch or Slackware is the way to go.

As for the DE, it is a matter of taste. I don't like the default configuration of any of the DEs out there. Fortunately, KDE offers sufficient flexibility and configuration options to tweak thing the way I want. Most consider this not very significant, but organizing the layout of the applications to minimize my hand (mouse) movement and click count optimizes my productivity a lot.

For development... Eclipse has intellisense and syntax highlighting for pretty much all languages. You can hook up external builders like cmake, scons, autohell, waf, etc. to it with minimal effort. That said, emacs is my primary choice for development. With sufficient dedication and stubbornness, you can do _anything_ in emacs. Some say it can even make you coffee but I haven't tried that yet. But wait... You said you don't like LUA. What can we do to convert you?

Cheeseness - Jan 16, 2015 at 01:35

I wouldn't bother with an IDE for Linux unless there's a debugger that you want to do that's provided by one. If you're already using CMake, build it with CMake.

SteamOS probably isn't worth targeting, but building against the Steam Runtime would probably be worthwhile (that's the collection of libraries that ship with Steam that Steam includes in the LD_LIBRARY_PATH when launching games). Most of the time when I ship stuff, I build on the current stable Debian or on my current desktop (usually the latest or next to latest Fedora release), but I make sure to get people on as many distros as I can to test and help me identify any packaging/dependency issues.

Rom - Jan 16, 2015 at 01:52

Linux Mint

Pascal - Jan 16, 2015 at 03:06

+1 for QtCreator or CLion. They're easy and fast to configure - the right tools for the simple task (update sources, do just one Linux build, shutdown machine). Both support CMake.

Talking of distros, I'd say Ubuntu and Fedora. Linux Mint is managed with Ubuntu. We Arch and Gentoo users will figure out how to run it ourselves.

enthusi - Jan 16, 2015 at 03:15

SDL is by far the best option in my opinion as well.
If it runs in Ubuntu (or Debian) it is MOST likely to either run out of the box on the others or at least the cummunity of those more obscure distros will manage to get it to run. As this will be an ace game of course, they will try very hard, too.
That being said: you will attract lots of modern geeks (and me) if you offer binaries for linux/ARM as well ;-)

enthusi - Jan 16, 2015 at 03:17

PS: I would personally donate you a raspberry pi or more powerful machine to just run your make on that in parallel to the other linux build.

Brian - Jan 16, 2015 at 14:30

It would be so cool to play this on a raspberry pi.

KernelPanic - Jan 16, 2015 at 03:42

Debian! (I hate Ubuntu :-P)

Mathias - Jan 16, 2015 at 03:43

Blasphemy!

Choosing your Linux is *far* more important than your religion. ;-)

Alessander - Jan 16, 2015 at 04:39

I use Kubuntu 14.10. Not taking in consideration your development preferences, maybe it makes sense to target the same Linux distributions supported by GOG or Steam. I hope SteamOS becomes a default choice for gaming on Linux, but I don't know if it is already stable enough...

GOG supports "Ubuntu and Mint, in their current and future LTS editions" [1], while Steam seems to support "Ubuntu 12.04 LTS or 12.10 with the Unity, Gnome, or KDE desktop" [2].

[1] http://www.gog.com/news/gogcom_now_supports_linux
[2] https://support.steampowered.com/kb_article.php?ref=1504-QHXN-8366&l=English

tante - Jan 16, 2015 at 05:28

If you are familiar with Ubuntu already, it's probably not a bad choice to build TP on. One issue with Ubuntu is that they have a bunch of things running no other distribution uses, but since all you use is SDL it really shouldn't matter too much. Since still many companies just deploy to Ubuntu (Valve with steam for example), many other distros have found ways to at least stay compatible enough to get stuff running.

I don't know which Language you use to develop TP but if it's C++ you might want to check out the QT creator (even if you don't use the QT toolkit). It integrates with CMake which should smooth things over for you. Kdevelop works well for C++ as well. (take it with a grain of salt, I am not really a big C++ person)

Thomas Arnold - Jan 16, 2015 at 06:08

BTW: If you are looking for really unique features in your C++-IDE you should have a look at Kdevelop. Sadly the version 5 isn't ready yet. But 4.6 or 4.7 work just fine.

Jammet - Jan 16, 2015 at 07:06

Make it a static built, as a tarball by default, so it could be used ANYwhere in any distribution. Individual package distribution managers will take care of the rest, and make sure it gets installed in the proper place, and the binaries and icons for the desktop linked in the proper places.

hihp - Jan 16, 2015 at 07:21

Just to chime in: Best would be Debian, since that should give you compatibility with Ubuntu, and I would still say that even though Mint seems to be coming up, Ubuntu is the easiest approach for many new Linux users.

Therefore: Debian -> Ubuntu is my suggestion.

Iron Curtain - Jan 16, 2015 at 11:32

This was the first result I got when I googled "Are Debian Applications compatible with Mint?":

http://ubuntuforums.org/showthread.php?t=2224686

It would seem like they are. Maybe I'm missing something and there are layers of depth that separate Debian from Ubuntu from Mint. Obviously you'll need to test the game on everything (that's what betas are for), but is it safe to assume that once a piece of software is compatible with Debian it would be compatible with Mint too?

I'm not asking this question to Ron, but to any of the other peeps who know a thing or two about Linux and Distro-forking.

some dude - Jan 16, 2015 at 09:20

Well... which Linux will run on my 8086 with Hercules Monochrome?

Akos - Jan 16, 2015 at 10:17

I am 100% with Marcelo Ellman: open source the executable (or more abstractly: some sort of wrapper layer). This way each distribution can maintain its own version for as long as they want to, and everyone can pop in the assets/data_files/whatever.

If this is not possible, a second best (but much worse) solution is to ship your own libraries.

BTW I use Gentoo, so I have no love for any Ubuntu version that you can use for a few years then becomes unsupported because of new lib versions.

Eric - Jan 16, 2015 at 10:28

Hello Ron,

that sounds a lot like "I set up a machine of distro X and then build Thimbleweed Park there, so that will decide my port". If that is the case, I suggest you set up a private instance of the Open Build Service (OBS). Although it was originally an openSUSE project, you can build packages for a lot of distributions with it, not just openSUSE and not just RPM-based distros. Also, it neatly handles different architectures (think i686 vs. x86_64 vs. arm7l). Setting it up might require a day or so, but it pays off. All you need is the build recipe (e.g., a spec file) for the package manager.

HTH
Eric

DuphusDigital - Jan 16, 2015 at 11:18

Ron,

I would recommend Ubuntu, if you haven't used Linux all that much. If you need someone to, I can build it and port it for you. I would work for a copy and nothing else.

~DuphusDigital

Fuzzy Box - Jan 16, 2015 at 14:33

I'm using Arch Linux and it's great for me, but I think you should choose Debian as a main target. It's traditional, basic, open, popular and well maintained distribution. I'm no Linux expert but I think after Debian it should be quite easy to install on any Linux distro.

JD - Jan 16, 2015 at 14:54

Distribution:
- Ubuntu is very common, but I dislike Canonical very much. They always try to do things differently than other distributions (Wayland vs. Mir, Unity, giving little back to the projects)

- Linux Mint could be an alternative.

- SteamOS is targeted for gaming, but still has a low userbase and is only developed by Valve so things can change quickly and don't have to be compatible.

- Debian is the base for SteamOS, but has a slow development cycle.

- My usual choice is openSUSE. If you need professional support you can get it (community is big enough, or by paying for Enterprise Desktop). It quickly adopts new standards and ideas, while still being stable and gives back to the kernel, etc. Finally it shipes my favourite desktop enviroment by default (KDE)

IDE: As enough people pointed out: Qt Creator is stable, feature-rich, cross-platform, supports CMake and is backed by a huge community where cross-platform development (even iOS, Android etc) is deemed essential.

JD - Jan 16, 2015 at 15:32

What I forgot to say: Generally the distribution shouldn't matter as the compiler usually stays the same (e.g. gcc or clang) and it should work on different distributions. But support matters when you are developing something you want to earn money with. You propably don't want to fiddle around with issues yourself and it seems as if Canonical's/Ubuntu's professional support isn't that good. Especially when developing/building/packaging for other distributions, e.g. Redhat, Arch, openSUSE.
openSUSE on the other hand has build up an entire build service (https://en.opensuse.org/openSUSE:Build_Service) including Ubuntu, Debian, Redhat, even on PowerPC if that's important. And even 24/7 priority support is still affordable.

Yuri Brunetto - Jan 16, 2015 at 19:50

Perhaps you can use an ArchLinux. Chakra is great!
http://chakraos.org/

DNSGeek - Jan 16, 2015 at 20:00

If you want to target the APIs and frameworks, etc that the average Linux use will be using in a year (when you release), use Fedora 21 now.

Ralf - Jan 17, 2015 at 08:22

It should not matter at all. Fedore, openSUSE and ubuntu all feature very recent versions of the named gaming-related libraries and / or provide them through well-known mechanisms like Open Build Service (https://build.opensuse.org) for old-but-recent OS releases.

Rob - Jan 17, 2015 at 11:05

I would be very happy if it at least runs great on Kubuntu, so testing on any recent Debian based distro should be fine. For testing packaging you should probably focus on both .deb and .rpm bases.

For development QTCreator is great. We use it on Ubuntu 12.04 LTS in combination with CMake (and our own sauce).

Li - Jan 17, 2015 at 13:44

Hey Ron, sorry my question doesn't pertain to the topic. I was wondering about the font you're using in TWP and on the website, too. Is it a commercial free font? Our small studio is developing an adventure game that's really an homage to games you guys were making in the 90s, and we really want a great font to go with it. Of course, buying it wouldn't be a problem either, just wanna know what it's called, if at all possible. Thanks and good luck with development! (Not that you need it, heh).

Ron Gilbert ✓ - Jan 17, 2015 at 17:24

The font can be found here: http://style64.org/c64-truetype/license

I won't be able to use it in the final game due to licensing issues, plus it's lacking accented characters. It's nice because it's a C64 font, but it's proportionally spaced.

Li - Jan 18, 2015 at 07:49

Thanks Ron!

chriskringel - Jan 18, 2015 at 16:19

Basically there is not much difference between (K/X/L/etc.) Ubuntu 14.04 and Linux Mint 17.0 and 17.1 (actually: binary compatible to Ubuntu) and Debian 8 and SteamOS (mixture of Debian 7 wheezy with updates and Debian 8 jessie). I run all of these distributions and versions and libraries are pretty much comparable.

If we look at Distrowatch.com (which is not represantive though) we see the most HPD points on these distributions:
(last 12 months)
1. Mint (2858 points)
2. Ubuntu (2011 points)
3. Debian (1665 points)
12. Lubuntu (752 points)
20. Xubuntu (556 points)
30. SteamOS (431 points)
32. Kubuntu (399 points)
33. Ubuntu GNOME (388 points)
35. KNOPPIX (364 points)

a total of 9424 H.P.D. points on distrowatch.com, which is like really a lot.

chriskringel - Jan 18, 2015 at 16:26

Another maybe more important question would be which OpenGL version should be used.
For the free drivers e.g. (Intel HD 4000 and Intel HD 4400) support for OpenGL 3.3 (glxinfo showing "OpenGL core profile: 3.3" is not yet in all pre-installed versions of Mesa.) But going for OpenGL 2.1, OpenGLES 2.x and also OpenGL 3.0 there should be no problems with really *most* drivers.

Rene Schickbauer - Jan 19, 2015 at 01:11

Well, i developed an SDL based Jump'n'Run game a few years ago[1]. Mostly used vim as my editor, since i couldn't find an IDE that satisfied me on Linux. (mostly developed on OSX back in the day). Also used CMake on Linux to build, worked quite well.

The *more important* part was to compile in 32 Bit and 64 Bit as well as both on Little and Big Endian. This found a LOT of otherwise rather hidden bugs and cross-plattform incompatibilities.

I fully support the comments above about releasing the game engine source and keeping the commercial rights for the game content (similar to what has been done to id's Doom 2). It's impossible from keeping geeks circumventing your copy protection, so why not just USE the great geekness potential out there to port the game engine to every plattform available.

[1] It's called BlinkenSisters. I'm not the maintainer anymore and haven't played the game in a long time. My priorities shifted. It might still be available online, just Google for it.

Sam - Jan 19, 2015 at 04:18

First world's problem...Ron...=)

I use Ogre3d (and SDL in the past) and I have a macbook. So you can figure out that I had to use Cmake and others.

After all I decided to install windows onto my macbook in bootcamp.. VM was not working so good. Mouse integration did not work as well as I expected.

Cheers!

Zak - Jan 19, 2015 at 05:25

I don't care for Linux. Just make a port of original Zak mckracken and the alien mindbenders for iOS. Please with nuts and cherries.

Mau - Jan 19, 2015 at 09:15

Get the original Zak and install the ScummVM for IOS. No need to waste developer time on games that already been ported to a lot of O.S.

el - Jan 20, 2015 at 02:15

debian or arch, emacs, ninja build using ninja_syntax.py

Heiko - Jan 20, 2015 at 02:17

I have cross platform and Linux development experience of about 20 years now and i don't understand your question: You should use what ever flavor of desktop linux you want, but get yourself some current linux that uses older software, like centos 6 or debian 7 (could be even on a virtual machine) for making the final build. Compile everything wich license allows it in statically, and only link LGPL stuff dynamically. That way you ensure it runs on as many Linux versions as possible, especially if you use SDL... if you make the final build on current Ubuntu beta, a lot of Linux users will not be able to run it, but this doesn't mean you can't use current Ubuntu beta for software development, just make the final build on centos 6 or debian 7.

Stoffe - Jan 20, 2015 at 10:56

Latest Ubuntu, generate Make files is just fine when you are not going to develop on the machine, hell if not for testing you could probably use one of your headless ones. ;) Sounds like you're gonna be in a terminal anyway except for testing the actual game.

Compile statically to get the SDL of your choice into final binary. Don't know if there is anything extra needed to support Steam, may be worth checking out.

The only really important part is the one you're getting right, right now: develop/test for the platform from the start, doing that it's usually not a problem, it's porting afterwards that may be tough.

Ploe - Jan 20, 2015 at 14:46

I'd recommend a distro running Gnome (Fedora, Debian, etc) since you're a Mac user. It'll feel familiar, as the UI isn't a stretch from OS X.

How do you connect to your network though? WiFi can be a bit of a pain in the rear, so Ubuntu GNOME might be best.

As shitty as it sounds the best idea is try 'em and see which one fits you best! It's a tough call... What matters to you?

joeb - Jan 20, 2015 at 18:45

codelite for IDE. everything else sucks

Alex Ianu - Jan 21, 2015 at 17:54

Targeting a specific distribution isn't really important. Since you're using SDL and other universal stuff it won't be an issue. Portability between distros hasn't really been an issue since gaming on Linux took off.

As the Steam implementation guy at Manjaro Linux, I have one request though: keep a machine with a partition running a bleeding edge distro (Arch - THE rolling distro, Manjaro unstable - easily deployable Arch w/ good driver and detection support, or Gentoo - the 'you compile everything' distro). That is where any bugs or version issues will pop up first, and they WILL eventually spread, so you can nick 'em at the source.

Geoff - Feb 18, 2015 at 15:43

Check out Linux Standard Base <http://www.linuxfoundation.org/collaborate/workgroups/lsb>; on top of a vanilla Red Hat 4.x or 5.x distro if you want binary compatibility across lots of distros. We've seen if you develop on Redhat 5x or 6x you can't run on 4.x, (runtime loader changes) though that's pretty old for a desktop OS at this point. Not sure if you can develop on 6.x and bring back and run on 5.x without issues at the linker/loader?