Rogue Arena
"Survive three waves of enemies, choose your upgrades and defeat the final boss"
Role: Lead Programmer & Team Lead
Development time: 3 months
Team Size: 2
Engine: Unity
Methodology: Agile
Programming language: C#
Project management: Trello
Tools: Git & GitHub
Genre: 2D Roguelike Shooter
Platform: PC
Year: 2025
About Rogue Arena
Rogue Arena is a fast-paced 2D roguelike shooter created by a team of two during the Game Programming I course at Kajaani University of Applied Sciences. We developed it in Unity with C# within three months.
The course theme was sports, but we wanted to create something less traditional than a normal sports game. We combined different sports with the structure of a roguelike arena shooter.
The player fights enemies inspired by American football, basketball and frisbee. Each enemy has its own movement and attack style. After surviving three waves, the player faces a final boss that combines abilities from the earlier enemies.
My Role
Our official roles were both programmers, but as the project continued, I gradually took on more responsibility for leading the development. I helped decide what needed to be done next, divided the work and made sure the different parts of the game came together.
My teammate had less experience, so I needed to think carefully about which tasks he could complete independently and where he might need more support. I divided the work based on our skills, followed the progress and handled many of the more complex systems myself.
My responsibilities included:
-
Helping define the game concept and project scope
-
Taking on informal leadership and keeping the project moving forward
-
Planning the development stages and prioritising the work
-
Dividing tasks based on my teammate’s current skills
-
Supporting my teammate when tasks became difficult or unclear
-
Programming the main gameplay systems in Unity with C#
-
Creating the pixel-art graphics and overall visual direction
-
Choosing and implementing the music and sound effects
-
Bringing the different parts of the game together in Unity
-
Testing the complete gameplay loop
-
Preparing the final PC build
The course did not require us to create custom graphics, but I really liked the concept and wanted the project to feel like a complete game rather than only a programming assignment.
Project Goals
Our main goal was to create a complete and replayable game within the available development time. It needed to have a combat loop, several enemy types, player upgrades, a final boss and win/lose conditions.
Because we were a two-person team, keeping the scope realistic was especially important. We wanted to include enough variety to make each wave feel different without creating more systems than we could properly finish and test.
We also wanted every enemy to behave differently. The American football, basketball and frisbee enemies needed their own movement and attack styles instead of only looking different, while the Boss had to combine them all in one.
Another goal was to give the game clear visuals. I chose a simple pixel-art style using 16x16-pixel graphics, so I could create a consistent look without taking too much time away from programming.
Production Process
We used an Agile approach and built the game in smaller stages. We first focused on creating a basic playable combat loop and then added enemies, upgrades, scoring and the boss fight step by step.
Trello was used to organise the project, divide the work into smaller tasks and keep track of our progress. I regularly reviewed the board, decided what needed to be worked on next and adjusted the priorities when something took longer than expected or became blocked. It also helped me choose suitable tasks for my teammate based on his current experience.
We regularly tested the newest version and changed our priorities when something took longer than expected or caused problems in another part of the game.
The development was divided into six main stages:
1.1 - 12.1 — Concept and planning
We brainstormed different ideas based on the sports theme and decided to create a roguelike arena shooter. We planned the main gameplay loop, enemy types, upgrades and boss fight, and talked about the features needed for a complete game. I also divided the first tasks based on what each of us could realistically handle.
13.1 - 2.2 — Core prototype
We mainly worked on player movement, shooting, enemy spawning and the basic wave structure. Our goal was to create a playable version early enough to test whether the combat felt enjoyable. During this stage, I also started creating the pixel-art graphics.
3.2 - 17.2 — Enemies, upgrades and Demo Day preparation
We added the different enemy behaviours, player health, upgrades, scoring and the boss fight. We connected the systems so that completing a wave opened the upgrade selection and choosing a bonus started the next round. Before Demo Day, we focused on making sure the full game could be played from the first wave to the final boss.
18.2 — Demo Day and public playtesting
We presented the game and watched players try it. The feedback showed that the enemy variety, visual style and higher difficulty worked especially well for people familiar with roguelikes and arena shooters. The playtest also showed that the overall balancing still needed improvement.
19.2 - 2.3 — Iteration and balancing
After Demo Day, we continued adjusting enemy behaviour, difficulty and gameplay feedback. We also improved the interface, animations, sound and connections between systems.
3.3 - 17.3 — Final testing and release
During the final stage, we tested the complete gameplay loop, fixed problems between connected systems and prepared the downloadable PC build. I also brought together the graphics, music, menus, gameplay feedback and ending screens.
Challenges And Solutions
One of my main challenges was taking on leadership even though it was not my official role. My teammate had less experience, so dividing the work equally would not always have been realistic.
I handled this by giving him smaller and more clearly defined tasks while taking responsibility for the more difficult systems. I regularly checked how things were going and helped when he became stuck.
The enemy AI was another major challenge. Each enemy needed its own recognisable behaviour while still working together with the others during the same wave. The American football, basketball and frisbee enemies moved and attacked in different ways, which made the combat more interesting but also harder to balance. An enemy could work well on its own but become overwhelming when several different enemy types appeared at the same time.
Balancing the game was difficult for the same reason. Small changes to enemy health, movement, attack speed, spawning or player upgrades could affect the whole run. We continued adjusting these values throughout development, although the final version still ended up being more suitable for experienced players than beginners.
Our original plan also included a shop where players could spend coins on weapons and upgrades. The system became too large for the time we had, so we removed the shop, turned the coins into score and gave the player a free upgrade after every wave. This allowed us to keep the risk-and-reward idea without adding another large system that we might not have had enough time to finish.
Gameplay
The player moves around the arena, aims with the mouse and shoots a ball at approaching enemies. Each run includes three 60-second waves followed by a final boss fight.
The main gameplay features include:
-
Fast 2D movement
-
Mouse-controlled shooting
-
Random enemy spawning
-
Three sports-themed enemy types
-
Different movement and attack behaviours
-
Three 60-second combat waves
-
A bonus selection after each wave
-
Health, attack-speed and movement-speed upgrades
-
Collectable coins
-
A score and high-score system
-
A final boss that combines earlier enemy abilities
-
Separate win and lose conditions
After each wave, the player chooses between an additional heart, increased attack speed or increased movement speed. These upgrades allow the player to adjust their playstyle and prepare for the final boss.
Coins appear during combat and disappear after a short time. Collecting them increases the score and gives the player another reason to take risks instead of only avoiding enemies.
Playtesting Feedback
We held a public playtest during Demo Day on 18.2.
Players especially liked the different enemy types and the fact that each one had its own movement and attack style. The graphics were also praised, which was encouraging because creating a polished visual style was not originally required for the course.
The difficulty received more mixed feedback. Some players found the game too difficult, and the balancing was not completely even. However, people who had played similar roguelikes and arena shooters really enjoyed the Master difficulty and found the challenge rewarding.
This showed me that the game had a strong core experience for its target audience, but the difficulty curve still needed more work for less experienced players.
With more development time, I would have tested the game with a wider range of players and adjusted the wave pacing, enemy combinations and player upgrades more carefully.
Outcome
We completed Rogue Arena within the planned development period and released it as a downloadable PC game.
The finished version included three combat waves, random enemy spawning, three player upgrades, collectable coins, a score and high-score system, several enemy behaviours, a final boss and complete win and lose conditions.
Although the project began as a programming assignment, it became a much more complete game. I created the graphics, chose the music, connected the different systems and helped guide the project towards a finished and presentable result.
For me, Rogue Arena became an important example of stepping up and taking ownership when a project needed clearer direction.
What I Learned
Rogue Arena taught me that leadership does not always begin with an official title. Sometimes a project simply needs someone to take responsibility, make decisions and keep the work moving forward.
I learned how important it is to assign tasks based on a person’s current skills. The tasks still need to be useful to the project, but they also need to be realistic enough for the person responsible for them to complete.
The project also gave me more experience working with connected gameplay systems. Player health, upgrades, enemy spawning, wave progression, UI and scoring could not be treated as completely separate features because changes to one system could affect the whole game.
Creating the enemy AI taught me how difficult it can be to make several behaviours work together while keeping the combat readable and fair.
The playtest showed me that difficulty depends heavily on the player’s previous experience. Experienced players enjoyed the challenge, while newer players could find the same version overwhelming. In future projects, I would start balancing earlier and test with a wider range of players.
Most importantly, I learned that reducing scope does not always mean losing the main idea. Removing the shop made the project more realistic while still allowing coins, upgrades and player choices to remain meaningful parts of the game.