5 ms·

Games on GitHub

195 points by nodivbyzero 10y ago

harryjo 10y ago
Got a DMCA hit pretty quick: https://github.com/FullScreenShenanigans/FullScreenMario/ https://github.com/FullScreenShenanigans/FullScreenMario/
deleted 10y ago
[deleted]
da4c30ff 10y ago
What, no id[1] in the major companies? EDIT: Nevermind I found it way down the list, but still, id is pretty major company when it comes to games. [1]: https://github.com/id-Software https://github.com/id-Software
- ComodoHacker 10y ago
  >If you'd like to add a repository to the list, please create an Issue, or fork this repository and submit a pull request.
ronny2 10y ago
Opensource things are always good.
unsignedqword 10y ago
Many companies in the games industry have settled on using Perforce or SVN (or more recently Plastic DVCS) internally as, out of the box, it can handle both code and non-code assets (i.e. large binary files) well in tandem. Git has problems with the latter - people have tried to correct this with solutions like git-annex and git-LFS but these have failed to catch on thus far.
- BinaryIdiot 10y ago
  I was wondering about this as well. I haven't done much video game dev in the past few years but even in my little indie stuff trying to check files into Git was a bit rough at times. Doable but on a very small scale. I'm surprised Git hasn't been adapted to handle this more natively but I'm curious if there are any trends or directions people are heading in regarding this or if they're still sticking with SVN.
- kirushik 10y ago
  The problem with non-code assets in git is (or at least it was for us) not with such assets being large blobs with weird in-git storage model, but with such assets being _unmergeable_ in case of two parallel edits of the same object. 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.
  - rmc 10y ago
    > The problem with non-code assets in git is (or at least it was for us) not with such assets being large blobs with weird in-git storage model, but with such assets being _unmergeable_ in case of two parallel edits of the same object. 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.
    - ido 10y ago
      git lfs was buggy/clunky for a while but it now seems to actually be pretty stable and usable. We've been using it pretty much since it was integrated into github.
- fsiefken 10y ago
  GitLab has built-in support for git-LFS https://docs.gitlab.com/ee/workflow/lfs/manage_large_binaries_with_git_lfs.html https://docs.gitlab.com/ee/workflow/lfs/manage_large_binarie...
  - greggman 10y ago
    As pointed out in other comments LFS is not enough
    - fsiefken 10y ago
      Hi greggman, not enough for what? Do you mean usability? gitlab, github and bitbucket provide a GUI to git-LFS. Or do you mean not enough documentation or a technical limitation like maximum file size or check-in/out speed or just bugs?
      - to3m 10y ago
        Needs file locking too. Looks like GitLab sort-of has you covered, though: https://docs.gitlab.com/ee/user/project/file_lock.html https://docs.gitlab.com/ee/user/project/file_lock.html 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.
        jobvandervoort 10y ago
        You can see whether a file is locked in the UI, but we'd be happy to take any feedback on how to further improve this.
        greggman 10y ago
        You need to know it's locked when you open it. Which means you need plugins for popular software. Photoshop, Maya, Unity, 3DSMax, Blender, etc. 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-graphical-tools https://www.perforce.com/product/components/perforce-plugin-... I've written some in the past as well (http://mayasvn.sourceforge.net/ 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).
- INTPenis 10y ago
  True and as if perforce didn't have enough of a strangle hold on the industry, it's free for small studios under 20 users I believe. So that would include most indie developers.
gcatalfamo 10y ago
I don't know if this was reason it was posted for, but looking at how the code is structured in some of hose projects is extremely insightful for game making. 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.
- ewjordan 10y ago
  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.
oneeyedpigeon 10y ago
Quite a few (well, 2 out of 3 or 4 that I've tried) of the project's off-github websites are either domain-squatted or, worse, result in "your computer has been infected" popups. Obviously, that's going to happen with projects as they get abandoned, but I think the compiler of a list such as this one has a responsibility to make sure everything's legit.
Endy 10y ago
I never knew how much I need this. Thank you.
INTPenis 10y ago
How on earth could they miss OpenRTS?
kzrdude 10y ago
Here's another nice once, if you'd like faithful remake of Settlers II https://github.com/Return-To-The-Roots/s25client https://github.com/Return-To-The-Roots/s25client
SticksAndBreaks 10y ago
https://github.com/spring https://github.com/spring https://github.com/ZeroK-RTS/Zero-K https://github.com/ZeroK-RTS/Zero-K are missing in strategy
edem 10y ago
Very cool idea. I've just added my library to the list of libraries (opened a PR).

195 points by nodivbyzero 10y ago

Got a DMCA hit pretty quick: https://github.com/FullScreenShenanigans/FullScreenMario/ https://github.com/FullScreenShenanigans/FullScreenMario/

deleted 10y ago

[deleted]

da4c30ff 10y ago

What, no id[1] in the major companies? EDIT: Nevermind I found it way down the list, but still, id is pretty major company when it comes to games. [1]: https://github.com/id-Software https://github.com/id-Software

ComodoHacker 10y ago
>If you'd like to add a repository to the list, please create an Issue, or fork this repository and submit a pull request.

ronny2 10y ago

Opensource things are always good.

unsignedqword 10y ago

Many companies in the games industry have settled on using Perforce or SVN (or more recently Plastic DVCS) internally as, out of the box, it can handle both code and non-code assets (i.e. large binary files) well in tandem. Git has problems with the latter - people have tried to correct this with solutions like git-annex and git-LFS but these have failed to catch on thus far.

BinaryIdiot 10y ago
I was wondering about this as well. I haven't done much video game dev in the past few years but even in my little indie stuff trying to check files into Git was a bit rough at times. Doable but on a very small scale. I'm surprised Git hasn't been adapted to handle this more natively but I'm curious if there are any trends or directions people are heading in regarding this or if they're still sticking with SVN.
kirushik 10y ago
The problem with non-code assets in git is (or at least it was for us) not with such assets being large blobs with weird in-git storage model, but with such assets being _unmergeable_ in case of two parallel edits of the same object. 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.
- rmc 10y ago
  > The problem with non-code assets in git is (or at least it was for us) not with such assets being large blobs with weird in-git storage model, but with such assets being _unmergeable_ in case of two parallel edits of the same object. 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.
  - ido 10y ago
    git lfs was buggy/clunky for a while but it now seems to actually be pretty stable and usable. We've been using it pretty much since it was integrated into github.
fsiefken 10y ago
GitLab has built-in support for git-LFS https://docs.gitlab.com/ee/workflow/lfs/manage_large_binaries_with_git_lfs.html https://docs.gitlab.com/ee/workflow/lfs/manage_large_binarie...
- greggman 10y ago
  As pointed out in other comments LFS is not enough
  - fsiefken 10y ago
    Hi greggman, not enough for what? Do you mean usability? gitlab, github and bitbucket provide a GUI to git-LFS. Or do you mean not enough documentation or a technical limitation like maximum file size or check-in/out speed or just bugs?
    - to3m 10y ago
      Needs file locking too. Looks like GitLab sort-of has you covered, though: https://docs.gitlab.com/ee/user/project/file_lock.html https://docs.gitlab.com/ee/user/project/file_lock.html 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.
      - jobvandervoort 10y ago
        You can see whether a file is locked in the UI, but we'd be happy to take any feedback on how to further improve this.
        greggman 10y ago
        You need to know it's locked when you open it. Which means you need plugins for popular software. Photoshop, Maya, Unity, 3DSMax, Blender, etc. 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-graphical-tools https://www.perforce.com/product/components/perforce-plugin-... I've written some in the past as well (http://mayasvn.sourceforge.net/ 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).
INTPenis 10y ago
True and as if perforce didn't have enough of a strangle hold on the industry, it's free for small studios under 20 users I believe. So that would include most indie developers.

gcatalfamo 10y ago

I don't know if this was reason it was posted for, but looking at how the code is structured in some of hose projects is extremely insightful for game making. 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.

ewjordan 10y ago
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.

oneeyedpigeon 10y ago

Quite a few (well, 2 out of 3 or 4 that I've tried) of the project's off-github websites are either domain-squatted or, worse, result in "your computer has been infected" popups. Obviously, that's going to happen with projects as they get abandoned, but I think the compiler of a list such as this one has a responsibility to make sure everything's legit.

Endy 10y ago

I never knew how much I need this. Thank you.

INTPenis 10y ago

How on earth could they miss OpenRTS?

kzrdude 10y ago

Here's another nice once, if you'd like faithful remake of Settlers II https://github.com/Return-To-The-Roots/s25client https://github.com/Return-To-The-Roots/s25client

SticksAndBreaks 10y ago

https://github.com/spring https://github.com/spring https://github.com/ZeroK-RTS/Zero-K https://github.com/ZeroK-RTS/Zero-K are missing in strategy

edem 10y ago

Very cool idea. I've just added my library to the list of libraries (opened a PR).