For our school project we had to make a game. With a team of 19 people we decided to take it upon ourselves to do the biggest Team Project in the history of our school.
On this page I want to explain my contributions to the team, and showcase all the things I have done for the project.
Do note, this is not really a game, but more of a Team Effort to increase our skills in aspects we chose to learn.
Role: Lead Developer
Team Size: 19 people
Engine: Unreal Engine 5.6
I was one of the first outsiders to be asked to join the project as Lead Developer, as they would love to work in Unreal Engine.
I quickly decided to hop on the team, as I have always wanted to take a leadership role within a Development Team and to see if I would be any good at it.
Soon we recruited people for the team, and we ended with 19 people.
- 3 Developers
(1 lead, 2 Gameplay Devs)
- 7 Designers
(1 Lead, 1 Producer, 2 Narrative, 6 Gameplay)
- 9 Artists
(1 Lead, 2 Freelancers, 6 Game Artists)
For this project I was assigned to lead the Development of the entire project. This consisted of a couple of tasks.
One of my first tasks was to research the best Version Control for a team of around 20 people, that was easy to use and free. I did a lot of research for different types of version controls that had good Unreal Engine integration, but they all had ups and downs.
- Perforce was very expensive, although it did have the best support
- Diversion had a limit of 5 free users, above that was quite expensive
- Plastic SCM was difficult to use for Artists
- Github is completely free, but didn't have great free plugins
Eventually after 2 days of experimenting with each version control, we decided to go for Github with the free plugin, it enabled us to use File Locking (Check in / Check Out) which was really useful with a lot of artists.
Next on the list was the Game Engine to use. We already decided to use Unreal Engine, but what version, what plugins, etc. ?
As this projects purpose was to expand Unreal Engine knowledge, for everyone's portfolio, I decided Unreal Engine 5 was the obvious choice, as it is the newest standard for companies to work with, and thus the best to learn others.
For the version I decided to use 5.6 as 5.6 introduced some new UI elements, and it didn't make sense to teach everyone outdated UI from 5.5 and below.
5.7 was also already released, but it was too unstable at the time, and most plugins also did not have support for it.
For the project I also had to choose what plugins to use. I knew that the Lead Designer and one of the Developers would love to use FMod, so FMod was put on the list of necessary plugins, and it would be put in the control of the requested Dev.
Next of course was the Unreal Engine Github Plugin, as it was needed for Version Control.
The Visual Studio Tools was also added, as it was necessary to code in C++
Last I decided to add my own Plugin (Goldie Plugin) to the project, so I could expand it more while working on the project, as I wanted to learn more C++, and this was a great way to add useful functionalities I could re-use later.
One of my goals was to help others with Unreal Engine, and teach them how it works. As I was most suited for the job, I did an entire lecture at school, and helped people with the setup.
Besides that, I also did a couple of assignments that the team members could do to learn some important features of Unreal Engine, more on this later.
Together with the other 2 Leads, and the Producer, we worked together a lot by planning ahead, prepping the sprint weeks, discussing certain issues like the Version Control being almost terminated and lots more.
Together we were the foundation of the projects success, and we made a solid team!
But this was not my only asignment for Team Management, I was also given the task to create Unreal Engine coding conventions for Developers, Artists and Designers.
My last task was of course coding the game as well. This was sometimes quite a challenge, trying to balance Team Management, helping / teaching others and coding the actual game.
More on the game code later as well.
As stated before, I was in charge of teaching everyone Unreal Engine, so during the first week, I immidiately started planning the Unreal Engine Lecture, which was mandatory for all the Team Members, and students from our school were open to join.
This lecture was about an hour to 1.5 hours long, and it included everything there is to know about the basics of Unreal Engine, from Variables...
Event Graphs with Functions and Macros...
To explaining why to avoid casting when necessary
At the end of the lecture was a small Kahoot, to motivate people to write down as much as they could and listen to the lecture.
I later got a lot of compliments for the lecture, and I am pretty proud of helping so many people with laying a foundation to using Unreal Engine.
Then there was another way of teaching everyone from the team how to use Unreal Engine. These were little assignments in different categories, Easy, Medium and Hard.
Easy and Medium were mandatory for everyone to make. Hard was there to challenge yourself and increase your skill, which some team members did amazingly!
In total I did 2 assignments as a lot of people already knew quite a lot by then with the Unreal Lecture and the assignments.
Later on, people from outside my team requested to get the assignments as well to help them out with Unreal Engine.
Most people within the team got a much better understanding with Unreal Engine, and I am proud of the work they have accomplished, as well as my own skills in teaching them.
For the Team Management our main task was to keep the project rolling, and keeping each sector (Development, Design and Art) working together to make a good end product, and most of all, learn how to work in a big project.
To do this we applied a Scrum working method to work in sprints of 2 weeks (5 times) to reflect upon each sprint and improve on the next.
We did alter the method slightly to work better for our team project.
Every weekend just before the sprint end, the leads and producer would sit together to make a new sprint planning based on the Amount of People * the Hours they had available, with a margin of 80% work time.
This gave us the planning hours to plan ahead with certain features, models or documents we wanted to have ready by the end of the sprint.
We would then work on making categories, adding priority, and tuning tasks to work between sectors so that it all went smoothly.
During our project we had 2 massive issues, that being a shutdown of the version control, and the entire project being almost perged.
While developing for a week or 2, we suddenly found ourselves unable to push to the Github. We discussed this as Leads and Producer, and we decided to use Github Business as it seemed free, and we could use a slightly bigger GIT LFS limit (As this was the issue).
However a couple weeks later I got an E-Mail that the Business Account we set up for Github (to use a larger Git LFS amount) would end within a short period of time. On Reddit we then read that the entire project would be wiped when this happens.
To avoid disaster, we sort of called an "Emergency Meeting" away from the Team to not give the entire team a panic alert, and we moved to a secluded room to discuss this issue.
After about 30 minutes to an hour, we decided on moving the project back to my account, and to invest €5,- into the Github for December, as well as another €5,- for January, this gave us just enough room to finish the project with Git LFS, and avoid panic.
For this project I had to make Code and Asset conventions for everything in the game, which is quite a difficult task, cause you have to take every discipline into account. Developers need to have an easy way to code, Designers need to understand that code, and Designers and Devs also need to understand the way assets like animations are organized.
So firstly I decided with the team to color code each sector / discipline.
- Development would be Yellow
- Design would be Blue
- Art would be Green
With these colors it was easy to seperate both the Scrum board, as well as code conventions and other things in documentation.
So I immidiately began with adding Unreal Engine Conventions, starting with the most important things like Blueprints, Levels, Input, Player Controllers and much more, mostly for Developers.
These are the conventions for most Developer things I came up with. Most of them are default Unreal Engine conventions, like BP_ or BPI_, but there are also some I just made out of own experience, so that every single type had a unique prefix (Input_, Controller_, Gamemode_).
Then Design, was next, Design was a bit tricky to categorize, cause most things in editor would be seen as either art or development. But I decided that some specific types would fit Designers slightly better.
Types like Levels, Level Sequences Widgets and Foliage is something a Designer works a lot with, especially with Level Design, which is most common for a Designer in the Game Engine.
Some could also be categorized under Art like Foliage or Level Sequence as it could be seen as Trees are models, and Level Sequences is Animation, but personally, I thought this fit better.
Then lastly onto Art, which was the biggest challenge, cause there are so many different types when it comes to Artists.
As you can see there is a lot going on, with many different types of materials, animation types, particles and textures.
While making it we luckily didn't have to change much, every now and then we wanted to use an Asset Type, and it was not in the conventions yet, this is when I would update the conventions and let it be reviewed.
We also decided to print the Unreal Engine Conventions on the wall in the office, so that everyone could see them, and they did not have to look through our Notion every time.
Lastly coding the game, this was probably one of the less interesting parts, as I already knew how to code, much better then I knew how to lead a Team, but it was still an exciting challenge to face, as I never developed in such a large team before.
The Designers had worked out different types of Player Movement for their 3C's Controller, they were all completely different with different mechanics.
Once those were done, the Lead Designer stitched all the good parts together into 1 massive Player Controller that was just coded in a way to feel nice, but not work nice.
I was given the important task of refactoring that Character Controller, and optimizing it where needed, like implementing an expandable double jump system, that was not hard coded and could easily be changed at runtime or by changing values by Designers.
Also the Lead Designer requested that I also add some extra features in from other characters, and over time the blueprint slowly grew bigger (Hence the size difference).
Final_3Cs (Design):
Player Final (Development):
Overall, I am extremely proud and exciting that I was able to work along side such talented Game-Designers to make this Player Controller a reality.
The gate was a fun Blueprint to work on, and also an important one. The Gate was used to stop the player from progressing at certain points until they perform a certain action, or to block them off from a certain area.
By adding some parameters, Designers were free to reuse this as much as they needed. I also made the gate scalable by multiplying the Distance it moves by the Scale of the Actor.
One of the first systems I actually made was the Dialogue System, that was needed for the Narrative of the game created by the Narrative Designers.
To do this I made a Widget that shows the dialogue that was given to the Widget with the name of the character saying it (if any).
After coding the widget, I needed a simple way for Designers to create a Dialogue Popup anywhere, which was easy to do with Macro Libraries. This 'Create Dialogue' node could then be used anywhere in any Blueprint.
To make it even easier for Designers, I decided to make a BP_Dialogue that has a triggerbox that automatically triggers diaogue set within the Blueprint.
(You can make an entire sequence of Dialogues in this)
The Lighting Transition is made between zones. You start in the "Safe Zone" and the first zone you enter is the City, but the lighting is completely different between the 2 zones, the problem being, they are in the same level.
So to not have an instant light change, I made a Trigger Sphere with a Spline in it. Once the player enters this sphere, it will start checking the nearest point on the spline from the player.
The Start of the Spline will return 0, and the end will return 1. This can make an extremely smooth transition between 2 points, that can be easily changeable and reusable.
This game was an insane challenge to take on, going from a team of just 4, to 19 people, and having to manage a dev team, managing the technical side of the game, teaching others and coding on the game.
But I have no regrets of participating in this project. I've learned a lot about how people learn, and what steps would be best to start with, thanks to the assignments, where people sometimes find unique ways to solve tasks that I did not intend.
Most of all, I learned a lot about being in a leadership position together with a couple others, managing such a large team, which is something I have wanted to learn for years, and I was finally able to do that. At the end we had a beautiful product to showcase, thanks to the amazing talented team of Artists, Devs and Designers, and of course the wonderful leadership of the lead team.