Two university projects, two awards - and both were for the process, not the product

The first thing that was actually mine

For a long stretch of a CS degree you only solve problem sheets. Analysis, theoretical computer science, sheet after sheet, and none of it belongs to you. The software project was the first module where I could actually build something of my own - and that changed everything. It was so much fun that I voluntarily stayed up through the night to keep building new things.

That sounds like a platitude, but it’s the first honest factor behind the two awards: motivation beats prior knowledge. I was no expert. During Starfighter Alliance I sometimes didn’t even know how to get an instance from one scene into another - an absolute basic in Godot. A finished game shipped anyway, and the university awarded it best individual project.

The award didn’t go to the game

Here’s the part many people get wrong. Nobody graded who delivered the prettiest or most complex game. The main criterion behind the awards was the software engineering itself: the process. Specification, planning, version control, traceability. A perfectly polished product with a chaotic history behind it would have lost.

Once that clicked, I took the process as seriously as it can be taken.

Requirements are the floor, not the ceiling

We had rules: work in GitLab, set up a CI/CD pipeline, use labels. Most people tick those boxes and get back to the “real” project.

I went completely over the top with it - in the best sense. Instead of default labels, a label system with actual thought behind it. Instead of a pipeline that merely exists, a CI/CD set up from several angles. Commits written to one fixed standard, every single time. Everything that belonged to the process got treated like a feature: how do you extend this properly? What’s the good solution here instead of the sufficient one?

The effect worked in two directions. Outward, every decision was traceable - read the repo history and you see the path. And inward, the structure carried me exactly where experience was missing. When you don’t yet know how to build something, a clean process is the railing you work your way along.

Battlefront Tactics, the team project two semesters later, was the same attitude at scale: real Scrum across the full runtime, sprints, reviews, retrospectives. Not ticked off as an obligation but treated as the actual craft. First place at the Software Engineering Award, plus second in the AI tournament.

What you can take from this

If your software project is still ahead of you, the short version of my experience:

• Pick something that genuinely excites you. The nights get long, and motivation is the one resource you can’t buy more of.
• You don’t need to be an expert. Not knowing how to move instances between scenes isn’t a disqualifier - it’s a Tuesday.
• Find out what actually gets graded. For us it was the process, not the product. Understand that early and you invest in the right place.
• Treat every requirement as a starting point. “Use labels” means five default labels to most people. It can also mean a system your team actually uses.

The full technical view of both projects lives in the case studies for Starfighter Alliance and Battlefront Tactics - including the UML and state diagrams that existed before the first line of code.