I was a mentor for a 5-person FYP team, who just finished their project on the last week of August 2018.
You can preview a trailer of their game here:
Bizarrely, this is the fourth Combat Arena game project I have mentored in a row. While it’s a sensible choice for a two-semester project, I have to point out that I did not decide on the game itself; it’s the student teams that came up with the game concepts. My role was to mentor and get their project done.
You can preview details of the first two Combat Arena FYP Projects – Dark Circuits and For The Gods – here: https://www.hilmyworks.com/incomplete-teams-managing-student-projects-with-incomplete-skillsets/
The third one is The Immortal which was finished on April this year.
https://khookhailun.wixsite.com/immortal
Initial draft title and blockout.
Semester One: Project Mockup and Prototyping
The team JADAX (name made of initials of the members’ names) proposed an arena slash-em-up with an 80s neon aesthetic.
An odd quirk about them: they’re three programmers + two artists with no designers. Apparently, they found themselves to be last people to pick a team, thus they found each other and jury-rigged a concept.
Project started on January, where they did visual mockups of the idea they had in mind, and for the next three months they researched on how to implement the concept each wanted to do.
Progressive updates from January to April
Since they have no designers, I de-emphasized the need to come up with a gameplay plan: their lack of experience in game design would mean they’d do more work than necessary. They were instructed to capitalize on their strengths and work out what is it they want to achieve with this FYP.
One programmer wanted to create procedurally generated content, and he settled at making the weapons generate during pickup. Image on the right (above) shows the base prototype weapons that were generated block-by-block.
To test this, another programmer used Mixamo free character animations to see how the generated weapons would look in play (because the animations by the animator will only be done months later). They also did this with discussion with the one of the artists who wanted to make bendable weapons a la the smear style animations in Overwatch.
While student projects tend to focus on building the game, I emphasized that teams of new people have to figure out processes on how to work together, and not take standard processes for granted. After all, it’s the understanding of what could go wrong that would allow them to fix problems effectively when things DO go wrong.
For example it’s easy to take Git for granted. However, a previous FYP group I mentored discovered that Github isn’t usable after a certain size limit, thus they migrated to Gitlab, which for some strange reason was blocked on campus. That team adapted by using a neighboring building’s Internet, and hey, grungy solutions worked for students.
This team worked a whole semester understanding Git’s quirks. They found traps in the processes – moments when merges won’t work, how Blueprint isn’t backed up by Git – and that understanding allowed them to come up with a development pipeline that avoided the traps. One programmer identified the workflow needed to merge all updates together into a working Build, thus she instituted a rule where for any Builds to be done, a lead time of 20-60 minutes need to be allocated to merge, check for Build issues and Build successfully.
It’s not perfect, but it meant most of the time their build process was reliable and that investment allowed them to focus on fixing the game’s issues in the next sem. This work was also what allowed them to reliably show their Builds to external parties anytime they needed to. Which I had them do quite a bit (more of that later).
By early May, they have worked out test materials and settled on the scope of their Arena. Thanks to the Unreal default character and downloadable Mixamo animations, they could test out their proposed fight mechanics and effects along with the weapon generation feature, while at the same time the artists continued building future game art assets.
By the end of their first FYP semester, they already have a rough build that was presentable to people. Since this is the point where they move from research to production, it’s a good time to bring outside perspectives in. This is also a good opportunity to get them to practice presenting to industry professionals.
Semester Two: Production and Public Testing
A little aside before talking about JADAX’s production.
KDU students are required to do presentations to industry professionals at the end of their FYP project. I felt however that in order to for the product to be good, presentations to industry professionals has to be done earlier. Feedback is only useful when they can be applied to do changes, and it is more helpful to bring professional advice early in a student’s project, as opposed to at the end.
July 23rd build with dynamic background effects.
I tested this theory a year earlier by arranging to bring an FYP team – whom I was mentoring on the Production and Worldbuilding side – to meet with LemonSky staff on July 2017. The Studio staff were gracious enough to allocate their staff’s time at their Studio to give their professional commentary on the students’ work. This was fruitful as the experienced staff were able to point out to the students what needed more work and what was done correctly.
Team Yellow Chicken Conspiracy's sci-fi horror game "Terminus Lockdown" wins Best Student Game at this year's Level Up…
Posted by UOWM Game Development on Wednesday, October 31, 2018
That team’s game – ‘Terminus Lockdown’ – won LevelUp KL 2018’s Best Student Game. Congratulations were in order! Of course I didn’t know that was going to happen when I was mentoring JADAX, but I knew then that bringing students out to meet professionals early in development did produce results. So I made sure JADAX got as many external feedback as I could manage.
On May 7th, I was able to ask Wan Hazmer of Metronomik to meet the team and check out an early Production build of their game. From this meeting, they got an initial outsider proposition on what could happen to their project and what features could be worth working on. This was during their semester break, so this meant the team was able to consider Haz’s advice before starting Production.
On June 5th, Chris Murphy (Unreal Evangelist) was in town. Was able to get him to meet the students at a Starbucks for him to check out the game and provide feedback. Do note that asking an external party to check out a Build that doesn’t work would have been pointless, which was why JADAX’s instituted Build process rule was useful; the Build programmer made it clear last semester she required invested time to ensure the Builds work, and we made sure she got the updates and enough time to confirm a Build before meeting these professionals.
Semester 2: Production and Bugfixing.
A feature one of the programmers wanted to focus on was enemy AI: making an opponent that could be varied in action/reaction based on what the player does. By June, he managed to get a playable version of the AI working. Along with refined materials for the environment, the game looked and played a lot better.
For Production, I emphasized the need for weekly builds, and that each build need to be tested. As I found out from designer prototyping, regular testing generates wonders in game quality.
A key point here is that they should not wait for the results from the test to work on the next build.
This reflected the process I went through in GameBrains; when we sent a Release Candidate – call it RC7 – it will take a few days for testing to be done and the devs would have nothing to do if we waited for the results to come back. So while RC7 was tested, the devs worked on RC8, and when the results from RC7 comes in, we’ll send out RC8 for testing and start on RC9.
Usually, there are always bugs to fix even after releasing an RC, so finding new stuff to fix without waiting for the test result isn’t a big deal. When the test results come back, we’d just compare the bug reports with any new issues that we fixed, and if it so happens we fixed an issue the publisher noticed, GREAT! Any new bug fixes requested is then simply added to the new RC to be built.
The reason I bought this process in for student FYPs was that students tend to panic over bugs in their games. There’s a tendency for them to crunch to fix newly discovered bugs, because they felt anything shown during a review needed to be perfect. The need to have a ‘perfect show’ meant delays in delivering need-to-be-perfect-work and late nights doing ad-hoc solutions.
Adding the deliberate delay meant the team could relax, and plan fixes properly. They can check how many iterations they have left, and plan on how to develop the next weekly build that would fix the most important issues they noticed. Since the builds are weekly, new issues will be handled on a weekly basis and discussion are always delegated to the end-of-iteration meeting, which meant they could focus on finishing their features in each iteration.
The requirement for weekly builds has a bonus: if any disaster occurs, the team would only lose at most one week’s worth of work.
I would have wanted the cycle to be tighter, but students work by weeks, so once a week is the limit.
By the 23rd of July, the game now has the look-and-feel down in-game. That sweet, sweet Miami 80s sunset.
One artist figured out how to do dynamic soundtrack (having the music change according to the state of the player+NPC). To his credit, he figured out how to do it with Blueprint within one night. With that in, the programmers could figure out how to connect visual events in-game with the music state, thus the environment by then has events that sync with the music.
Team added a TV to the arena. One reason we added this was that a fighting game needed to be a spectacle to capture the audience; while the player knows what’s going on, the game has to work on informing the audience and keeping them interested to watch. This way, the game will not just entertain the player with gameplay, but also engage anyone watching (with the hope it’ll interest them in trying the game out.)
The JADAX team showed the state of the game at Jeremy Choo’s Unreal meetup at the end of July. Jeremy did point out to the team that their current build is resource-heavy: it has realistic reflections on the ground and it renders another view of the game on the TV screens.
.
By the 21st of August, the game is done as an FYP project. The game was shown at the KDU Public Playtest on August 20th. The team noted one player played the game up till 45 mins just to make sure he beat the game.
On August 24th, I arranged for Wan Hazmer to meet the JADAX team again, and his time he brought members of his company with him.
Falk, an audio engineer collaborating with Metronomik checking out the dynamic music feature while a Metronomik programmer played the game.
The Metronomik team took turns trying the game out and providing advice to the graduating students. And it must be said; at this point my Mentorship of the FYP students was done. I have guided them throughout their development, allowed them to get feedback from industry professionals early, and was able to show the same professionals how the students could progress in their development while guaranteeing delivery of their project. Life goes on.