Support us on Patreon
PayPalThe developer of Smith and Winston made an interesting blog post about supporting multiple platforms
I recently talked about the Steam release of Smith and Winston but I didn't realise until late last night, that the developer actually made a very interesting blog post about supporting multiple platforms.
Interesting enough, that it warranted an extra post to talk a little about it. Why? Well, a bit of a situation started when game porter Ethan Lee made a certain Twitter post, which is a bit of a joke aimed at developers who see Linux as "Too niche" while practically falling over themselves to get their games on every other new platform that appears. This Twitter post was shared around (a lot) and some developers (like this) ended up mentioning how Linux doesn't sell a lot of games and it continued spreading like wildfire.
There's been a lot of counter-arguments for Linux too, like this and this and this and this and a nice one thrown our way too. Oh and we even spoke to Tommy Refenes who said the next SMB should come to Linux too, so that was awesome. Additionally, Ethan Lee also wrote up a post about packaging Linux games, worth a read if you're new to packaging for Linux.
Where was I again? Right, the blog post from the developer of Smith and Winston about how they support Windows, Mac and Linux. They go over details about how they do so, from using SDL2 which they say "takes 90% of the pain away from platform support" to the cross-platform rendering library bgfx. It's just a really interesting insight into how developing across multiple platforms doesn't have to be overly difficult.
I especially liked these parts:
I’ve been writing games and engines for 30+ years so none of this is new, I have a lot of experience. But you only get the experience by doing it and not making excuses.
By forcing the game through different compilers (Visual C++, Clang and GCC) you find different code bugs (leave the warnings on max). By forcing the runtime to use different memory allocators, threading libraries and rendering technologies you find different runtime bugs. This makes your code way more stable on every platform. Even if you never deploy your code to a non windows platform just running it on Linux or macOS will expose crashes instantly that rarely appear on Windows. So delivering a quality product on the dominant platform is easier if your support the minor platforms as well.
They also clearly mention, that they might not even make their money back on the Linux port of Smith and Winston. However, they're clear that the other reasons (code quality, easier porting to other platforms and so on) do help make up for it. This is a similar point the people from Stardock also made on Reddit.
See the post here in full. If you wish to check out their game, Smith and Winston, it's available on itch.io and Steam in Early Access.
Article taken from GamingOnLinux.com.
I don't get this?
Quoting: BeamboomI don't understand how different compilers can expose different bugs in the same(?) code. I mean, a bug is a bug isn't it? Or is it because the use of different libraries expose bugs caused by those particular libraries/APIs? If so, how will the code run smoother on a different set of libraries if the bug is related to that other library?Doesn't work that easy in programming, especially in C/C++, which is what pretty much all gaming is based on.
I don't get this?
The same code simply might behave ever-so-slightly-different under different compilers.
Not major differences, mind you - that would be absurd. But small ones that can actually help uncovering otherwise hard to find bugs.
But he also mentions different libraries, like different threading libs per platform. That might be a more obvious example, where one library functions in a way that makes a possible deadlock in your code occur more often on that platform, so finding that bug earlier helps tremendously.
Last edited by TheSHEEEP on 10 January 2019 at 11:25 am UTC
Marc Di Luzio Jan 10, 2019
Quoting: BeamboomI don't understand how different compilers can expose different bugs in the same(?) code. I mean, a bug is a bug isn't it? Or is it because the use of different libraries expose bugs caused by those particular libraries/APIs? If so, how will the code run smoother on a different set of libraries if the bug is related to that other library?
I don't get this?
In general, this is a bunch of things:
1. Different compilers have different sets of warnings, one may silently do something unexpected, another may say "Uh, look here mate, a bad" (MSVC is known for being very lenient, clang is very strict, so clang may find the source of bugs for you).
2. "Undefined Behaviour" is common in C/C++ and compilers may behave differently. One compiler may cause an immediate crash (easy to debug) but another may overwrite a random bit of RAM somewhere (very hard to debug).
3. Two compilers may share the same compiler bugs or odd behaviours (in the old days PS3 used GCC), so compiling for one platform may be doing a chunk of the work resolving issues you would have found on another platform in the future (Linux GCC bug may also have been found on PS3 GCC).
There's more than just those, but hopefully, that's a taste.
Have you thought about consulting some linux developers to make a kind of guide of "Best practices to make an multi-platform game"?
Like pointing some tips about which engine, libraries, sound libraries they should use, and which they should avoid...
I know that most developer companies don't support linux because of business decisions, but there are a lot of devs who are a little "clueless" about how linux works. This also clould help some users to feedback devs about using some resources to make the porting / emulation easier for us.
Anyway It's just a suggestion :)
Quoting: BeamboomI don't understand how different compilers can expose different bugs in the same(?) code. I mean, a bug is a bug isn't it? Or is it because the use of different libraries expose bugs caused by those particular libraries/APIs? If so, how will the code run smoother on a different set of libraries if the bug is related to that other library?
I don't get this?
This is a good question: At a very basic level different compilers warn about different things. Although the C/C++ standard defines what is an error very clearly different compilers will warn about different things. Often this isn't that important and isn't going to save your bacon but a good developer listens to their compiler. There is a reason the compiler isn't happy and it can reveal false assumptions and you'll find yourself saying "I have no idea how that ever ran".
Different compilers do have different standard libraries though and they can be more of less forgiving. Visual C++ STL (Standard Template Library) has extensive debugging output in debug builds that catch errors quickly and precisely at the expense of debug builds being very slow. This also has the effect of using more memory and changed memory usage can also hide or expose different kinds of bugs. So macOS and Linux not having these is "good" as in different and in the case difference is good but not better or worse (I am not saying one compiler is better than another, just different).
Another big difference between standard libraries is the way they allocate memory within the application heap. So the OS gives your application a chunk of memory that only it can use called a heap and the application allocate's and frees blocks within that heap. Each standard library has different algorithms for how allocate and free work and you can even replace them with your own if you are brave/foolish/clever/stupid/genius. So when you allocate a piece of memory, use it, free it and then illegally use this piece of freed memory you get different behaviour. Annecdotally on Windows you get away with this a lot more often than on UNIX where you will more often (but not always) crash almost instantly making it easier to track down the problem. On embedded platforms (consoles for example) where memory is tighter you also get different behaviour as the OS vendor will tweak the memory allocator to be more aggressive about recycling memory than on a desktop where "memory is limitless".
Hope that helps and vaguely makes sense?
Quoting: TheSHEEEPdifferent threading libs per platform. That might be a more obvious example, where one library functions in a way that makes a possible deadlock in your code occur more often on that platform, so finding that bug earlier helps tremendously.
Absolutely more obvious, but like I say how can a library-specific bug really help on other platforms, where other libraries are used for that same function where a particular issue is not present?
Admittedly I've only got experience from higher level languages, and will totally accept that is the reason for my lack of comprehension. :)
I didn't regret buying W&W, but now i regret even less. So, i sub-regret it ?
Quoting: TcheyI didn't regret buying W&W, but now i regret even less. So, i sub-regret it ?
If we ever do a boxed version this quote is going on it :D
Quoting: metaldazzaHope that helps and vaguely makes sense?
Absolutely, thanks!
wintermute Jan 10, 2019
Quoting: Beamboombut like I say how can a library-specific bug really help on other platforms, where other libraries are used for that same function where a particular issue is not present?
The library-specific bug could expose a problem in your algorithm that you've mostly been able to ignore up until now because the bug only occurs in 0.01% of cases with the other library, so you've never been able to replicate it.
See more from me