Greetings, I am Stein and I'm working as a volunteer developer for the Sanctuary project. I've been with the project for the past 2 months, but have been doing programming for 3 years. I'm a self-taught programmer who is interested in game engines and writing high performance code through clean simplicity. I'm also not one for long biographies so I'll get right into the meat of it.
So you might ask, what is a developer and what do they do? Well, the exact definition of a developer is vague, but usually with respect to game development refers to someone who does the programming in a project. In our case, we refer to all members of our team as developers, since we all have a hand in creating this project and often build more than a single part of the overall whole. You can't have a game without code, sound, art or substance.
My role in the project is primarily programming. I work with Lua, C, C# and anything else that the project may require, but I don't only do coding as you'll read later.
The Technical problem
Projects are large and complicated with many different moving parts. As such it's important for everyone to work as a team and not just work with each other, but work together with one another.
To collaborate in this way, each team member needs to know what the other is doing, where work is being done and where effort needs to be allocated; it's something I like to call "situational awareness". However, when more than twenty people are involved, it can be tricky for everyone to know everything about the project.
It's also important for the team to know where they are and where they are heading. Giving a team a sense of direction helps them prioritize tasks and pace themselves, thus progress becomes tangible and is no longer a vague idea team members need to wonder about.
THE Solution
I could obviously ramble on about how important project structure is, but how do we do it?
First of all, you have to keep things simple, practical and accessible. You don't need or want something extremely complicated and convoluted to achieve a good project structure, because nobody will want to maintain it, so we decided to use something we already had and ended up with a milestone and issue ticket system using GitHub.
A milestone is a progress marker. Milestones have requirements before you can reach them, and are only counted as complete when all the requirements are filled. It is similar to a todo list, but I like to think of it more as a trail of breadcrumbs.
Our MVP (minimum viable product) was our first milestone, a very basic version of the game engine. It is based on a list of requirements we created of the essentials we needed.
With our list of requirements for our milestone done, we had set up issue tickets for each requirement. In these tickets you have assignees, which are people actively working on the ticket. You also have the ability to label the tickets with various tags (or stickers as I like to think of them). An issue looks something like this:
Writing issue tickets like this allows us to have a personal todo list viewable by all the other team members. As we complete work on issues, we tick through our todo list, one task at a time, allowing other team members to know the status of a task without having to actually ask for a progress update. We also get notifications sent to us by a webhook.
Additionally, issues can be viewed on a Kanban board, so at a glance, the project manager can look at what is being worked on currently, what tickets are still open and what has been completed. This is what a Kanban board looks like:
Now would be a good time to explain how our workflow works. From viewing the image above, you can guess how the workflow is, but allow me to give you some additional details.
First a developer chooses a ticket from the ticket pool (based on their aptitude and the priority of the ticket) and puts the ticket in the “in progress” column. The developer works and implements the feature, and once the developer thinks the work is ready, the issue ticket moves onto the "Waiting for QA" column. QA stands for Quality Assurance and is where we review each other’s work to make sure it meets our high standards.
At this point, any QA testers can just go to the Kanban board and check this column to find a ticket to test. Once they’ve completed their tests, they either approve or decline the results. If they decline, it returns to the “In Progress” column and the developers fix any glaring bugs or mistakes that need to be resolved for that issue. If they approve the developer’s work, the issue then moves to the "QA Approved" column and from there the developer can combine it into the main project. Afterwards, the ticket gets closed and moves to the "Done" column.
This is relatively simple in comparison to enterprise methods of project structuring and management, but as I like to say, simplicity is severely underrated.
As a small, independent team, using the same project management techniques used by larger companies would reduce our efficiency. There's no necessity to have large and complicated management structures for a team of our size, so we do what works and what makes sense for us. There's many ways to achieve similar results but this style lets us develop quickly and carefully.
I hope you found this interesting and hopefully it gives a bit more insight on the things you have to keep in mind when managing and creating a structure for your own projects. It's not something often taught in schools, but something that becomes very important in the real world for complicated projects like Sanctuary. Thank you, Stein.