Running/contributing to an open source project

  • By opening up the Eco source, we're performing a pretty unique experiment. I haven't seen a lot of games do this. So I wanted to tap the community for thoughts on the process and their experience: What open source projects have you worked on? Any games? What went well? What didn't? What would you change?

  • Well, i have only worked on open source projects but they were mostly related to WoW private servers as i used to be heavy into them and ran quite a big one (we won't go into the gray area on that lol). I have done a few of my own through repo's as well.

    This works a little different for us though, because unlike the other open source games anyone could git pull the source code.. While this is open source its only for people at a certain dev tier and above. So our repo's would need to private from guest access right away. Everyone else should get invited to make an account that can only make pull requests against the repo that need to be approved by strangeloop game devs before being immediately inserted into the code base.

    There is a bot integration add-on for slack+github which can notify in a channel of pull requests and new commits. The projects i worked on had well over a hundred volunteers and over a thousand pull request last i checked. It went well there, the system was merely what i explained above except there repo was also open to guests which ours cant be.

    Pull requests are our friend here, it lets the strangeloop devs test all the new commits first you should also hold up a code quality standard so the source doesn't get spaghettied. In the other project they would deny pull requests that did not follow certain code standards. Now you could choose to fix/pretty them up... or deny them and explain they need to clean up the code. Either way its important to have <u>commented</u> code base. Especially when you have volunteers... I worked on MANGOS, TrinityCore, and ArcEmu.

    I didn't really have any bad experience except at first when they didn't used to fully test the pull requests and i would pull in bad code updates to my servers and have to revert or cherry pick out the commits that were wrong or fix them myself. Anything that comes out of master should just work. So really the only key things here is... We need to sign an NDA for code access, The repo needs to be private invite, Everyone should be required to do pull requests and have them approved by a strangeloop dev, And also all code should follow "some" type of standard you set up so the code base doesn't get all horrid and scary looking down the road. It took the TrinityCore project over 6 months to re-work the code base and fix it up to the standards they implemented later on. And that was fixing over thousands of commits.

    Also, Art Assets should be stored in something private like an OwnCloud so it can be on your own server, it can be private and you can set up accounts by invite. Then they can add a WebDAV disk to computer to access/sync the art from strangeloop.

  • My comment is about bug report process, which I suspect is important for modding and open source contributions:
    Box2D has a testing sandbox. As a developer, reporting a bug about Box2D works best if you can reproduce the bug in a simple form within their sandbox.
    This process of reporting developer bugs seems to reduce the effort required by those who know how to fix the framework bugs.
    The typical alternative seems to be, "here is my pile of code, sometimes it does <something> wrong" which will frequently result in finding a bug in the pile of code instead of a bug in the framework. the developer would have likely found the bug in their own pile of code while simplifying the reproduction and porting it into the sandbox, without bothering those who know how to fix the framework bugs.

    <b>What went well</b>: I bothered Erin Catto, Boris the Brave, and Jesse less often than i would have otherwise.
    <b>What didn't</b>: The Box2D sandbox is a little daunting, because it too has unnecessary features when as it relates to reproducing bugs.
    <b>What I would change</b>: It would be nice to provide a bare bones environment to reproduce and report bugs. Perhaps even a "level editor" so that objects can be place in specific position to always immediately reproduce a "sometimes" physics bug.

  • Been trying to build up the dev community around SketchUp. We haven't got that many active projects yet, still early days. But some reflections on what we've experience so far:

    Have clear getting started guides (Even for some of the basics, if only a few links to better tutorials. Open source attracts people with all ranges of experience. It might some times seem like a hazzle to account for the people with almost not experience, but these people, enthusiastic people, can often be quick learners and a great asset if only they are guided a little extra in the beginning.)

    Clear style guides. (I see there are services one can hook up to perform analysis of code style that can help reduce some of the back and forth communication on this topic.)

    Clear branch guide. (Git-Flow or any other patterns)

    Clear guides for level of tests for each contribution.

  • I think it would be very useful for clear guideline for coding style and even if a pull request works it should be rejected on the bases that it doesn't match the coding style.

    I agree with the getting started guide as a lot of unity tutorial focus on using the unity interface rather than doing the same thing in code. The unity interface is great for something simple but quickly gets in the way if you ever what to do anything complicated.

    Git-Flow is great for mid to large teams and having one person responsible for taking a release cut might be a good idea too.

    Also bug reports should be easy to reproduce, with clear steps on how to reproduce.

  • Oh and I forgot comments in code are so helpful :D

  • Yea, at our place we don't give our LGTM in our peer review unless the code complies with the style guides. The style guides also cover comments - don't repeat what the code says, describe the intent instead.

    For C++ we use Google's style guide:
    For Ruby we use GitHub's:

    There are things in each I don't agree with 100%, but that doesn't matter - consistently does. The C++ style guide was inherited from the Google era of SketchUp so we kept when when Trimble acquired us.
    We picked the GitHub Ruby guide because it was a commonly referred to guide among the community. Two familiar guides which increase the change that people have heard or even used them - less friction.

    Not sure what languages Eco uses across the board, but whatever the core team is already using is fine. Consistency is king.

    +1 for clear bug reporting guides. "It does't work" reports is notoriously time consuming to iterate over in order to get to the meat of the issue. Though, it sounds like the majority on this forum are existing devs, but if the bug tracker is opened to all users in general it might be worth some additional Report Bug tool on the website.

  • +10 for clear bug reporting guides. Not a dev, just a tester here. But I know how helpful it is to you guys. It might be worth some of us QA types managing the bug tracker to

    1. Make sure multiple bug reports all get sorted to the same issue.
    2. Make sure all the bug reports make sense and are in clear English.
    3. Have a go at prioritising the bugs.

  • Thanks a lot all. Some great links and things to follow up on here. I think I like the git-flow style, and a transition to git may be in order, if we can sort the large file issue.

  • What are you using right now?

  • they use svn

  • @Mantolwen I highly agree with all of that especially well formed responses on bugs. As someone who's spent more time just trying to figure out what a client even wanted to ask themselves vs making sense of what they already asked / reported an issue on, it can be a lifesaver if the bug report is well organized / has its own monitoring for control. Especially if say a particular bug is reported multiple times across the board we would need to up its priority level of a 'fix' vs a bug reported only once.

    With that said i'm now even envisioning a means of 'up voting' or 'liking' on a bug if someone already filled out the details and you just need to re-iterate it when you came across it yourself (if it still not fixed yet).

  • I just want to add to there comments and say I am super eager to learn Unity to help like many others are, but am not sure where to start, so a "Getting Started" guide would be awesome! I could help put together and design a PDF or something with others if there is interest.

  • Bug reporting is easyer with the full source code. Reason for that is you can Just run the game in debug anddrill into the bug yourself and better can report a bug(tho this also means those having acces need to be able to debug. Bug fixing should be the core devs responsebility

  • Bug reporting is easyer with the full source code. Reason for that is you can Just run the game in debug anddrill into the bug yourself and better can report a bug(tho this also means those having acces need to be able to debug. Bug fixing should be the core devs responsebility

  • Just in case you guys are new to Git, I find everyone has a different way of using it. I'd been console only for years until I started a job at a place with 300 odd devs and GitHub enterprise. Here's some of the stuff we do...

    If it's GitHub then it's generally GitHubFlow, a variant of GitFlow which includes pull requests.

    Learn to rebase your local updates - it makes the history much more readable and will make your pull requests way smaller (when you encounter this pain, you will understand what I mean).

    <code>git rebase -i <target branch></code> will start an interactive rebase (the best kind) by bringing up a textfile with instructions - it's worth just trying it out and seeing what happens (with a test repo).

    <code>git rebase --ignore-date <current base branch></code> will rewrite all of your commits to now so they're all nicely grouped together in the history.

    A lot of people don't seem to twig that any git repo directory is a valid target for a remote - super handy for working on two versions of code or exchanging code without the rigmarole.

    It seems like GitHub Desktop is the GUI tool to use these days. GUIs help because they conventionalise merge, rebase and conflict commit messages. - the console tools for git (hub) flow by the guy who came up with it.
    If you use this, you'll get automatic release notes simply through the way it integrates with Git's tag system and how GitHub presents them. - .NET tools for getting different formats of code version from the git history - super useful for CI

    Change your git text editor and diff tool to something you might actually want to use.
    kdiff3 is decent and pre-configured if you're after a free diff tool.

    Get line endings sorted in a .gitattributes file and get a white-list style .gitignore because it is very hard to get rid of unwanted files once they make their way into the repo.

    PuTTY is pretty key in Windows for not having to enter the password for your ssh key all the time.

  • Thanks for the writeup Seth! So far been loving the github/visual studio integration.

Log in to reply