Magical Girl Shooter - Team

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.

Plugins

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.

Teaching Unreal Engine

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.

Team Management

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.

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.

Assignments

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.

Team Management

Sprint Planning

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.

Version Control Disasters

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.

Code Conventions

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.

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.

Gate

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.

Dialogue System

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)