Mennää

Overview

mennää.exe started as a small Godot experiment, not an attempt to become a game developer or launch a polished indie title. The real goal was to build something end‑to‑end in Godot, ship it, and learn by doing — treating the project as a full lifecycle exercise rather than a portfolio showpiece.

The game grew from a simple prototype into a finished, coherent experience, and along the way it taught me a lot about structure, iteration and how to keep even a tiny project from turning into spaghetti.

Download

Download mennää.exe

Getting started with Godot

Godot was appealing because it removes friction: you can open the engine, drop a few nodes into a scene, write a short script and see results immediately. That tight feedback loop kept me building instead of over‑planning. I started with a basic prototype focused on movement and interaction, and only once it felt fun to control did I begin layering in more mechanics.

Scenes, nodes & modular structure

One of the biggest design decisions (which Godot naturally nudges you towards) was breaking the game into many small, independent scenes. Instead of a single giant script controlling everything, each piece — player, enemies, interactions, UI — owns its own logic.

That structure made iteration fast and safe: if a mechanic felt off, I could tweak just that scene without worrying about side effects elsewhere. It kept the project maintainable and was a good reminder that clean architecture isn't just for big systems.

Building the core gameplay

I focused early on making the player feel responsive. Even simple mechanics feel much better when input is snappy and movement is predictable, so I spent time tuning acceleration, speed, friction and timing in code. Godot's scripting made it easy to iterate quickly on the "feel" of movement and interaction.

Once that felt right, I layered in small interactions, reactions and simple enemy logic. Rather than designing complex systems, I stuck to straightforward condition checks and short scripts — clarity over cleverness. Often the simplest version of a mechanic ended up being the best one.

Adding polish

With the basic loop working, I spent time on polish: small animations, short effects and subtle feedback cues that make the game more readable and more satisfying to play. None of these were huge features, but together they pushed the project from "prototype" to "finished".

It reinforced an important lesson: polish isn't just a final coat of paint at the end of a project. It's part of how you communicate with the player, and in many cases small details matter more than big new systems.

What I learned

• Finishing something small is more valuable than sketching something big.
• If your architecture is clean, iteration becomes effortless.
• Visual debugging forces you to understand your own logic better.
• Cutting features is a skill.
• Shipping builds confidence.

More than anything, mennää.exe was practice for the full lifecycle: idea, design, implementation, iteration and release. That end‑to‑end process made me sharper in ways tutorials don't, and the same habits carry directly into my professional work.

Why it's in my portfolio

It's a small project, and that's exactly why it matters. It shows that I can pick up a new tool, understand it quickly, build something coherent and actually finish it. The mindset behind mennää.exe — simple foundation, fast iterations, constant refinement — is the same way I approach larger software projects.