Games on GitHub
github.com
github.com
Since merges are not generally possible (except for some special usecases), one would expect version-control system's help in avoiding parallel edit situation at all. This is where svn's centralized server helps, allowing "pessimistic locking" of certain files and folders. AFAIK, Plastic also offers such a feature, when git cannot do anything like that by design.
I tried storing large images in git once. And one problem was when git would try to do garbage collection every now and then. And start diffing all the images against each other to repack them to use less space. This was very CPU and memory intensive.
We've been using it pretty much since it was integrated into github.
On the other hand, it seems like it makes you wait until you're trying to do a git push before you find out somebody else has it locked already - which seems a bit cruel. The more traditional approach is for the file to be read-only in your working copy, and you use the version control client program to make it writeable (and it then performs the appropriate checks). So if you omit to consult the client program first, you'll get no further than your first attempt to save before you find out.
P4 has many of these integrations so that artist and other non-technical people will know the moment they open the file that if they want to edit it they need to check it out. Similarly they can choose to check in the changes directly from their asset editing app, not from some separate app. They also need an easy way to find out who has it checked out so they can go over to that person and ask when they'll be able to edit it or if the person forgot to check in their changes.
https://www.perforce.com/product/components/perforce-plugin-...
I've written some in the past as well (http://mayasvn.sourceforge.net/) that would not just check in a Maya file but also check in all the referenced files (otherwise an artist checks in the asset but there are lots of missing textures).
On a subnote: Asking the artist "check this in?" on each save is a bad UX. I tried that and the artists complained since they save all the time (in case their app crashes).
Too bad that, at least in the games I looked at, all the non-game code (e.g. Google play integration, analytics, etc..) is missing.
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
I imagine single-player premium desktop games are quite a bit simpler, but I've never had the pleasure.
EDIT: Nevermind I found it way down the list, but still, id is pretty major company when it comes to games.