Reach Core
"Fly deep beneath the Earth’s surface, navigate through dangerous layers, and race toward the Core — only to fly through it and go back into the sky! Go as far as possible, avoid obstacles, and claim the highest score."
Role: Game Producer, Product Owner, Scrum Master
Development time: 3 months
Team Size: 6
Engine: Unity
Methodology: Scrum
Programming language: C#
Project management: HacknPlan
Tools: Git & GitHub
Genre: 2D Arcade, Casual Game
Platform: Mobile
Year: 2025
About Reach Core
Reach Core is a fast-paced 2D mobile arcade game created by a six-person team during the Mobile Game Project course at Kajaani University of Applied Sciences. We developed it in Unity and released the finished Android version on itch.io.
The player falls from the sky towards the centre of the Earth, avoiding obstacles and trying to get the highest possible score. After reaching the Core, the whole world flips and the player begins travelling back towards the sky.
Our team included people working in production, design, programming, art, sound and music. Several team members also tried roles outside their main study specialisation, which gave everyone a chance to work on something they were genuinely interested in.
My Role
I worked as the Game Producer, while also handling the responsibilities of both the Product Owner and Scrum Master. I also helped with some of the Unity implementation.
As the Product Owner, I kept the overall direction of the game clear, managed the backlog in HacknPlan and decided what the team should focus on during each Sprint.
As the Scrum Master, I organised the Scrum process, ran our daily meetings, followed the team’s progress and helped deal with problems before they became bigger blockers.
My responsibilities included:
-
Helping the team choose and develop the final game concept
-
Defining the product goals, scope and main priorities
-
Creating and maintaining the full production schedule
-
Managing and prioritising the Product Backlog in HacknPlan
-
Planning the work and goals for each Sprint
-
Organising and facilitating daily Scrum meetings
-
Leading Sprint Planning, Sprint Reviews and Retrospectives
-
Tracking progress, deadlines, dependencies and blockers
-
Organising public playtests and preparing feedback forms
-
Adjusting upcoming priorities based on feedback and testing
-
Leading part of the art production and discussing visual decisions
-
Preparing and presenting the initial and final project presentations
-
Setting up the itch.io page and coordinating the final Android release
I tried to be someone the team could approach whenever something was unclear or going wrong. I also organised a few casual hangouts because keeping the team comfortable with each other made communication much easier.
Project Goals
The course brief asked us to create a simple 2D mobile game. We decided to focus on one clear gameplay loop that would be easy to understand but still difficult to master.
We wanted players to be able to start playing almost immediately. At the same time, the increasing speed, different enemy behaviours and Near Hit mechanic gave more experienced players something to improve at.
The original idea was built around controlling the character by tilting the phone. However, we knew that tilt controls would not feel comfortable for everyone, so we also added on-screen touch controls.
We also wanted the final game to have four visually different sections, several enemy types and fully original graphics, animations, music and sound effects.
Production Process
We used Scrum throughout the project.
The development was divided into Sprints lasting a few weeks. At the beginning of each Sprint, I updated the backlog in HacknPlan, planned the new tasks and helped the team agree on what we needed to complete next.
We held daily meetings so everyone could explain what they had worked on, what they planned to do next and whether anything was blocking them. We also had longer weekly meetings where we could look at the project as a whole and discuss bigger problems.
At the end of each Sprint, we reviewed the current version of the game, discussed what had gone well and decided what needed to change in the next Sprint. Public playtests and project presentations also helped us decide which features, bugs and improvements should be prioritised.
The development was divided into four main stages:
Late August - September — Concept and planning
We started by brainstorming several mobile game ideas and presenting them to each other. After choosing Reach Core, we polished the concept and decided on the main gameplay loop, visual direction and control methods. I created the project schedule and set up our work in HacknPlan. We also started the Game Design Document, Technical Design Document and Art Bible. The programmers worked on the first playable prototype while the artists and designer began developing the character, environments and overall visual style.
October — Core gameplay and first public playtest
During the next Sprints, the team worked on systems such as procedural obstacle spawning, health, menus, screen effects and high scores. We prepared a playable version for the Visit KAMK event. I organised the team during the event and helped create the feedback forms used to collect players’ opinions. Afterwards, we discussed the feedback and changed the backlog and upcoming Sprint tasks based on what we had learned.
November — MVP and main production
Our MVP deadline was in early November. By that point, the main gameplay loop, procedural generation, health, scoring and visual systems needed to work together. After completing the MVP, we focused on the remaining environments, enemy types, music, sound effects and difficulty balancing. We also tested the game more regularly. New bugs and gameplay issues were added to HacknPlan and prioritised together with the remaining content.
Early December — Final Sprint and release
The final Sprint focused on completing the last features, fixing bugs, polishing the visuals and checking that all of our documentation was finished. We completed the final playtest and project presentation in early December. The team met every deadline and achieved the main goals we had set at the beginning of the project. We originally considered releasing the game on Google Play, but its testing requirements would have required more time after the course. We chose itch.io instead so that we could still finish the release properly and make the Android version publicly available.
Challenges and Solutions
One of the main challenges was keeping a six-person team organised when everyone was working on very different things.
I used the Sprint backlog and daily meetings to make sure everyone knew what was currently important. Breaking larger goals into smaller tasks also made it easier to see when something was taking longer than expected or blocking other work.
Another challenge was balancing the needs of the project with the interests of the team members. Several people wanted to try roles outside their main study area. I wanted to support that, but I also needed to make sure all the important parts of the game still had someone responsible for them.
The team also had very different levels of Unity experience. One programmer had never used Unity before, and there was also a language barrier that sometimes made communication more difficult. I helped with technical problems and version control, but this was one situation I could have handled better. I should have created clearer beginner-friendly tasks, checked in more often and asked the teachers for support earlier instead of hoping the situation would improve by itself.
Gameplay
The player controls a skydiver falling from the sky towards the centre of the Earth while avoiding obstacles and trying to earn the highest possible score.
The main gameplay features include:
-
Fast-paced 2D arcade gameplay
-
Four visually different sections
-
Enemies with different movement patterns and behaviours
-
Tilt controls and on-screen touch controls
-
Three lives per run Local high-score saving
-
Increasing speed and difficulty
-
A Near Hit mechanic
-
A world-flip mechanic after reaching the Core
-
Original graphics, animations, music and sound effects
Each section has its own colour palette, atmosphere and obstacles. The deeper the player travels, the more difficult the run becomes. Flying close to an obstacle without hitting it activates the Near Hit mechanic, increasing both the score and speed.
After reaching the Core, the entire map flips, including the enemies, and the player begins travelling back towards the sky. The controls were kept simple so players could focus on reacting quickly, improving their score and learning the behaviour of each obstacle.
Playtesting Feedback
We tested Reach Core several times during development and used each session to focus on different parts of the game.
During the first playtest, we mainly tested the controls and the basic gameplay feel. We wanted to see whether players understood how to move the character, whether tilt controls or on-screen buttons felt more comfortable and whether the speed increase was noticeable and not confusing.
The second playtest focused more on the overall experience and the visuals. Some players pointed out that enemies could be difficult to distinguish from the backgrounds, especially for colour-blind players, because each location and its enemies used very similar colour palettes. With more development time, we would have improved this by adding clearer contrast, stronger silhouettes and other visual indicators instead of relying mainly on colour.
Overall, players described the game as addictive and enjoyable. Many said that each run made them want to try again and beat their previous score. This was very encouraging to us because creating a simple but replayable and addictive gameplay loop was one of our main goals.
Outcome
We completed Reach Core on schedule and released it as a downloadable Android game on itch.io. The final version included four visually different sections, enemies with their own behaviours, tilt and touch controls and the Near Hit mechanic. All of the visuals, animations, music and sound effects were created by the team.
We reached the main goals we had set at the beginning of the project, met every course deadline and received positive feedback during the final playtest. Players found the game enjoyable and replayable, and several said that it made them want to try again and improve their score.
For me, Reach Core became an important producer project. I managed the backlog and schedule, planned Sprints, ran daily meetings, organised playtests, supported the team and helped guide the game from its first idea to a public mobile release.
What I Learned
Reach Core was the first project where I felt that I was properly leading a team rather than only helping to keep the project organised.
Using Scrum taught me how the Product Owner and Scrum Master responsibilities support different parts of development. As Product Owner, I needed to keep the game’s direction and priorities clear. As Scrum Master, I needed to keep communication moving and help the team deal with problems.
HacknPlan helped me turn a long project schedule into smaller Sprint goals and manageable tasks. Daily meetings also showed me that a task board never tells the whole story: you still need to talk to people and understand what is actually happening behind each task.
I also learned that assigning someone work is not enough. A producer needs to make sure the person understands the task, has the right support and feels comfortable asking for help.
Producing my first mobile game gave me experience with phone controls, Android testing and mobile builds. Supporting both tilt and touch controls also showed me how important player preference can be, even in a simple arcade game.
Most importantly, the project made me more confident as a producer. We kept the project moving, met every deadline and finished with a game that the whole team could be proud of.