3 ms·

Choose the right platform for your goals. While id was banging out bare-metal code on a relatively unchanging PC platform, my old partner and I spent our time

Choose the right platform for your goals. While id was banging out bare-metal code on a relatively unchanging PC platform, my old partner and I spent our time battling API deprecation, a change of processor, endianness issues, performance issues, just on and on and on, a whole litany of insults on the Macintosh platform. We were attempting to "just have a successful shareware game business on the Macintosh" but after 20 years of this self-flagellation I bailed. We each now work at rather successful studio/agency development firms and I've probably contributed to more meaningful projects in the last year and a half than in all the years previously. When you choose the wrong platform, you will not only be running against the wind, but when the wind dies down you will be so tired that you miss the new opportunities. We should have been positioned to capitalize on the iOS store back in the mid-2000s with our substantial codebase, but due to burnout I witnessed others openly rake in $100,000 paydays on projects similar to our own that they only spent a couple of months making. That could have been us, but I can't blame the competition or Apple because in hindsight it was my own sheer inability to stop beating a dead horse that put me in the universe that didn't work out. Really you should always be working in a sustainable way that's not too easy and not too hard so that you can see the forest for the trees, and after a while those small successes often accumulate into something unbelievable.

lawpoop 10y ago
How does one choose the right platform ahead of time? It seems that that would be something you could only judge in hindsight. For instance, did you know that, over the course of your endeavour, that the powers that be were going to deal you a bunch of API deprecation? Did Id Software know that their respective platform providers, or the market in general, were going to keep their platform a relatively stable development target? I am thinking about developing a game in my spare time. I don't have any grand plans with it. I thought to develop it on Android (though I hear that's a mess, getting apps to run on various phones and OSes), but I want to try to keep open the possibility that it could be ported to other platforms (iOS, console, etc) relatively painlessly. Being a web developer, how could I glean enough information in areas I'm really unfamiliar with to judge which is the right platform? If I decide on Android, for whatever reason, and I become un-enamored with all of its warts, how do I know that the grass truly is greener on the other side?
- zackmorris 10y ago
  It pains me to say it, but the big companies (even nvidia) are incentivized towards proprietary solutions, so your best bet would probably be to go with something like Unity. My big mistake was to think that I could manage a game engine. This was in the late 90s and early 2000s before the current paradigm of github, stackoverflow, etc. I got to the point where I was cross-compiling with mingw and using libraries like libpng, libfreetype, libtheora, etc because frankly a lot of the system-level APIs at that time were not up to the demands that games placed on them (and probably still aren’t). I spent a ton of time in dependency hell because it was all C++ without a package manager, so it was a game of whack-a-mole just to update a single library. These were all huge red flags but I couldn’t see them because I was thinking to myself that if I could keep that mess together long enough, that I could put out a gold master of our flagship game on Mac, PC and iOS (and eventually Xbox etc) and everything would be all better. But what ended up happening that I spent the entirety of my time maintaining dependencies and trying to make rent. Now id has certainly been down that road as well, and I’m not saying that the Windows platform is free of breaking updates. The big difference was that Windows was already the de facto gaming platform outside of consoles. So id could rely on a vast constituency of established game companies that would put Microsoft’s feet to the fire, or simply route around the damage with 1337 code snippets from the community. I always sensed a kind of reverence towards gaming, so that if Microsoft made a mistake, it was instantly under a magnifying glass. Contrast that with the Apple development community, where rampant fanboism has led to an Apple-knows-best mentality that prevents meaningful progress at even the most basic levels: OpenGL drivers are years behind, online documentation goes missing, iOS code signing is a hair raising process, etc etc etc etc etc.. I don’t want to be too hard on them but they’ve lacked a serious software engineering vision for so long that to fix it now would require a reevaluation of where they are going as a company. I don’t know what to tell you as far as your own game development goals, but I know that if I was starting now, I would work at the highest levels that are still performant and likely to be maintained in the future. I prefer fundamentals over cookie cutter solutions, so I might opt to go with up-and-coming standards like WebGL and WebSocket running in Cordova to learn some fundamentals before applying them in Unity. The rule of thumb used to be that anything you were working on would be free and open source within 2-3 years, but that’s dropped to about 6 months today. So don’t stress too hard about it, just do what feels right and gives the shortest runway between planning and implementation. Often the conceptually correct solution and the most optimized one are the same or similar in the long run. Be wary of solutions like CocoaPods that seem to create their own diverging ecosystem. A few are ok, but if you find yourself knee-deep in packages that’s definitely a code smell. So is having too few, monolithic packages trying to take the place of the OS. Prioritizing your time gives you a roadmap on where to put your efforts and helps you remember “don’t be like that guy”.

lawpoop 10y ago

How does one choose the right platform ahead of time? It seems that that would be something you could only judge in hindsight. For instance, did you know that, over the course of your endeavour, that the powers that be were going to deal you a bunch of API deprecation? Did Id Software know that their respective platform providers, or the market in general, were going to keep their platform a relatively stable development target? I am thinking about developing a game in my spare time. I don't have any grand plans with it. I thought to develop it on Android (though I hear that's a mess, getting apps to run on various phones and OSes), but I want to try to keep open the possibility that it could be ported to other platforms (iOS, console, etc) relatively painlessly. Being a web developer, how could I glean enough information in areas I'm really unfamiliar with to judge which is the right platform? If I decide on Android, for whatever reason, and I become un-enamored with all of its warts, how do I know that the grass truly is greener on the other side?

zackmorris 10y ago
It pains me to say it, but the big companies (even nvidia) are incentivized towards proprietary solutions, so your best bet would probably be to go with something like Unity. My big mistake was to think that I could manage a game engine. This was in the late 90s and early 2000s before the current paradigm of github, stackoverflow, etc. I got to the point where I was cross-compiling with mingw and using libraries like libpng, libfreetype, libtheora, etc because frankly a lot of the system-level APIs at that time were not up to the demands that games placed on them (and probably still aren’t). I spent a ton of time in dependency hell because it was all C++ without a package manager, so it was a game of whack-a-mole just to update a single library. These were all huge red flags but I couldn’t see them because I was thinking to myself that if I could keep that mess together long enough, that I could put out a gold master of our flagship game on Mac, PC and iOS (and eventually Xbox etc) and everything would be all better. But what ended up happening that I spent the entirety of my time maintaining dependencies and trying to make rent. Now id has certainly been down that road as well, and I’m not saying that the Windows platform is free of breaking updates. The big difference was that Windows was already the de facto gaming platform outside of consoles. So id could rely on a vast constituency of established game companies that would put Microsoft’s feet to the fire, or simply route around the damage with 1337 code snippets from the community. I always sensed a kind of reverence towards gaming, so that if Microsoft made a mistake, it was instantly under a magnifying glass. Contrast that with the Apple development community, where rampant fanboism has led to an Apple-knows-best mentality that prevents meaningful progress at even the most basic levels: OpenGL drivers are years behind, online documentation goes missing, iOS code signing is a hair raising process, etc etc etc etc etc.. I don’t want to be too hard on them but they’ve lacked a serious software engineering vision for so long that to fix it now would require a reevaluation of where they are going as a company. I don’t know what to tell you as far as your own game development goals, but I know that if I was starting now, I would work at the highest levels that are still performant and likely to be maintained in the future. I prefer fundamentals over cookie cutter solutions, so I might opt to go with up-and-coming standards like WebGL and WebSocket running in Cordova to learn some fundamentals before applying them in Unity. The rule of thumb used to be that anything you were working on would be free and open source within 2-3 years, but that’s dropped to about 6 months today. So don’t stress too hard about it, just do what feels right and gives the shortest runway between planning and implementation. Often the conceptually correct solution and the most optimized one are the same or similar in the long run. Be wary of solutions like CocoaPods that seem to create their own diverging ecosystem. A few are ok, but if you find yourself knee-deep in packages that’s definitely a code smell. So is having too few, monolithic packages trying to take the place of the OS. Prioritizing your time gives you a roadmap on where to put your efforts and helps you remember “don’t be like that guy”.