[{"content":"Game design student at Breda University of Applied Sciences.\nPassionate about designing tools and AI behaviours.\nCurrently looking for an internship in 2027/2028!","date":"4 October 2026","externalUrl":null,"permalink":"/","section":"","summary":"","title":"","type":"page"},{"content":"","date":"4 October 2026","externalUrl":null,"permalink":"/projects/","section":"","summary":"","title":"","type":"projects"},{"content":"\rUnder construction\rSorry, this project page is still under construction!\nKey responsibilities:\nResearched commentaries in sports games Designed a representation of voicelines with interchangeable content Developed a system of prioritised voiceline events in C++ Optimised the workflow of scripting triggers with a custom K2Node Created a demo to showcase the plugin Collaborated with a voice actor on the demo ","date":"4 October 2026","externalUrl":"https://sports.tonyl.eu","permalink":"/projects/sports-commentary/","section":"","summary":"UE5 plugin for commentary systems in sports games\rKey responsibilities:\nResearched commentaries in sports games Designed and developed the plugin (C++, BP) Documented the user workflow (in-engine, online) Created a demo to showcase the plugin Collaborated with a voice actor on the demo ","title":"Sports Commentary","type":"projects"},{"content":"\rI am a 3rd year game design student at Breda University of Applied Sciences focusing on technical design, particularly tools and AI behaviours. I am passionate about problem-solving and improving my playtesting processes.\nI enjoy participating in game jams, both alone and in a team, totalling 12 entries so far. My most ambitious jam games include Daily Steps (a mouse-only adventure game) and TicTic (a variant of Tic-Tac-Toe, with online multiplayer). The latter placed in the top 2.5% in Fun.\nOutside of games, I engage in competitive programming. As a contestant, I scored a Silver Medal at the International Olympiad in Informatics. As an organiser, I author and test tasks for the Czech olympiad since 2024.\nCurrently looking for an internship in 2027/2028! I am based in Breda 🇳🇱 and Brno 🇨🇿, but open to relocation.\nSkills\rDesign skills\rRapid prototyping Structured playtesting AI behaviours (states, trees) Tools \u0026amp; workflows I also have experience with:\nLevel design Puzzle design Technical skills\rUnreal Engine (C++, Blueprint) C++, Python Perforce, Git Algorithms \u0026amp; data structures I also have experience with:\nUnity, Godot, custom engine PHP, AngelScript Soft skills\rProblem-solving Written documentation Pitching, presenting SCRUM processes I also have experience with:\nSketching ","date":"14 September 2026","externalUrl":null,"permalink":"/about/","section":"","summary":"","title":"About","type":"page"},{"content":"","date":"8 June 2026","externalUrl":null,"permalink":"/tags/8-weeks/","section":"Tags","summary":"","title":"8 Weeks","type":"tags"},{"content":"","date":"8 June 2026","externalUrl":null,"permalink":"/tags/custom-engine-zap/","section":"Tags","summary":"","title":"Custom Engine (Zap)","type":"tags"},{"content":"\rYour browser cannot play this video. Download video.\nGameplay footage of Petrified\rPetrified is an on-rails shooter where you play as a witch. Ride your broomstick, dodge rocks, and sling orbs at elementals to save the forest from petrification.\nWe made the game in Zap, a custom engine developed by students prior to and during the project. The engine features a comprehensive editor, enables scripting through AngelScript, and exports to both Windows and PS5.\nPlayable on itch.io\rKey responsibilities\rDesigned and balanced a 2-phase boss and its 4 attack types Designed and balanced 2 enemy types and their 8 movement patterns Developed an in-editor tool for collecting and visualising telemetry data Co-ran playtests and supported our team\u0026rsquo;s QA processes Collaborated with programmers, artists, and our level designer to create meaningful challenge for the player Boss design\rWe wanted our level to end on a high note with an intense boss fight. To tackle it, we formed a small feature team consisting of me as the designer, one gameplay programmer, and our two artists handling the character and VFX.\nResearch\rInitially, it was unclear what kind of attacks our boss should have. To help answer this, I briefly researched bosses from our primary reference game, Ex-Zodiac.\nI timed 8 boss fights, broke down their attacks and phases, and took notes on which parts could work well for our game.\nThis helped me identify 4 common types of boss attacks worth exploring: projectiles, beams, launched obstacles, and in-world obstacles. The data also led to a sensible scope for an engaging boss: 90 seconds of combat across 2 phases and 4 varied attacks.\nThe conclusions enabled me to make confident decisions over the boss\u0026rsquo;s concept and gave the programmer a clear direction for what to prototype.\nConclusions and takeaways from the research\rView full document\rConcept\rSeveral ideas for the boss emerged from an artist\u0026rsquo;s concept sketches and the programmer\u0026rsquo;s early prototypes. We went back-and-forth with the programmer to explore different attack patterns, and soon we landed on a compelling set of attacks. However, the prototypes were still loose and it was unclear how they should connect. My goal became to turn our ideas into cohesive 2-phase boss.\nI established a target intensity curve to effectively engage the player throughout the fight (with a rising intensity and frequent fluctuations). I also wanted to encourage the player to switch between their two weapons \u0026ndash; to solve this, I opted for varying the boss\u0026rsquo;s hittable areas (both small and large). Another aspect I considered was how different attacks allow for the player to play aggressively or force them to defend themself.\nWith these objectives in mind, I rated our attack types and mapped them to the two phases. This way, each phase had an intense signature attack and two other attacks that grew in challenge.\nGraph of intended intensity over time\rView full concept\rBreakdown of the boss\u0026rsquo;s 2 phases and 6 attacks\rI made sure to check the concept with our feature team. Importantly, the boss relied on several feedback systems, which I discussed with visual artists. The concept was well received and established clear intentions for each attack which could be verified during playtesting.\nBalancing\rThe initial parameters of the boss prototype did not align with the intended player experience for the concept. Instead, I continuosly balanced the properties over 4 iterations based on playtests and my own playthroughs.\nThe biggest issue was with the boss\u0026rsquo;s pacing \u0026ndash; the boss is supposed to be the most intense part of our level. I reduced the boss\u0026rsquo;s health to reach the target duration, and shortened the attacks and delays between them to maximise action. The exception was the laser beam attack, which I prolonged to motivate the player to both dodge and counter-attack.\nReviewing recordings from our first playtest confirmed the boss phases last the intended 60s and 30s. Another success was with the players\u0026rsquo; weapon use \u0026ndash; lock-on was preferred in the 1st phase and firing bullets in the 2nd, as expected.\nHowever, most testers found the 2nd phase easier than the 1st. To avoid an anticlimactic ending, I further shrunk delays in the 2nd phase. Based on how testers rated intensities of the individual attacks in a survey, I continued to tweak them to highlight the signature attacks and tougher variants.\nYour browser cannot play this video. Download video.\nThe initial unbalanced prototype\rYour browser cannot play this video. Download video.\nFinal version (4th balancing iteration)\rEnemy design\rDesigning enemies was my primary responsibility this project. I worked on them in a feature team together with 2 to 3 programmers and both of our visual artists. I designed the enemy types and behaviours, and worked closely with the level designer who used them for combat.\nFeature specification\rTo utilise our team composition, programmers handled most of the gameplay implementation. My task was to figure out what functionality our enemies should have, and then specify it so programmers knew what to work on. An important consideration was making sure enemies are easy to tweak and experiment with for both myself and the level designer.\nI started with some quick research into on-rails shooters. This let me identify what key elements should be tweakable for modulating difficulty: the complexity of enemy movement, number of fired bullets, and whether they come in fleets.\nBased on the findings, I started mapping down the functionality in a document. This required a very iterative process, keeping in close touch with programmers. Especially at the beginning, I had to update them frequently to avoid design becoming a bottleneck. There also turned out to be several unclarities, which led me to refine the documentation and adjust my process to be more descriptive. I also found it helped to check for understanding by asking others to paraphrase.\nThe updated specification was well received, and the resulting feature made it easy to create content (described in the following sections).\nA snippet from the feature specification\rView full specification\rEnemy types\rBalancing variety with the limited scope, we settled on having 2 enemy types \u0026ndash; flying \u0026amp; stationary.\nIn a playtest I co-ran, testers found enemies easy to avoid and rarely threatening. To address this, I reduced the bullet anticipation, requiring a swift reaction from players. I also made the stationary enemy fire multiple bullets to provide a distinct challenge.\nIt was important for our artists to have metrics for enemies locked in early. I used feedback from build reviews to find the right sizes and updated the artists. Another consideration for visual art was communicating to the player which enemies are passive and which are going to shoot \u0026ndash; we discussed this and opted for having 2 variants.\nPassive flying enemy\rAggressive flying enemy\rStationary tower enemy\rAttack patterns\rIn on-rails shooters, players fight many enemies with various attack patterns they can learn and overcome. To support this, I created and maintained a growing library of reusable enemy behaviours for the level designer to build combat with.\nThere were two kinds of behaviours I created, based on the current priorities:\naggressive (moving and shooting) – used to threaten the player, especially later in the level passive (movement only) – intended for onboarding, as well as to layer combat and give opportunities for extra score I used a minimal gym environment to set up timeline animations for enemies relative to the player, including shooting events. These timelines, together with a couple more settings, formed the full behaviours as data assets. The exception was a bespoke movement pattern made for a specific point in the level, which I defined using a spline.\nYour browser cannot play this video. Download video.\nAn overview of all enemy behaviours in a gym\rYour browser cannot play this video. Download video.\nA bespoke spline-based behaviour (right before the boss)\rWhile a few experiments were scrapped, a total of 8 behaviours made it to the final level (some appearing many times).\nTelemetry system\rMotivation\rThe player moves on a spline, and as such the game is a fully linear experience with well-defined pacing. Knowing in which sections players struggle and how they navigate around obstacles could prove very useful, especially for the level designer.\nTo utilise this opportunity, I proposed and developed the telemetry system \u0026ndash; a script to collect playthrough data, together with an in-editor tool to visualise it. I worked on this alone on the side under a low-priority goal.\nDevelopment\rAn interesting technical challenge was working around gaps in the engine\u0026rsquo;s functionality. Core gameplay was our team\u0026rsquo;s priority, and so we did not have features like game saves or HTTP requests until later in development. I wanted us to start collecting telemetry data as soon as possible, so I made do with what the engine allowed.\nThe solution I came up with was dumping the telemetry data to our game\u0026rsquo;s logs, following a simple text-based format. I could then scrape the logged data with a Python script. To enable easy aggregation across multiple playtest sessions, I used my PHP server, storing the metrics in a database and allowing us to download a synthesized data asset. Finally, I could read all this data in AngelScript and visualise it in the editor through debug draws.\nThe telemetry code was not very well optimised, and so it was important that the telemetry system could easily be switched off and that gameplay logic would not be dependent on it. To achieve this, I utilised delegates (called ZapEvent in our engine) like in the example:\nvoid Start() { /* subscribe to the player */ m_player.GetComponentInChildren\u0026lt;HealthComponent\u0026gt;().onDamage .AddListener(ZapEvent\u0026lt;HealthComponent\u0026gt;::CallbackType(PlayerDamaged)); } private void PlayerDamaged(const HealthComponent\u0026amp;in healthComponent) { playthrough.AddPosition(TelemetryType::PlayerHurt, m_playerTransform.GetWorldPosition()); }\rResults\rWe used the telemetry system to collect data during various playtests, but by far the biggest dataset was from visitors trying the game at the Night of the Nerds (an event in Eindhoven), totalling 166 playthroughs. Use of the tool to visualise this data can be seen below:\nYour browser cannot play this video. Download video.\nVisualising telemetry data in-editor\rTelemetry data collected at Night of the Nerds\rThe most useful information were player paths and where players took damage \u0026ndash; reviewing the data with the level designer allowed us to quickly check for pain points. Due to the project\u0026rsquo;s short duration, there was unfortunately not much room to iterate based on these findings, but the learnings from the development were certainly worth it.\nConclusion\rFrom what worked well and what went poorly, these are my biggest take-aways for this project:\nCollaborating with programmers \u0026ndash; Specifying enemies, I learned that communicating functionality requires descriptive language and checks to prevent misunderstanding. Designing the boss taught me another kind of collaboration \u0026ndash; constant back-and-forths with a programmer through prototypes allow for rapid exploration and iteration. The build is key \u0026ndash; We started the project developing features in separation, which carried risks for gameplay. Introducing daily build reviews led us to exchange lots of feedback and prioritise connecting features as soon as possible, maintaining a playable build. Functionality testing \u0026ndash; Based on research into QA practices, I set up a part of our team\u0026rsquo;s testing pipeline. From the processes, functionality test suites proved particularly valuable, allowing us to confidently ship frequent updates to the game. Improving workflows \u0026ndash; Watching and asking about the level designer\u0026rsquo;s workflow, he was placing frames along the spline to visualise player bounds and distances. Thanks to this, I saw an opportunity to help and scripted a tool to automate and customise the process. Duccio Carnicelli – Level Designer\r\u0026ldquo;Tony is a reliable teammate who doesn\u0026rsquo;t shy away from cooperating with teammates to ease their workflows, helping them speed up implementation and iteration time\u0026rdquo;\n","date":"8 June 2026","externalUrl":null,"permalink":"/projects/petrified/","section":"","summary":"On-rails shooter made in a custom engine\rKey responsibilities:\nDesigned \u0026 balanced enemies (8 patterns) Designed \u0026 balanced the boss (4 attack types) Specified enemy functionality for programmers Developed a telemetry system in Angelscript Co-ran playtests and supported our QA processes ","title":"Petrified","type":"projects"},{"content":"","date":"8 June 2026","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"\rUnder construction\rSorry, this project page is still under construction!\n","date":"26 June 2025","externalUrl":null,"permalink":"/projects/resonance/","section":"","summary":"A twin-stick action game with telekinetic powers Nominated for Dutch Game Awards 2025\rKey responsibilities:\nDesigned and balanced 2 enemies Prototyped enemy behaviours with StateTree \u0026 BP Integrated Steam achievements Handled deploying builds to Steamworks ","title":"Resonance","type":"projects"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"}]