About me

The central mechanic is inspired by timing and positioning minigames such as the fishing system in Breath of Fire III, but the player takes the role of the fish instead of the fisherman. The idea grew from the game jam theme, “Beneath.” The player controls a green bar along a curved meter while an AI-controlled fisherman icon moves unpredictably through the same space. Keeping the two aligned lets the fish resist the pull and gradually drain the fisherman’s energy; losing contact drains the fish’s energy instead.

At intervals, the fisherman performs a special action. A warning icon appears briefly, giving the player a short window to be correctly positioned and press the action input. A successful response damages the fisherman and triggers visual, movement, and sound feedback. Missing it costs the player a significant amount of energy, creating a rhythm between continuous positional control and short reaction-based challenges.

The encounter ends when either participant runs out of energy. If the fish wins, the fisherman is pulled underwater and presented as the fish’s catch, humorously reversing the usual fishing result screen. If the player loses, the fish is pulled out of the water. The game also includes selectable fish appearances, animated camera movement, audio feedback, and dedicated victory and defeat sequences.

Role

Concept, design, UI, and core gameplay programming

Tools

Unity, C#

Team

Three developers

Status

Released game jam project

Key features

• AI-controlled fishermanRandomized movement targets and timing make positioning unpredictable.
• Timed reaction eventsSpecial actions create short response windows with meaningful success and failure consequences.
• Dynamic feedbackUI color, fish movement, audio, and animation respond to distance, positioning, and major actions.
• Complete game flowIncludes fish selection, a main menu, pause handling, victory, defeat, and restart flows.

The player controls a stone token and clears targets by carefully aiming each flick. Shot strength, impact position, and angle all affect how the token moves, allowing the player to use both direct hits and glancing strikes with spin. The focus is on precision and understanding the physical interaction between the pieces rather than simply using maximum force.

I originally designed the minigame as one activity within a larger historically inspired game project. Because the small physical scale of the pieces made Unity’s physics difficult to tune reliably, I separated the mechanic into a standalone prototype so I could develop and test the underlying systems independently. The current playable version contains tutorial stages that demonstrate the core mechanics and serves as a proof of concept, with additional stages and balancing still planned.

During development, I focused on building a reliable turn-resolution system, natural-feeling physics interactions, reusable stage layouts, multiple play areas, tutorial progression, and a complete gameplay loop. I also added an optional explosion mechanic after playtesting showed that a less realistic but more chaotic mode made the game more entertaining.

Role

Solo developer

Tools

Unity, C#, Blender

Work

Design, programming, 3D modelling

Status

Playable prototype

Technical highlights

• Physics-based flickingUses a temporary physical striker instead of applying force directly to the player token, allowing contact position and impact angle to affect movement and spin.
• Turn resolutionTracks collisions, movement, field exits, and pre-existing contacts before determining whether a shot produces a valid score.
• Modular stage systemEach board defines its geometry, camera settings, spawn areas, and layout, allowing stages and rule variations to be developed independently.
• Tutorial and game flowIncludes fixed tutorial layouts, contextual instructions, menus, scoring, retries, randomized standard stages, and completion logic.
• Playtesting and iterationBegan with an emphasis on realistic, historically plausible play; testing led to optional mechanics such as explosive targets for a more chaotic variation.

Berry Connected was developed during Siida Game Jam 2026 around the theme “Layers.” The player moves through layers of forest, gathers berries and flowers, and encounters small reminders that the environment is more than a source of resources. The game’s topics and actions were informed by knowledge shared by the Sámi Museum Siida and the game jam organizers.

The main activity is a timed 2D berry-picking scene. The player advances through the forest with the keyboard and uses the mouse to interact with overlapping elements: collectables can be picked, grass pushed aside, and foreground obstacles dragged out of the way. Procedurally arranged rows of bushes, birches, grass, and flowers keep the layered scene changing as the player moves forward.

The gathering systems also give the player’s choices consequences. Bushes contain a randomized number of berries, but the final berry is left behind. Some bushes rustle and may reveal a hidden lemming, creating an encounter that can end the run. Counters, a timer, start and pause states, menus, and distinct completion outcomes bring these mechanics together into a complete game jam experience.

Role

Code and design; berry-picking gameplay and systems

Tools

Unity, C#

Team

Three-person team with an additional art contributor

Status

Playable game jam release

Technical highlights

• Layer-aware interactionSelects the visually topmost object from overlapping 2D colliders while respecting sorting groups and explicit interaction priorities.
• Procedural forest compositionBuilds and recycles layered rows of bushes, birches, flowers, and grass with randomized placement and spacing constraints.
• Gathering rulesRandomizes resources, tracks separate collectable types, and prevents the player from stripping every berry from a bush.
• Environmental interactionsSupports collectables, draggable foreground objects, animated grass, rustling bushes, and hidden lemming encounters through reusable interaction components.
• Complete game flowCoordinates scene navigation, timed play, counters, start and pause states, completion screens, and encounter-driven failure.

ft_transcendence was a five-person team project completed at Hive Helsinki. The application combines a React and TypeScript frontend with separate backend services for authentication, player statistics, tournament data, and other platform features.

I was responsible for the game feature within the frontend, including the Pong implementation and its surrounding page. I developed the gameplay systems and connected them to player selection, settings, tournaments, match results, navigation, and the application’s backend services.

The game includes local two-player controls, collision handling, scoring, configurable match formats, multiple arenas, visual effects, sound, and additional mechanics such as boosts and temporary shields. I also designed its interface and presentation to fit the visual style established elsewhere in the application.

The game page manages the full lifecycle around each match: preparing player data, configuring the game, starting and ending matches, displaying results, advancing tournaments, and submitting the resulting data. This made the feature a complete part of the platform rather than an isolated game embedded in a webpage.

Integrating the game required extending an existing frontend data-fetching implementation. I modified the shared flow so the necessary player, match, and tournament information was available, submitted correctly, and displayed consistently. I worked with the backend developers to communicate data requirements and investigate integration problems, while using the project’s existing token-based authentication system for protected frontend operations.

Role

Game development, game page, tournaments, and frontend data integration

Tools

TypeScript, React, Babylon.js, Tailwind CSS

Team

Five developers

Status

Completed Hive Helsinki project

Technical highlights

• Complete frontend game featureDeveloped both the Pong game and its surrounding React page, including configuration, player data, match lifecycle, results, tournament progression, navigation, and backend integration.
• Local two-player gameplayImplemented controls, ball and paddle interactions, scoring, match resolution, pausing, restarting, effects, and sound.
• Configurable game systemsAdded multiple arenas, speeds, match lengths, custom controls, boost mechanics, and temporary shields.
• Tournament systemBuilt tournament setup, player configuration, match progression, bracket visualization, winner handling, and history views.
• Game data flowExtended the existing player-data process and ensured match and tournament information was retained, submitted, retrieved, and presented correctly.
• Authenticated requestsConnected protected frontend operations to the project’s existing token system.
• Cross-team integrationWorked with the backend developers to align frontend requirements with the available services and diagnose problems across system boundaries.

miniRT reads a scene from a structured .rt file and renders it pixel by pixel into a MiniLibX window. Each camera ray is tested against the objects in the scene, and the closest intersection is shaded using object colour, ambient light, diffuse light, distance, and hard-shadow calculations.

The renderer supports planes, spheres, and finite cylinders with end caps. It also handles camera orientation from direction vectors, surface normals, cameras positioned inside objects, and small intersection offsets that reduce self-shadowing artifacts.

The displayed scene can be explored and adjusted without restarting the program. Keyboard controls allow the user to select, move, rotate, and resize objects; reposition and rotate the camera; move the light; and adjust both direct and ambient brightness before re-rendering the scene.

We developed the ray-tracing logic through shared mathematical reasoning, reference research, iterative testing, and debugging. My implementation work focused on bringing the individual calculations together into a complete renderer, parser, interactive control system, and reliable application flow.

Role

Rendering, parsing, controls, integration, and shared mathematical design

Tools

C, MiniLibX, Make, Linux

Team

Two developers

Status

Completed Hive Helsinki project

Technical highlights

• Scene parsing and validationReads cameras, lights, colours, orientation vectors, and primitive objects from .rt files while rejecting malformed or out-of-range input cleanly.
• Per-pixel ray tracingGenerates a ray for every pixel, tests it against every scene object, and retains the nearest valid intersection for shading.
• Object intersectionsSupports planes, spheres, and finite cylinders with separate side and end-cap calculations.
• Lighting and shadowsCombines base colour, ambient light, distance attenuation, diffuse lighting, and secondary shadow rays.
• Camera and object transformsBuilds camera basis vectors from its direction and uses vector, matrix, and quaternion-related operations for movement and rotation.
• Interactive scene controlsObjects, camera position and orientation, light position, dimensions, and brightness can be changed at runtime before the scene is rendered again.

ft_irc was a three-person systems and networking project completed at Hive Helsinki. The goal was to build an IRC server that could accept multiple simultaneous clients and support real-time private and channel communication through an established IRC client rather than a custom interface.

The server uses non-blocking TCP sockets and an epoll event loop to accept connections and process activity from multiple clients without creating a process or thread for each connection. Incoming stream data is buffered until complete CRLF-terminated IRC messages are available, then parsed, validated, and dispatched to the relevant command handler.

The implementation maintains clients, nicknames, registration state, channels, memberships, invitations, operators, topics, and channel modes. It supports the main registration and messaging commands as well as the numeric replies and state changes expected by IRC clients.

The project required compatibility with an existing IRC client, and our team chose Irssi. My main contribution was implementing and refining selected server commands, then testing full workflows with Irssi and correcting the connected logic. Its automatic CAP, WHO, WHOIS, PING, and MODE exchanges exposed edge cases that were easy to miss when testing individual commands manually through Netcat.

Role

IRC commands, Irssi compatibility, integration testing, and debugging

Tools

C++, Linux sockets, epoll, Irssi, Netcat

Team

Three developers

Status

Completed Hive Helsinki project

Technical highlights

• Non-blocking multi-client serverUses TCP sockets and epoll to accept and process multiple client connections through a single event loop.
• Stream-aware message parsingRetains partial socket data, extracts complete CRLF-terminated messages, and handles multiple commands arriving in the same read.
• IRC command handlingSupports PASS, NICK, USER, QUIT, JOIN, PART, PRIVMSG, KICK, INVITE, TOPIC, MODE, CAP, PING, WHO, and WHOIS.
• Channel state and permissionsTracks membership, invitations, operators, topics, passwords, user limits, and the required invite-only, topic, key, operator, and limit modes.
• Irssi compatibilityHandles the automatic capability negotiation, presence queries, keep-alive traffic, and mode requests generated during normal Irssi use.
• Protocol-level testingTests registration, messaging, permissions, disconnections, numeric errors, and multi-user state as complete client workflows rather than isolated function calls.

ft_inception was an individual infrastructure project completed at Hive Helsinki. I built a small WordPress hosting environment inside a Linux virtual machine without using preconfigured application images for the main services. NGINX, WordPress with PHP-FPM, and MariaDB each have their own Dockerfile, startup script, runtime process, and container.

NGINX is the only service exposed to the host and accepts HTTPS traffic on port 443 using TLS 1.2 or 1.3. PHP requests are forwarded to the WordPress container over the private Docker network, while MariaDB remains accessible only to the other services on that network.

Docker Compose defines the service relationships, dedicated bridge network, restart behaviour, environment-based configuration, and bind-mounted data directories. WordPress files and MariaDB data remain outside the disposable container layers so that rebuilding or replacing a container does not erase the site.

Custom entrypoint scripts perform the first-run setup for each service. They initialize the database and accounts, wait for dependencies, configure PHP-FPM, install WordPress through WP-CLI, create its users and configuration, generate TLS material and NGINX configuration, set file permissions, and finally start each service in the foreground.

Role

Solo developer

Tools

Docker, Docker Compose, NGINX, WordPress, PHP-FPM, MariaDB, Bash

Work

Container builds, networking, configuration, persistence, and automation

Status

Completed Hive Helsinki project

Technical highlights

• Custom service imagesBuilds NGINX, WordPress with PHP-FPM, and MariaDB from Debian base images using separate Dockerfiles and entrypoint scripts.
• Isolated service architectureExposes only NGINX on port 443 while WordPress and MariaDB communicate internally through a dedicated bridge network.
• HTTPS terminationGenerates a self-signed certificate, enables TLS 1.2 and 1.3, and routes PHP requests from NGINX to PHP-FPM.
• Persistent application dataUses bind-mounted host directories for the WordPress installation and MariaDB database so data survives container rebuilds.
• Automated provisioningInitializes the database and WordPress installation only when needed, creates configured users, applies permissions, and waits for service dependencies.
• Lifecycle toolingProvides Makefile commands for checking Docker, preparing host directories, building, starting, stopping, restarting, and rebuilding the complete stack.

minishell recreates a focused subset of Bash behaviour in C. It displays an interactive prompt with command history, resolves executables through PATH, runs external programs, and provides the required built-ins: echo, cd, pwd, export, unset, env, and exit.

User input passes through quote-aware parsing, environment-variable expansion, tokenization, syntax validation, and grouping into commands. The execution layer then coordinates child processes, pipelines, input and output redirections, append mode, heredocs, built-ins that must affect the parent shell, and the resulting exit status.

Correct behaviour depends on the interaction between these systems. Pipes and redirections must apply in the right order, file descriptors must be closed in both parent and child processes, environment changes must persist when appropriate, and signals must behave differently at the prompt, during command execution, and while reading a heredoc.

We compared the shell against Bash across normal use and deliberately difficult input. My work included maintaining a detailed test and investigation log, tracing failures across parser and execution boundaries, checking memory and open file descriptors with Valgrind, and fixing subtle cases involving quotes, empty input, chained redirections, heredocs, failed forks, built-in options, and exit codes.

Role

Parsing, redirections, heredocs, signals, integration, and testing

Tools

C, Unix processes, Readline, Valgrind, Make

Team

Two developers

Status

Completed Hive Helsinki project

Technical highlights

• Quote-aware parsing and expansionHandles single and double quotes, environment variables, exit-status expansion, operators without surrounding spaces, and syntax validation.
• Processes and pipelinesUses fork, pipe, dup2, execve, and waitpid to connect commands and report the status of the resulting process chain.
• Redirections and heredocsSupports input, overwrite, append, and heredoc redirections while coordinating precedence, descriptor restoration, delimiter quoting, and variable expansion.
• Built-ins and environment stateImplements the required shell built-ins and preserves changes from commands such as cd, export, and unset in the parent shell.
• Context-sensitive signalsCoordinates Ctrl-C, Ctrl-D, and Ctrl-\ behaviour across the interactive prompt, child processes, and heredoc input while maintaining Bash-like exit statuses.
• Edge-case and memory testingUses a repeatable Bash comparison list and Valgrind runs with child tracing, descriptor tracking, and Readline suppressions to investigate failures and resource handling.