2025 Capstone Post-Mortem

About this article.

Heyo! My name is Sebastian Poutanen, I was the producer, game designer and generalist for our capstone team, Team E-Motions. I just wanted to start this by giving you a clear idea on what you'll find and won't find in this article. This article is first and foremost:

A perspective of what me and the 7 other talented game developers in my team have learnt in the 8 months of making our steam released game Roman Rumble for QUT BGIE capstone 2025.

As a team, we're proud of what we've made, flaws and all. Although it might be easy to blame shortcomings on unforeseen circumstances, which would make this a really short and boring article, blaming on factors that we can't control provides no room for growth. Plus, some of these factors can be easily prevented or mitigated, but more on that later.

At the end of the day, I wanted to provide some of our learning experiences, even if it was just a single team that ended up more prepared or more confident for their own capstone experience, as a result of this article, then I'm happy. Through the best of my abilities, I'll try to communicate key take-aways through diagrams and demonstrations. Thank you for your time!

From Humble (and Eager) Beginnings

At the end of 2024, the year before we began the development of our final game for our degree. We practiced as a team on 2 separate game jams, it was a lot of fun and we learned what each other's skill sets were and what skills we lacked as a team. We used the Unity Engine, as it was the engine we're most familiar with. We used it throughout our degree, so we knew about what we could and couldn't do with it. However, when we're given a choice on which industry partner we would like to work with, we ended up deciding to work with PlaySide. They would be giving us mentoring on a regular basis, which helped us massively in the long run. The brief we knew we're getting into, gave us full control on what game we wanted to make, it just included one small detail. It had to be made in Unreal Engine 5…

As tempting as it may be to pivot into the first key learning point calling it "NEVER work in Unreal Engine as 8 inexperienced game developers". As funny as that is, we knew that we hadn't made a game in Unreal Engine before, we welcomed the challenge anyways. Did it mean that all of the preparation went through the window? Not necessarily. We were able to transfer our prior knowledge to the engine, we just needed to learn its tools and quirks.

So instead, I’m going to focus on the outcome of our learning experience from game development as a whole. So that you can still find this article useful, regardless of the engine. From how you can approach the initial planning for the project, to risk mitigation strategies to help create a smoother development. After diving headfirst into development, excited to prove we could handle Unreal Engine, but we didn't spend nearly enough time nailing down what we were actually building. We wanted to learn what the engine could do as soon as possible and test our game ideas, cause we knew that getting feedback was important.

Now for our first actual learning point...

Plan extensively early-on

Planning a large portion of the game early-on mitigates risk, risk that could take the form of large pivots or not knowing how to respond to feedback. Some of the feedback that we’re given, ended up changing pretty important features of the game. Because we didn’t have solid guiding principles, ideas from playtesters seemed more justified than our initial ideas, but if we had identified why our ideas worked in the larger context of the game. We would’ve been able to filter ideas from feedback a lot safer. I mean, it’s an innocent mistake, if given the goal “ perfectly plan the entire game from scratch”, where would we even start? Some ideas might look good on paper, but they could have flaws when tested in the game engine. So, here are some suggestions that could help with the design process:

Design for "moments"

To help you map ideas, you can imagine games as "moments", that appear to the player one frame at a time, at many frames per second. Thinking about games in this matter will help you understand what emerging emotions need to be achieved, and most importantly what features make them happen.

Ask yourself: What does the camera look like? What are the interactions required to set-up this moment? How does the interface reinforce this moment? How should the player react? What sounds are happening in the scene?

Planning for moments gives you production goals that help shape the rest of the game, like designing a way for players to repetitively experience the moments (Game Loops), or what mechanics or juice would help achieve the right amount of oomph for that "moment".

Our Experience with Combat Design

One of the first meetings we had as an official team was listing what genres are off the table. A lot of genres out there are way too complicated or too risky for a small team to get into, from MMOs to Tactical FPS. Know that if you have a genre selected, you should fully understand what makes the genre work and what systems are required. Don’t just look at the surface level features, dive deep to the polish, the visuals and how many different games approached it. Here’s what we’ve learnt from making our combat system.

To give you a quick rundown, we wanted to imitate the combat experience from God of War (2018), what the developers call the "plow through snow" feeling. But we wanted to add a goofy spin to it, replacing gruesome executions with comical corpse launches and over-exaggerated finishers like you'd see in wrestling.

We learn that some of the most important features don't just come from Kratos' axes swinging animations or enemy variety. In my opinion, a vast majority of God of War's combat depth comes from features that might be hard to notice at a first glance. However, if you look at combat footage frame by frame, play a ton of the game, or do research into its development. Features like freezing impact frames, sucking to targets after each swing, or subtle AI movements. Tend to have a huge impact on how the player experiences the system, but take a huge amount of time to get right.

A Fair Warning

Be very careful when looking at other games for direction, understand that you’re a small team of developers that have time constraints. Replicating ideas from an existing game, one that had a team of 240 people behind it, could add way more time to development than initially planned. I'm not saying never reference existing games. But understand that different visions require different plans, and your core moments should drive those plans. When you reference other games, use them to understand why their systems worked and were fun, and what makes a good plan in the first place.

Create visualised designs

Communicating your ideas can be a long and arduous process. However, doing a more visual approach to game design can help this process. Whether it's using diagrams, image editing, sketches, screenshots with annotation, all of these options can help you compare and test ideas a lot quicker and more effectively. Here are some examples with screenshots, note that the examples aren’t perfect, but does help with communicating ideas:

How animations can be planned with diagrams and sketches

Without visual guidance, artists will struggle the most when they try to make art that works with the mechanics for the game. As an example, for an attack animation, details like anticipation frames, impact moments, and recovery phases. Can be made into a diagram like the one seen below. When sectioning an animation in a timeline, you can see the general timing of the phases(wind-up, contact, recovery), when it starts/ends, or what could happen after. Programmers can also benefit from understanding the timing of features like input buffering if you label when it should happen. 

Flow Charts: Understanding the Loop

Flow charts became one of our most valuable communication tools, especially for mapping out game loops and system interactions. When you're trying to explain how a round of combat flows from start to finish, a paragraph of text becomes confusing fast. A simple flow chart showing "Player spawns → Enemies appear → Combat phase → Victory/Defeat → Reward screen → Next round" instantly clarified the sequence for everyone.

These diagrams also helped programmers, flow charts revealed the actual logic they needed to implement. Whether it's demonstrating what the player can and can't do during attacks or how the combat loop starts and ends. For designers, flow charts exposed gaps in our mechanics. Allowing us to understand what we were lacking and explore "what if" scenarios to help refine our ideas.

Flow charts also helped us identify what assets and interactions were actually required. When you map out "Player performs finisher → Trigger animation → Play sound effect → Spawn particle effect → Launch enemy ragdoll → Display score popup," you create a checklist for every discipline. The animator knows they need a finisher animation. The sound designer knows they need impact sounds. The programmer knows they need to trigger all these systems in sequence.

The key was keeping them simple. We're talking boxes, arrows, and basic labels, not complex UML diagrams. A whiteboard sketch often worked better than a polished flowchart because the goal wasn't documentation perfection. It was a shared understanding of how our game actually worked, moment to moment.

Time is always shorter than planned

This is one of the most repeated pieces of advice in game development, yet it remains valuable.  Understand that learning about new features adds a ton of time from reading, testing and fixing.  Every feature should carry a hidden cost of "learning how to approach this system.". Pivots are common in game development, so understand how you can develop tools to mitigate them.

Know that your final month should be spent on polishing. To help achieve this, I recommend planning your initial timeline, then reduce your feature set by half. Evaluate if it's still ambitious. If so, reduce by half again. Target completing your vertical slice (genuinely complete, genuinely fun, genuinely polished) by the halfway mark. By week 14, you should have something you'd confidently demonstrate to anyone.

Additionally, schedule dedicated buffer weeks. Reserve 1-2 weeks explicitly for catching up on delayed work, with no new features planned. Work will fall behind schedule. This is a pattern to plan for, not a failure to avoid. When learning a new engine simultaneously, consider doubling these buffer periods. The compound effect of learning while building makes traditional estimation even less reliable.

Key Insights: What We'd Tell Our Past Selves

After 28 weeks of development, countless iterations, and one shipped game later, here are the core lessons that transcend our specific project. Whether you're working in Unreal, Unity, or any other engine, these insights apply.

On Design and Scope

On Communication and Planning

On Time and Estimation

On Scope Management

What These Lessons Actually Mean

These aren't just nice-sounding principles. They're specific, painful lessons learned from watching our timeline collapse, rebuilding systems multiple times, and cutting features we'd invested months into.

The connecting thread? Clarity prevents chaos. Clear moments prevent feature creep. Clear visuals prevent miscommunication. Clear, realistic timelines prevent crunch. Clear scope prevents burnout.

You'll still make mistakes. You'll still underestimate tasks and overestimate your capabilities. But if you internalise even half of these lessons, you'll make different mistakes than we did. Better mistakes. Smaller mistakes. The kind you can recover from.

The Most Important Piece of Knowledge

You need to stay healthy, both body and mind. You as an individual need to rest and eat well. I'll use working out as a similar experience to show why developing the game is sometimes not the most important task in game development.

When you lift heavy weights or do any strenuous activities to build muscle, that activity won't actually build any muscle. It tears your muscle fibers, which triggers a process of repair that will build them to be stronger and larger. If you are constantly tearing your muscles without allowing your body ample time to repair, the chances of injury during a workout increases a lot, because you're trying to do the same level of effort with a severely exhausted body.

In game development, resting can be especially difficult to do. When you have the dopamine of a great idea, or the endorphins from being in a locked in flow state of development, taking yourself out of the mindset and catching a break is often an uphill mental battle. You're fighting your passion for the game idea or you're just so close to finishing a cool mechanic or animation.

I'm very guilty of doing this. I still struggle in giving myself breaks. During the development, I just kept pushing myself and had little to no breaks. I had the feeling that if I wasn't constantly on my A game, I was letting the team down. What resulted was stress and exhaustion that carried with me on the 1hr bus home, or sleepless nights at 2am. The stress caused stupid ideas like "maybe we should switch to Unity", when we were almost halfway through development.

The burnout eventually hit me so hard that I couldn't do anything related to the development for 2 weeks, so I had to offload my producer duties to a team member that was able to help, just when the release was a month down the line.

Allocate yourself time to not work on anything. Don't even think about the game. If you are struggling, let your team know. Everyone wants to do their best in making the game, but they also want to make sure you're ok.

Know that no matter what you make, be proud of what you and your team were able to achieve. Game development isn't easy, but it can be fun. So enjoy the time you spend making the game, don't worry about the outcomes. This isn't going to be your last game, so if you keep striving to learn and improve after each experience, everything will work out. Because all is well.