Cross Platform Development
Rival Fortress Update #5
This week has been cross platform week for Rival Fortress.
I’ve been trying to set up a toolchain that can allow me to easily compile the game on Windows, Linux and Mac, from a single build machine. Since my main development platform is OSX, the first thing I tried was using Mingw-w64 alongside GCC to build for both Windows and Linux. After a lot of fussing around I was able to get the game to build for both Win32/64 and Linux 32/64, but unfortunately GCC is not able to output PDB debug symbols, so while in development, I will still have to compile with Visual Studio to be able to debug on Windows.
But the big question is:
Why game development on a Mac?
Mac OSX is not a common platform for game developers that aren’t targeting primarily Apple’s mobile products. Visual Studio is an excellent IDE with a fantastic (probably the best) graphical debugger, so it seems like a no-brainer for an Indie game dev to choose Windows.
I was a Windows developer for 12 years, before and after .NET was a thing. About 8 years ago I bought a Mac out of curiosity, and that’s when I discovered that “living in the shell” could give me a new level of productivity and freedom that Visual Studio or any other IDE just couldn’t give me. I still have a Windows machine that I mostly use for gaming, and a little debuggin when I have to make sure my code runs on Windows, but all of my development is done on a Mac.
Writing game code on OSX
My terminal is iTerm2 that I always keep fullscreen while I’m developing.
I write code in Neovim that, combined with Tmux, allows me to fly through code at a much faster pace than when working with any other IDE. OSX comes with Xcode but, unless you are doing iOS development, I find it to be a mediocre IDE with sub-par debugging tools.
This is how my setup looks like (the screenshot is 2560x1440):
The top two panes are Neovim, where I keep two files open most of the time. At the bottom I have a Zsh shell for when I need to do some Hub operations, and on the right is a
tail -f of the game log. I usually zoom the Neovim pane using Tmux’s
<prefix>z when I’m in “Flow”.
Debugging game code on OSX
My debugger of choice is LLDB. It’s a fantastic debugger once you customize it to fit your needs. It takes some time to get used to, especially if you are used to GUI debugging, but I find it almost rivals Visual Studio when it comes to giving you the information you need to quickly locate those pesky bugs.
This is what a typical debugging session looks like:(the screenshot is 2560x1440)
The left pane is LLDB customized with a
.lldbinit to show me the information I usually need based on the type of debugging I’m doing. I also have another
.lldbinit in the project directory that I use to format custom data types. On the right pane at the top is a Neovim session that I use to take notes or open miscellaneous files. At the bottom right is another
tail -f of the game log colorized based on the serverity of the log.
While I’m developing I never need to touch the mouse.