This is the start of a series of blog posts about onboarding onto a new game: Frog Bath. Described by our lead designer ( https://www.linkedin.com/in/leonardo-robles-gonzalez/ )
“A couch-competitive “Capture-The-Soap” platformer that offers an approachable, frog-like movement system with nuances to allow for mastery over the game’s mechanics. Players control cute frogs obsessed with hygiene and want nothing more than their Frog King to be as clean as can be. In doing so, they end up competing against one another to give their Frog King the best and fastest bath possible. The game has competitive complexity due to the mastery available from the movement systems, but can be enjoyed by more casual players thanks to the silly theme, approachable surface-level gameplay, and the innate social nature of the game. “
Frog Bath was developed in Unreal which is great because it will give me more experience working with C++ and Unreal. It will also give me more experience to figure out how to work well with Unreal and Git. The team is awesome with some great developers that I’ve worked with on previous projects. However, with the team size more than doubling to 12 people there will inevitably be problems to overcome.
The first problem was immediately obvious. The Git repo took 10 minutes to clone. Now if you’re working in industry I’m sure that sounds great, but for a one semester old school project it should only take a couple minutes at the very most. When I started to dig into the repository there were obvious problems. For one, the .gitignore file was copied from Github and placed in the root of the repo without modifying any paths. This meant that whole folders like Builds/ and Intermediate/ weren’t actually getting ignored. Second, there was an Art branch which contained not only both zipped and unziped maya and photoshop projects, but also an additional unreal project for testing art.
To fix this we just set up a new repository and copied over only the Unreal project. I also edited the .gitignore to correctly ignore everything that it was supposed to. This cleared up over 4.5gb of unnecessary files.
There were also no conventions around Git as far as I could tell. The current working branch after 12 weeks of work was week4-(programmer’s name). We are planning to move forward roughly following gitflow as described at https://nvie.com/posts/a-successful-git-branching-model/. This includes naming branches after the feature and using meaningful commit messages rather than ones that could be from http://whatthecommit.com/.
The art files proved to be a problem, especially the full project files which could be over 1gb on their own. We’re currently trying a separate art repo that they “can do whatever they want to” with. This means that the art pipeline to get art into the game is to pull both repos and copy the files over in File Explorer. This is less than ideal, but is a step up from the previous art branch which had the same pipeline with the added steps of copying files to the desktop in between switching branches because merging wasn’t an option.
How did this mess of an art branch and bloated repo happen? I’d love to blame it all on Champlain College. Git is expected, but not taught. Out of the senior game programmers I think there are only a few of us who can do more than pull / push / commit. However, it’s not hard to learn git on your own over 3 years. I don’t think it’s unreasonable to expect teams to figure out their own workflows. But it would be great to have at least a little help to avoid the absolute mess that teams make work because they don’t know of a better option.
To test my earlier assumptions I asked the senior programmer chat to take a quick and very scientific pole to get a better idea of how well people can use Git.
On the upside no-one said they can’t use Git at all. On the downside, more than half the responses are what I’d consider minimally competent with Git.
Going forward with this new team I will be filling the role of repository manager and cat herder when it comes to Git standards. I’ll also get to do whatever programming tasks don’t fall into our other programmers specialties of AI and networking.