I’ve been enjoying collaborating with my friend this month. When I work alone it takes forever to get anything done, so an extra person adds virtually double the output.
Despite having extra manpower, working together can cause some problems if you aren’t properly prepared. I’ve made a list of 5 things that I think are essential for holding a small, 2+ person project together.
1. Keep a Shared To-Do List
A to-do list should be the first thing you set up for your project. It allows you to work more efficiently with less confusion and divert important tasks. You can gauge how much work you can realistically get done in a set time-frame and plan accordingly.
My project partner Ferdi and I have been using Trello to plan our intended fixes & changes. It’s awesome for getting your ideas and priorities on a shared page. If you run into an urgent bug that the other guy needs to fix, throw it up at the top of the to-do list.
For the first week he did all networking-related tasks and I did all gameplay-related tasks. We made it clear that we would be working only on our group of tasks and wouldn’t touch the other’s. The completion of our own tasks were not dependant on the other person’s progress.
We did not sort the priority of tasks according to how urgent they were. Certain network tasks HAD to be completed to allow for gameplay elements to be implemented, and vice versa.
See, Ferdi and I don’t work the same days or the same hours. We just work on the project. I have my KanBanFlow time-box schedule, and he has his schedule. Sometimes I do my entire week of dev work in 3 days instead of 5 or 6, and I happened to do that this week.
I got way ahead of his week’s schedule and became unable to progress because he hadn’t finished his task yet. Oops…
We ended up immediately cooperating on the task for several hours to rush it to a finished state so I could continue working. Ferdi was up until 6AM his time. He was equally as loopy as he was cranky, but he got the job done.
Moral of the story:
Prioritize your tasks & communicate how soon they have to be finished!
2. Back Up Your Project to a Shared Location
Back up your project. BACK UP YOUR PROJECT
This isn’t a joke. This is priority #1. This needs to be set up before you begin your new project. I’ve seen tweets from developers complaining about losing days, weeks, even a month (!?) of progress because they didn’t back up their project.
I’ve always backed up my practice projects once a day using Google Drive. This can be okay for a while, but a serious project needs more than a daily copy/paste to the cloud.
Ferdi is a big fan of Git & GitHub, so that’s been our backup tool of choice. It easily beats my old way of backing stuff up. Here are some of the pros of Git:
- It’s easy to backup frequently
- It has a ton of ways to document all details of your changes made (You can also view line changes on GitHub!)
- It’s easy to merge two instances of the same edited script together
- It’s easy to revert to an old version
- jIt’s useful for checking if your partner has recently made any changes and what they were
- It works fine with Unity assets and files/folders
Also, consider investing in a UPS if you experience power outages from time to time.
3. Create a List of Project Standards
It’s important to try to be as clean as possible with your project. It isn’t enough to just write clean code when you’re dealing with a file structure, engine objects, and hundreds of assets.
At the very least you should make some guidelines to adhere to. Ignoring even small naming standards could quickly have a butterfly effect on your project. You might end up with a mess that will take many hours to clean up because you didn’t take the extra time to plan a standard and adhere to it.
Here’s a quick example of something I’m about to make a rule for tomorrow.
Recently Ferdi has been testing a lot of things with our Unity scene. Every time he wants to test something completely new he creates a new scene for it.
One night I had to test a networking feature in Ferdi’s networking scene (I thought he had 1 networking scene). I opened the folder and saw this. Keep in mind we have ONE real scene.
I ended up losing 90 minutes of work because I was attempting to get a server running in the wrong networking scenes.
4. Quality Assurance
My brain is developed to pull a fast one on me a few times. Ferdi also happens to be designed to pull a fast one on me. We are humans, we make a lot of mistakes. We can’t perfectly adhere to the standards. This is what Q&A is for!
Cleaning & tidying up your project should be a regular thing. Every week I spend around 15-25 minutes reviewing the project in general to make sure everything is clean. Sometimes I’ll find a mess that doesn’t fit the project standards, but wasn’t fixed.
You should be documenting everything you change in the project. Your partners are going to usually need very specific information as to what and why something is created/changed, so be verbose if you need to.
In our project we type our general changes into Git & we keep a check list of bugfixes in Trello. At the tops of our scripts we have version numbers, dates, authors, and lists of all changes made to the script.
Ferdi and I also hold a code review every so often. A code review is a harsh scrutinizing of each other’s code in order to better the project by creating a cleaner environment. This minimizes potential mistakes from either of us. Things to critique include:
- Proper authors, dates, versions, & versionlist details
- Names of methods, classes, variables being written in clear and proper english
- Names of methods, classes, variables having consistent naming
- Parameters, return values, exceptions written clearly
- Documentation of the script & how it’s intended to be used
The code reviews have also taught me a lot of good habits that I can apply to my solo projects. Sometimes I get weird habits that just developed for no reason, and until Ferdi pointed it out I wouldn’t have thought anything of it.
5. Keep in Touch (Meetings)
It’s very important in a multi-person project to plan out what everybody is going to be working on for a timeframe. If you skip this then you can easily fall behind schedule or waste time.
Ferdi and I have a weekly conference call where we come up with more ideas, discuss our current obstacles, & plan all of our work for the week. This is our only scheduled weekly meeting but we have a lot more depending on what we run into.
If you work at different times then it’s also very important to have a constant means of communicating with each other and be “on call”. There were a couple times last week where I was dead in the water until I could call Ferdi.
Ferdi and I have always frequently chatted about games, so we already had heavy communication before we started the project. This let’s us have an “open-door” IM/text with each other. We can message each other 24/7 and get a reply (if awake). This has proven to be a lot more useful than I thought it would.
If you liked this, please like & share it on your preferred social media.