Support us on Patreon
PayPal
A recent article about Jon Blow has spurred other developers getting in touch, and one developer is Brushfire Games, the developer of Shipwreck. Their sales are looking good, and they have some thoughts.
I spoke with Nick from Brushfire Games, and he shared these sales statistics with us. We are very privileged to get this kind of info, so a big thank you.
Sales stats for Shipwreck
89.64% Windows
5.96% Mac
4.40% Linux
That’s some of the healthiest Linux sales I’ve seen to date on a game, and I’m pretty impressed.
Nick did have more to say about it, and he gave these reasons on why he supports Linux with his studio:
It’s nice to see a developer who isn’t solely focused on income, but it is important of course and I’m not blind to that. If you want to do a Linux version, you need to remember the sales will be lower than other platforms, and not expect to get rich from it.
Nick did however have some other thoughts on why Linux may be a little more difficult:
I do understand what Nick is saying here, everything you get is pretty much direct from Apple. You don’t usually need to worry about getting a driver here and there for your machine, as it’s usually just done for you.
The Steam runtime is something that is helping with the many distributions argument too. I have yet to personally see the fragmentation actually cause any issues myself, so I’m still not entirely sure where people get that idea from. If someone could point out in the comments any games that are broken on certain distributions, I would appreciate seeing them (apart from Legend of Grimrock, as that's not a distribution issue).
This is important, and it’s something that is improving over time. Linux has gotten easier to install in a short amount of time, and the tools we have available now over a year ago are far more stable.
What we need to do is accommodate developers needs, and keep pointing them in the direction of tools, people, and whatever else they may need. We also need to not point developers at niche distributions, but the most popular. I’m not going to be popular with some people for this, but point them at Ubuntu/Mint/SteamOS and be done with it. The vastly smaller distributions should be accommodating the others to make sure games work correctly, it shouldn’t be up to the developers if x distribution does something slightly differently that it breaks a game.
Again some valid points. I actually get annoyed personally when a reply is to “try x distro instead”, and I see it a lot too. We need people to drop their distributions bias, and just focus on the problems people have.
One thing I would really like to see, is more developers blogging about tools and resources they found that helped them develop for Linux directly. If you know of them, share them, and then share them some more.
You can support Nick by grabbing Shipwreck on Steam or Humble, both are available at their official site.
If you are a developer and would like to share statistics and thoughts with us, feel free to contact us any time. We like to cover all sides of the Linux gaming argument, even when it isn’t pretty, and we aren’t afraid to do so. Article taken from GamingOnLinux.com.
I spoke with Nick from Brushfire Games, and he shared these sales statistics with us. We are very privileged to get this kind of info, so a big thank you.
Sales stats for Shipwreck
89.64% Windows
5.96% Mac
4.40% Linux
That’s some of the healthiest Linux sales I’ve seen to date on a game, and I’m pretty impressed.
Nick did have more to say about it, and he gave these reasons on why he supports Linux with his studio:
Quote1. We're a small studio and need to go after any customers willing to spend money on our products.
2. I believe in letting people game where they want. I'm a Mac user and it sucks when a game I like (*cough* Banished *cough*) doesn't support my platform. So I can empathize with the Linux base.
It’s nice to see a developer who isn’t solely focused on income, but it is important of course and I’m not blind to that. If you want to do a Linux version, you need to remember the sales will be lower than other platforms, and not expect to get rich from it.
Nick did however have some other thoughts on why Linux may be a little more difficult:
Quote1. As for the "why Mac over Linux" argument, developing on/for a Mac is much simpler. Yes, you have to buy proprietary hardware, but then you just download Xcode and you're off and running. You still have code to write, but you don't have to deal with any driver issues, you don't have to use a package manager to get various tools, and you have a decent IDE for free from the platform holder that does what you need. Mac is also nice since there's a very small set of hardware and operating system versions to support which is a far cry from how Linux operates with open hardware and a vast array of distros (and various versions of those distros).
I do understand what Nick is saying here, everything you get is pretty much direct from Apple. You don’t usually need to worry about getting a driver here and there for your machine, as it’s usually just done for you.
The Steam runtime is something that is helping with the many distributions argument too. I have yet to personally see the fragmentation actually cause any issues myself, so I’m still not entirely sure where people get that idea from. If someone could point out in the comments any games that are broken on certain distributions, I would appreciate seeing them (apart from Legend of Grimrock, as that's not a distribution issue).
Quote2. I too have had issues getting distros to work for me when trying to setup for development. And yes there are solutions and things to try, but remember that (most) developers don't plan to use Linux as their main machine so they're not really interested in investing a lot of time to setting up their dev environment. This is another reason why even if Linux is 4% of their sales they may forego Linux simply because of the time/effort of setting up (and supporting) Linux.
This is important, and it’s something that is improving over time. Linux has gotten easier to install in a short amount of time, and the tools we have available now over a year ago are far more stable.
What we need to do is accommodate developers needs, and keep pointing them in the direction of tools, people, and whatever else they may need. We also need to not point developers at niche distributions, but the most popular. I’m not going to be popular with some people for this, but point them at Ubuntu/Mint/SteamOS and be done with it. The vastly smaller distributions should be accommodating the others to make sure games work correctly, it shouldn’t be up to the developers if x distribution does something slightly differently that it breaks a game.
Quote3. I've also seen the forums or help threads where people dismiss the challenges others have with Linux. Usually the responses are along the lines of "try this other distro" or "use this other desktop manager" which aren't really helpful because those answers feel so arbitrary to someone not steeped in Linux. With so many options it's really hard as an "Outsider" to know the best way to setup a Linux box for development that will allow one to build for as many users as possible. For example, I still don't know if things I build on Ubuntu or Mint will work on Debian or other distros. As a Mac person I just have no idea how that all works. So if the community really wanted to help devs, make a super nice wiki on "How To Setup a Linux Distro to Build C++ Games for SteamOS and Linux using SDL2". I'd read and share that in a heartbeat.
Again some valid points. I actually get annoyed personally when a reply is to “try x distro instead”, and I see it a lot too. We need people to drop their distributions bias, and just focus on the problems people have.
One thing I would really like to see, is more developers blogging about tools and resources they found that helped them develop for Linux directly. If you know of them, share them, and then share them some more.
You can support Nick by grabbing Shipwreck on Steam or Humble, both are available at their official site.
If you are a developer and would like to share statistics and thoughts with us, feel free to contact us any time. We like to cover all sides of the Linux gaming argument, even when it isn’t pretty, and we aren’t afraid to do so. Article taken from GamingOnLinux.com.
0 Likes
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
Quoting: BeamboomAre there a lot of games on Steam written more or less by hobbyists?
My entire image of a games developer is about to get a serious correction here now...!
Of course there are, Steam is rammed full of games made by people of all ages and competency's.
2 Likes, Who?
Well, the line between "a hobbyist" and "a professional" gets blurry over time when it becomes easier to do whatever you happen to be doing. For example, almost any random person can pick up a camera and become a host of their own show thanks to the power of YouTube and accessible video editing software. Same thing with game development, you can these days make good games without even having to know how to program.
I'd say the end result tells more than the journey there in this day and age. If a person can make an awesome game using the "incompetent rando" approach then more power to them.
I'd say the end result tells more than the journey there in this day and age. If a person can make an awesome game using the "incompetent rando" approach then more power to them.
2 Likes, Who?
It'd be in all of our best interests to convince Valve to bundle dev tools into SteamOS's desktop mode, or at least make them extremely easy to install for anyone of any experience level, and turn SteamOS into a one-stop-shop for gamers and game devs alike. This is a huge opportunity with the likes of Valve, Alienware, GameStop (eww) behind it...
4 Likes, Who?
Maybe i'm allowed to give some hints to check.
1.) http://nothingtocode.blogspot.de/2013/07/setting-up-sdl2-in-ubuntu-linux-mint-debian.html << this is a very easy example of how you install all needed headers for SDL2
2.) The first only installs the SDL2 headers. You might want to add the OpenGL development files / glew development files and openal development files too
3.) What you want for crossplatform development is a different build system than visual studios nmake. I highly suggest cmake. If the development enviroment is set correctly cmake searches for the right pathes and includes the right files on windows / linux and mac osx.
4.) A nice ide supporting cmake + c/c++? If you ask me i would highly suggest you take a look on clion https://www.jetbrains.com/clion/ . I'm totally honest here i suggest this with totally knowing it cost money. There are many alternatives around but this seems so far give the best overall experience on all systems (personal opinion at least in what you plan to do).
The following are maybe alternatives:
- qtcreator
- eclipse + cdt
- https://www.visualstudio.com/en-us/products/code-vs.aspx (keep an eye on it , c++ other language support is highly requested)
I hope this helped a little.
Last edited by Glog78 on 4 July 2015 at 9:42 pm UTC
1.) http://nothingtocode.blogspot.de/2013/07/setting-up-sdl2-in-ubuntu-linux-mint-debian.html << this is a very easy example of how you install all needed headers for SDL2
2.) The first only installs the SDL2 headers. You might want to add the OpenGL development files / glew development files and openal development files too
3.) What you want for crossplatform development is a different build system than visual studios nmake. I highly suggest cmake. If the development enviroment is set correctly cmake searches for the right pathes and includes the right files on windows / linux and mac osx.
4.) A nice ide supporting cmake + c/c++? If you ask me i would highly suggest you take a look on clion https://www.jetbrains.com/clion/ . I'm totally honest here i suggest this with totally knowing it cost money. There are many alternatives around but this seems so far give the best overall experience on all systems (personal opinion at least in what you plan to do).
The following are maybe alternatives:
- qtcreator
- eclipse + cdt
- https://www.visualstudio.com/en-us/products/code-vs.aspx (keep an eye on it , c++ other language support is highly requested)
I hope this helped a little.
Last edited by Glog78 on 4 July 2015 at 9:42 pm UTC
3 Likes, Who?
Quoting: liamdaweI may run this website, and speak to a lot of developers, but I know jack about things like the command line to the point of disliking it.
I used to hate it too, until I realized that when anything or even everything breaks, the command line saves the day. I don't even have to restart my computer. It's also how a lot of things actually run, hiding the terminal so you can't see it like in Window$. If you can run a game and change the in-game settings, you can run a command in a command line.
*Game: Click "fun-game.x86_64", go to options and set resolution to 1024x768, click "Save settings"
*Command Line: fun-game.x86_64 --resolution=1024x768
The idea is, all the programs are written by humans so that other humans can read and understand them. Of course, you can always absolutely safely use "program-name --help" or "man program-name" or even look up the program options online if truly necessary. You don't have to keep more than a handful of them in your memory (or a text file until you get used to them). All of these things are there to help.
It is true that the number 1 issue I've found on Linux is library management. But actually, most of it is on the developer's end, because they tend to have little idea how to deal with dependencies (including or not, compiling or not) and where to look for libraries. The programs always look in the wrong places, especially with 32-bit compatibility libraries and binaries installed, and (nearly always) no options are provided to change where the program looks. This is especially important when compiling, where there have been so many times I had to manually and carefully change /lib to /lib64 in a configure or Makefile because it wouldn't accept any options to the contrary. Some programs don't even accept LD_LIBRARY_PATH, much less the LD_PRELOAD which rarely works.
Another thing about libraries, some distros include extra libraries by default when compiling. The rest of the distros have to change the actual "include" statements in files for it to work, or maybe with some extra linker flags.
I would say a lot of the hostility is directed at this "non-standardization". On Window$ and Mac, there are few places that the libraries go and that's it. On Linux, you have:
/lib (can include 64-bit libraries, 32-bit libraries, or both depending on your set-up and where your programs want to install)
/lib32 (usually not there and never checked by any program, but clearer than just /lib )
/lib64
And the /usr counterparts of the above, which have the same problem. I still use it, I like it, but some parts still need some organization (and some degree of standardization of locations and programming environment) and better development. I can't wait until 128-bit shows up on Linux to cause even more of these issues (Note: Dreamcast is already 128-bit, but is going the way of Betamax mostly).
1 Likes, Who?
Quoting: MajorLunaC....
Thats why icculus and i do to suggest checking out cmake. Basically instead of telling i want for example /usr/include/SDL2/SDL2.h you just say cmake that you need SDL2 , OpenGL headers and libs. Here a smal example how it kinda looks to make it understandable how easy it is: http://sprunge.us/ghbX
The next step is that cmake makes a build file for your dev platform. So cmake on windows can create nmake files or mingw-makefiles or so on. Thats than what you can compile with your build enviroment.
Since every refresh of the cmake cache searches again for the dependencies you don't realy have to know where the files are as long as they are installed. Of course if you want specific settings cmake lets you override everything even depending on the platform but defaults to good system defaults.
So for example if you tell cmake to use a 32bit compiler it will search in /usr/lib32 or /lib32 for the files. If you tell cmake to use a 64bit compiler it will search on /usr/lib64 or /lib64 and so on.
That way you basically can also very fast switch between compilers. For example:
mkdir build
cd build
CC=/usr/bin/clang CXX=/usr/bin/clang++ cmake -D_CMAKE_TOOLCHAIN_PREFIX=llvm- -G "Sublime Text 2 - Unix Makefiles" ..
creates unix makefiles (make) and a sublime project file :) very nice i tell you
if you only do
cmake -G "Sublime Text 2 - Unix Makefiles" ..
it will use the default c/c++ compiler in your development enviroment
In the first place linux look very strange to develop on but once you start using ...
apt-get install thisspeciallibrary-dev thisspeciallibrary thisspeciallibrary:i386
and basically everything is in place afterwards you don't drop a tear for this msi / exe packages on windows :) At least it was for me that way.
Microsoft btw notice that too thats why c# have its nuget + dnwm enviroment. So comftable :P a json.file with the dependencies and they are downloaded using dnwm/nuget :)
Last edited by Glog78 on 4 July 2015 at 10:52 pm UTC
1 Likes, Who?
Quoting: Guest"How To Setup a Linux Distro to Build C++ Games for SteamOS and Linux using SDL2"
I’ve been thinking of something similar for a long time and started writing notes, but it’s complicated and I forgot about it :).
I switch machines weekly. Setting up a system from scratch is a breeze.
1. Install Linux Mint 17.
2. sudo apt-get install git codelite libsdl2-dev libsdl2-net-dev libsdl2-image-dev libglew-dev build-essential libsdl2-ttf-dev libfreetype6-dev
Linux - Done. Windows is a major pain comparatively. I'd love to see someone setup a full Mac dev environment in fewer steps.
3 Likes, Who?
Mountain Man Jul 5, 2015
Quoting: GuestThe problem is most people have a Microsoft education instead of a computer education.It's the old Microsoft Certification program that basically teaches you how to use Windows but doesn't actually teach you anything about computers. It's like back in my computer science days in college when we were always butting heads with business majors who took a class that was basically "Microsoft Office for Dummies" and then thought they were computer experts.
2 Likes, Who?
Valve are very experienced game developers, they could put together a sister distro to SteamOS targeted at developers, where all the libs and a decent IDE are there. They could even preinstall things like Godot or have a deal to get Unity set up from a very non-free repo you can apt-get install from.
If developer-friendliness really is an issue, that's a problem that can be solved if someone puts enough engineering behind it.
If developer-friendliness really is an issue, that's a problem that can be solved if someone puts enough engineering behind it.
7 Likes, Who?
Oh I remember this developer. Had an issue with pixel collision or something on release and it got fixed pretty quickly after a couple email descriptions. Nice guy and a fun little retro Zelda inspired game. :) I see some really nice potential for a sequel with more content and some additional physics based combat (ie: Link to the Past).
His statement about Mac and Linux ports resemble empathy. Honestly, more people need this in a diverse world, as it's becoming rarer with clashing ideals and culture. That is why I hope gamers/users get their OSX ports as well. I mean, why not? More money for the developer and convenience for the customer.
His statement about Mac and Linux ports resemble empathy. Honestly, more people need this in a diverse world, as it's becoming rarer with clashing ideals and culture. That is why I hope gamers/users get their OSX ports as well. I mean, why not? More money for the developer and convenience for the customer.
5 Likes, Who?
See more from me