And when you're actually taking games to market, all that non-game code makes up a huge percentage of the development cost. It's highly predictable code that mo

And when you're actually taking games to market, all that non-game code makes up a huge percentage of the development cost. It's highly predictable code that most game devs have done many times before (which is why I always argue that once the gameplay is locked and loaded, which it should be before you go into large-team production [if there are still big changes to make, you should stay in prototype and not have a full team doing production quality art, UI, sound, servers, etc that might need to be replaced], mobile game dev projects should always be waterfall, not agile), but it's still a lot of work, and it can't ever be 100% reused. Speaking just to mobile, you need to add, on top of "the game" itself: - scalable persistence that handles play on multiple devices and platforms (add load testing to this if you're "Doing It Right") - in-app-purchase integration - metrics instrumentation, collection, analysis, etc. - social integration: authentication, sharing, invites, leaderboards, etc., often with backend components, not to mention the hell that is integrating with social SDKs and keeping them all up to date - dynamic content loading, if your game is too big to fit in the ipa/apk - TOS, legal, COPPA compliance dialogs/data filtering - a proper audio integration (chances are your initial approach, whatever it was, won't work for a full game) - dynamically loaded variables system (can't do an App Store push every time you need to change something about the game tuning) - A/B testing - customer service mechanisms - ads - push and local notifications - user acquisition attribution (to know which ad networks are effective at pushing users) - landing page optimization - platform nonsense (a carrier just pushed a new version of Android to one of their phones that has a crappy GPU driver whose bugs are only fully exposed in the latest OS version? Congrats, now half of your shaders draw black squares, have fun tracking that one down, esp. since that particular driver/chipset combo only exists in phones sold in Canada and eastern Europe!) - and so on, when I was in this field we'd end up with lists 40-50 items long of basic stuff that every game needs, along these lines It gets really messy, "the game" is really just the barest start. All the stuff I listed above can easily take 50%+ of total man-hours in a dev cycle, even if you have well-factored code from other games to work off of, just because it all requires game-specific UI and design (both of which always have some non-zero code cost). I imagine single-player premium desktop games are quite a bit simpler, but I've never had the pleasure.