My latest "cheese talks to" interview is live, this time talking with cross platform game porter flibitijibibo (Ethan Lee) about porting games, software development and his community endeavours.
In this three part interview, we trace flibit's path through modding and game development, eventually leading him to porting several indie games to MacOS/Linux (including Vessel from the Humble Indie Bundle 6, Waveform, Eversion and Blueberry Garden). We also cover the hurdles and pleasant surprises associated with migrating others' code to new platforms, and touch on flibitijibibo's assorted activities within the Steam and Linux communities.
Here are a couple of snippets:
http://cheesetalks.twolofbees.com/flibitijibibo1.php
Enjoy! Article taken from GamingOnLinux.com.
In this three part interview, we trace flibit's path through modding and game development, eventually leading him to porting several indie games to MacOS/Linux (including Vessel from the Humble Indie Bundle 6, Waveform, Eversion and Blueberry Garden). We also cover the hurdles and pleasant surprises associated with migrating others' code to new platforms, and touch on flibitijibibo's assorted activities within the Steam and Linux communities.
Here are a couple of snippets:
QuoteHow do you find game porting to differ from game development?
There's a lot more debugging in porting, at least in my experience. I'm a colossal pain in the ass about portability/code quality though, so anything I work on from the start tends to require a lot less time in QA. I like to think that this carries into my port work, but it's probably not as much as I want it to be.
I also tend to learn a lot from my porting. I'll only delve into what I would put in my own engines if I work alone, but when dealing with other engines I'm forced to broaden my horizons a bit more. Here are some things I learned to port some of my games (some of these may shock you):
- Waveform: Win32 threading, WGL/CGL/GLX, Win32 API
- Blueberry Garden: C#, Mono, XNA, basic Direct3D-ish stuff, MonoGame (basically everything, but I still ported it to Linux in a weekend!)
- Eversion: Ruby, and how it's a pain on OSX
- Vessel: Advanced Direct3D, MojoShader, MojoDDS
As you can see, a lot of these things I just learn as I port. Is this bad? I don't know, maybe. I've been able to get these out in a timely manner, so I can't be sure. So far the only project that's been impacted by this is Vessel, but that's also the largest project I've ever worked on. It's hard to tell, at least from my perspective. Maybe someone sensible will read this and tell me I'm a phenomenal idiot for learning things after I take the project.
QuoteHow do you feel that commercial games fit within the Free Software ecosystem?
Right now commercial projects are the main source of professional developers in the Free Software universe. Commercial projects need open libraries, open libraries need work, developers work on those libraries.
Of course, we'd all like for developers to release the main project source as well, but this is where we're at, currently. There are still a lot of people developing on proprietary libraries/frameworks as well, so I think we should keep working at making the free/open libraries the best they can be. Think of it as attacking from all sides, I guess.
QuoteWhat do you consider to be the values of cross platform software to gamers, developers and the industry as a whole?
Games, from a business standpoint, should not be dependent on a single platform. If something goes horribly wrong with one platform (Windows 8?), it shouldn't be grounds for a catastrophe, and it should be possible for the industry as a whole to move freely between platforms to provide gamers and game developers to provide the best experience possible without having to force anyone into using software they'd rather not use. If you think this is silly, read the last sentence again with DRM in mind, rather than platform dependency.
QuoteWhat key factors contribute to the ease or difficulty of a port?
Use of F/OSS libraries helps. Use of cross-platform libraries helps even more. Strict use of multiple static analysis tools helps even more. Use of compilers other than Visual Studio's helps even more. All of these things aren't just portability concerns, they're code quality concerns. High code quality = easy port work, plain and simple.
Liberal use of Visual Studio's liberal compiler is annoying. Misuse of asserts and NDEBUG is irritating. Trying to come up with your own clever asset packaging format is infuriating. Use of OS-dependent low-level APIs is agonizing. Use of DirectX is a death wish.
http://cheesetalks.twolofbees.com/flibitijibibo1.php
Enjoy! 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.
Cheeseness Nov 16, 2012
Quoting: "Anon, post: 6372"Yeah, it doesn't really crash anymore and the performance is fine. All-in-all it's almost playable, but the game is still prone to crash due to some graphics related bugs. So it isn't just cosmetic issues.
flibit tells me there aren't any crash causing bugs left that are graphics related, so if you've been testing, and you've encountered something that appears to be so, make sure you report it.
0 Likes
There are three major blockers left before I can stamp Vessel with an RC tag:
- Outdated assertions. Best case, I just have to delete some of these. Worst case, I compile with NDEBUG.
- Fluro eyeballs. At first glance they're just missing, which I thought was a scripting issue, but something else is going on (looking at it right now). This sounds like a minor issue, but it's the source of every crash I've got in the bug tracker that's not an assertion. This needs to be fixed.
- Color channels. Some materials are still the wrong color, including lighting. Will be doing this last.
There are other things I may address if I can get it in a November release, but none of them are game-breaking or even problematic (and a couple of them could possibly require editing the content files, which I'm avoiding at all costs). Of course, there may be other bugs that I have to fix, but currently Vessel is doing pretty well in QA.
- Outdated assertions. Best case, I just have to delete some of these. Worst case, I compile with NDEBUG.
- Fluro eyeballs. At first glance they're just missing, which I thought was a scripting issue, but something else is going on (looking at it right now). This sounds like a minor issue, but it's the source of every crash I've got in the bug tracker that's not an assertion. This needs to be fixed.
- Color channels. Some materials are still the wrong color, including lighting. Will be doing this last.
There are other things I may address if I can get it in a November release, but none of them are game-breaking or even problematic (and a couple of them could possibly require editing the content files, which I'm avoiding at all costs). Of course, there may be other bugs that I have to fix, but currently Vessel is doing pretty well in QA.
0 Likes
Patreon
PayPal
Currently working on Winter's Wake, a first person text adventure thing and its engine Icicle. Also making a little bee themed base builder called Hive Time :)
I do more stuff than could ever fit into a bio.
See more from me