I’m taking a hiatus from this project in order to finish up a couple of other things. I hope to get back to it soon, at which time I’ll make the switch from Carbon to Cocoa and push ahead on user input and full-screen rendering.
As good fortune would have it, I recently acquired a MacBook Pro and have set about porting the most recent incarnation of my simulation framework to run under OS X. In my travels over the tubes I was not able to find a comprehensive, step-by-step guide to basic OS X game programming so in the great programmer tradition of NIH I decided to write one.
What You’ll Learn
This tutorial currently covers:
- An introduction to .NET development on OS X.
- How to create a window and receive events.
- How to receive idle time notifications to update your scene.
In the not-too-distant future I’ll be adding:
- How to configure OpenGL.
- How to receive keyboard, mouse, and game controller events.
- How set up fullscreen rendering.
Later I’d also like to add:
- How to play sound effects and music.
- How to create force feedback effects.
About the Code
I happen to use .NET for my development (and enjoy it greatly) so the code samples in this guide are written in C#. But since I’m really just making native API calls it should be useful to anyone looking to get up to speed on OS X game programming. Whether you are using C++ or Java or Python or Scala you will still make the same system calls in the same order. In fact, if anyone wants to recode the examples in another language I’d be happy to host those versions here as well.
You are free to use the included code samples in any manner you choose, including commercial use. If you do, some credit and a link back to this tutorial would be appreciated (but not required).
If you are interested, everything I learn about and discuss here will end up in my Flat Four project, an open source framework for games and simulations (which just so happens to run on OS X).
A Disclaimer
Let me state up front that I am no OS X expert. I am learning as I go and will undoubtedly make a gaffe or two along the way. That’s actually why I am writing this guide: so that I can have my errors pointed out in excruciating detail, in the hope of making my code the best it can be. Comments and corrections are encouraged — don’t worry, I’ve got a thick skin! You can leave a comment at the bottom of any page.
Good luck, and have fun!
