DEV Community: Jesús Pineda

The power of the Game Loop

Jesús Pineda — Fri, 03 Apr 2026 20:58:22 +0000

Hey Gamers! 👻

As part of the Rapid Games Prototyping module, we are continuing our bi-weekly peer reviews. Analyzing a game built in just one week is always a fantastic learning opportunity, so here is my latest breakdown!

The theme for this sprint was "Manchester Museum" with the modifier "Replay," meaning we were allowed to reuse code, assets or ideas from our previous module prototypes.

My pick for this week is Museum Digger (RobotWizard23, 2026). The premise is simple but highly effective: you go out into the field, excavate artifacts, and bring them back to the museum to generate income.

First Impressions: The Incremental Gameplay
I am a big fan of clicker and incremental games. Having scores and resources generate passively provides a satisfying, low-pressure experience that is great for short bursts of play. Museum Digger splits the experience into two distinct screens: the Dig View and the Museum View.

The core loop requires you to mine for bones and artifacts, then transfer them to the museum to be stored in display cases. The initial hook relies on tight economy management: you start with minimal funds and must strategically balance your budget to purchase enough cases to house your findings without going bankrupt.

Constructive Feedback: Visual Signifiers
While the visual assets were minimal, which is completely expected and acceptable in a one-week game jam, the core mechanics were so engaging that I completely lost track of time and practically finished the game in one sitting!

However, one area that could easily be improved is the use of Visual Signifiers. When visuals are basic, color-coding becomes crucial to help the player distinguish between different interactive elements. Adding distinct material colors to the artifacts, cases, and UI elements would create a stronger visual hierarchy, giving the player a much better, immediate sense of what they are clicking on without needing to read or guess.

Reflective Practice: Mechanics vs. The Core Loop
Playing Museum Digger was a massive eye-opener for my own design philosophy. It demonstrated how one simple, well-executed mechanic can scale into a highly replayable game with substantial playtime.

Reflecting on my own recent prototypes, I realize I often fall into the trap of over-engineering complex backend systems. I spend so much time perfecting the algorithms and technical mechanics that I forget to step back and establish a satisfying Core Gameplay Loop. A flawless mechanic means very little if the player has no overarching reason or loop to keep engaging with it.

Action Plan for Next Sprint Inspired by the addictive simplicity of Museum Digger, my primary goal for my next prototype is to prioritize playtime and loop design over technical complexity.

Loop First: Before writing a single line of code, I will map out the Core Gameplay Loop (Action -> Reward -> Upgrade) on paper.
Scope Management: I will strictly limit my mechanics to one simple interaction, dedicating the rest of my sprint to balancing the economy/pacing to ensure the game actually holds the player's attention for more than a few minutes.

See you next week for another update! 🛼🤟🏽

References:

RobotWizard23 (2026) Museum Digger [Downloadable game]. Available at: https://robotwizard23.itch.io/museum-digger (Accessed: 3 April 2026).

Clunky Controls

Jesús Pineda — Fri, 03 Apr 2026 20:28:10 +0000

Hey Gamers! 👾

As part of the Rapid Games Prototyping module, we are continuing our peer review series. Reviewing a game built in a single week always provides unique insights, and this week’s prototype was a fantastic lesson in the power of audio design.

Alien Abduction was the game I reviewed featured a highly creative premise centred around an alien abduction, tasking the player with getting a character out of their house from a completely fresh perspective. Having spoken directly with the developer, Allen, it was fascinating to see how the initial concept evolved into this final prototype.

The Power of Foley and Audio Feedback
My first impressions of the game were incredibly positive, entirely driven by the outstanding sound design. The developer implemented custom Foley (everyday sound effects added to media) that made the world feel tactile and responsive.

What impressed me the most was the dynamic audio feedback. Hitting the character against different walls or surfaces produced distinct, material-specific sounds. This level of detail is rare in a one-week game jam setting. The sounds were deeply satisfying, immersive, and fundamentally elevated the game's comedic tone. It proved that good audio doesn't just decorate a game; it defines the "Game Feel."

Controls: The Line Between Clunky and Comedic
The main area for constructive feedback lies in the control scheme. The inputs felt quite clunky and overly complicated, making it genuinely difficult to manoeuvre the character.

However, in the context of game design, this wasn't a total flaw. This mechanical friction actually resulted in Emergent Comedy. Struggling with the controls made the abduction scenario visually hilarious. While I would recommend refining the inputs to be slightly more intuitive to prevent player frustration, keeping a degree of that "clunkiness" could serve as a core feature rather than a bug, enhancing the game's unique identity.

Reflective Practice: Making It Personal
Playing this prototype and discussing its evolution with Allen profoundly impacted my perspective on game audio. Usually, I rely on royalty-free asset packs for my prototypes to save time. However, seeing how custom-recorded sounds gave this game such a distinct, personal touch was a revelation. It also challenged me to think beyond simple mechanics, incorporating dynamic systems like surface-specific collision sounds adds a layer of polish that transforms a basic prototype into a memorable experience.

See you next week for another update! 🛼🤟🏽

Multiplayer Challenges

Jesús Pineda — Fri, 03 Apr 2026 19:05:08 +0000

Hellu, and welcome back to another weekly update for A Wargame Without Compromise (WWC)!

We kicked off this week with our standard Agile rituals: reviewing PRs, merging code, and scoping the next sprint. The project is currently in a very healthy position. Our core gameplay loop feels solid, and while we still need to polish a few features, we had enough stability for me to continue the heavy lifting on the online multiplayer integration.

The Integration Reality Check:
Following the success of my initial Proof of Concept (PoC) last week, I moved on to a much more difficult task: integrating our existing single-player features into the networked environment.

My first victory was the spawning system. After refactoring some of our instantiation logic to ensure the server had proper authority, I successfully managed to spawn the different players along with their respective units across the network.

State Synchronization & Race Conditions:
Next, I tackled the pre-game flow. I created a new network-aware Game State to ensure all players were fully connected and synchronised before the match actually started. This proved quite difficult to sync; I initially ran into race conditions where the states were not updating simultaneously across clients. After some rigorous debugging, I finally managed to get the server to orchestrate the state changes correctly.

The Movement Synchronisation Hurdle:
The biggest challenge of the week, and the one that ultimately bested me, was unit movement. I attempted to synchronise the units' physical movements across the network. While I successfully managed to sync their rotation, I struggled to synchronise their actual positional movement and inputs without causing severe jitter or desynchronization. Networked movement requires a complex balance of client prediction and server reconciliation, and I am still figuring out the best architecture for our specific grid/movement system.

Reflective Practice: Managing Risk and Scope:
For the first time in this project, I was not able to fully complete my assigned sprint tasks. However, rather than feeling defeated, I am actually quite happy with the foundational results.

This experience brought up a critical aspect of software engineering: Risk Management. Networking is an exponentially complex feature. My main learning this week is that we must objectively assess our remaining time. As a team, we need to evaluate if it is truly viable to deliver a robust online experience before the module deadline, or if we should pivot and focus our remaining time on polishing a flawless local multiplayer or single-player experience instead.

Action Plan for Next Sprint Going into next week, my goals are split between technical research and project management:

Transform Sync Deep Dive: I will dedicate focused time to researching networked Transform synchronisation (specifically position interpolation) to see if I can crack the movement bug.
The "Go/No-Go" Meeting: I will present my findings to the team so we can make a definitive, data-driven "Go/No-Go" decision on continuing the online multiplayer development versus cutting our losses to protect the final grade.

Thank you so much if you got here!

See you next week for another update! 🛼🤟🏽

The Multiplayer Leap

Jesús Pineda — Fri, 03 Apr 2026 18:34:11 +0000

Hellu, and welcome back to another weekly update for A Wargame Without Compromise (WWC)! 👾

This sprint began a bit later than usual due to heavy deadlines in my Rapid Games Prototyping (RGP) module. However, once I transitioned back to the WWC project, I immediately jumped into clearing our backlog by reviewing pending Pull Requests and issue tickets to ensure the rest of the team remained unblocked.

Architectural Planning: Spawning & Networking Our primary architectural discussions this week revolved around spawn management and the daunting task of integrating multiplayer networking. Taking a game from a single-player state to a networked state requires a massive paradigm shift, so I dedicated significant time to research.

After extensively reviewing documentation, community forums, and performance benchmarks, I concluded that FishNet was the most robust and performant networking solution for our specific needs.

The Multiplayer Proof of Concept (PoC) My main goal for the week was to build a Proof of Concept (PoC) for our online system.

The Setup: I installed the FishNet package to handle our server/client architecture. Alongside it, I integrated ParrelSync, an incredibly useful Unity tool that allows developers to run multiple instances of the same project simultaneously without needing to build the game every time.
The Workflow Bottleneck: While the initial integration wasn't too difficult, the learning curve for FishNet's specific logic was steep. Furthermore, the physical testing process became a major workflow bottleneck. Running and debugging two simultaneous game instances on a single monitor was incredibly frustrating and drastically increased my iteration time.

From Local to Remote: Bridging the Gap Testing the local connection (localhost) was successful relatively quickly. However, a true PoC requires remote connections over the internet. To simulate this without renting dedicated servers, I utilised Radmin VPN to create a Virtual LAN (Local Area Network). This allowed my machine to act as a host IP that other players could remotely connect to. I am thrilled to report that the remote tests were successful!

Reflective Practice: The Complexity of Netcode My biggest takeaway this week is a newfound respect for multiplayer game development. Finding reliable, up-to-date resources and tutorials for modern networking is surprisingly difficult. More importantly, this sprint taught me that while making a simple connection work is achievable, developing a truly robust, synchronised online game introduces staggering complexity. Every mechanic we design from this point forward must be evaluated through the lens of server authority and client prediction.

Action Plan for Next Sprint With the networking PoC successfully connecting clients, my goals for next week are:

Spawn Management over Network: I will integrate our initial spawn management ideas with FishNet to ensure players instantiate correctly across all connected clients.
Workflow Optimisation: I need to reorganise my workspace and window layouts to make single-monitor network testing less cumbersome and more efficient.

Thank you so much for getting here!

See you next week for another update! 🛼🤟🏽

References

First Gear Games (2026) Fish-Networking Documentation. Available at: https://fish-networking.gitbook.io/docs (Accessed: 17 March 2026).
Unity Technologies (2026) Netcode for GameObjects (NGO) Documentation. Available at: https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.10/manual/index.html (Accessed: 17 March 2026).
Unity Technologies (2022) Updated Free Networking Solution Comparison Chart. Available at: https://discussions.unity.com/t/updated-free-networking-solution-comparison-chart/899755 (Accessed: 17 March 2026).
Unity Multiplayer Networking Comparison (2024) [Google Sheet]. Available at: https://docs.google.com/spreadsheets/d/1Bj5uLdnxZYlJykBg3Qd9BNOtvE8sp1ZQ4EgX1sI0RFA/ (Accessed: 17 March 2026).

Conquering Chunks, UV Mapping, and Spaghetti Code

Jesús Pineda — Mon, 16 Mar 2026 21:29:15 +0000

Hellu, and welcome back to another weekly update for our Game Studio project! 👾

This week was incredibly code-heavy. I dove deep into the algorithms behind our procedural map generation, experiencing both the highs of solving complex math and the lows of debugging UV coordinates for hours on end.

The Foundation: Octaves and Custom Chunks
I started the sprint by implementing octaves into our noise generation, which went fairly smoothly thanks to Professor Jimmy's guidance. This added the necessary granular detail to our terrain.

However, I severely underestimated the effort required for the next step: the chunking algorithm. Instead of following the standard approach of generating perfectly squared maps with squared chunks, I decided to implement a custom solution to support rectangular maps. This meant that certain chunks could have different widths and height values depending on the map's overall dimensions.

I spent an entire day wrestling with the math for this. While Professor Jimmy was intrigued by the approach, the initial result was pure "spaghetti code", clunky and hard to read, but functionally working. When I cross-referenced my logic with Sebastian Lague's highly regarded procedural chunking tutorials, I found that while our foundational logic was similar, adapting it to a rectangular, variable-dimension grid required a uniquely tailored approach.

The 8-Hour UV Battle & Refactoring
The next day was dedicated entirely to refactoring that spaghetti code and fixing the mesh generation. The chunks were generating, but the colours and mesh UVs were completely broken.

I spent 8 continuous hours trying to understand exactly how the UV coordinates were being calculated across the divided mesh. It was a gruelling process, but finally cracking the math and understanding how UVs map to dynamically generated vertices was a massive technical victory. The connections (seams) between the chunks are not yet 100% perfect, but the system now flawlessly supports both square and rectangular maps.

Architecture and Polish
For the remainder of the week, I focused on architectural polish and adjustments:

Procedural Gradients: I completely changed how the terrain calculates colour, shifting from a static list of colours to a dynamic gradient system for smoother transitions.
Separation of Concerns: Drawing on standard software engineering practices, I divided the monolithic generation code into distinct, single-responsibility scripts. The architecture is now much cleaner and highly scalable.
Destructible Integration: Finally, I integrated the destructible terrain system to work seamlessly with the new chunks. It is not fully optimised for performance yet, but the core functionality is there.

Reflective Practice: The Cost of Custom Solutions
This week reinforced a hard truth about game development: custom solutions are time-consuming. Straying from standard, squared-chunk tutorials to build a flexible, rectangular system cost me days of debugging complex math and UV rendering issues. However, the architectural payoff, having a highly modular, decoupled system, was worth the initial frustration. It highlighted the importance of balancing rapid prototyping with clean code principles.

Action Plan for Next Sprint
While I would like to focus more on the terrain generation, I will be investigating how to implement the multiplayer functionality into our game.

Thank you so much if you made it this far into the technical weeds!

See you next week for another update! 🛼🤟🏽

References:

Lague, S. (2016) Procedural Landmass Generation (E07: Endless Terrain). Available at: https://www.youtube.com/watch?v=WP-ZiClmqWE (Accessed: 7 March 2026).

Micro games

Jesús Pineda — Mon, 16 Mar 2026 20:57:08 +0000

Hey Gamers! 👾

As part of the Rapid Games Prototyping module, we are tasked with reviewing a peer's game. The challenge is to analyse a prototype built in just one week, so here is my latest review!

The theme for this week was "Microgames" with the modifier "Mash Up." This implies a WarioWare-style paradigm, where individual mini-games are integrated into a single sequence, played one after another with escalating difficulty. Because of this unique format, today I won't be reviewing a single game, but rather dissecting a few standout mechanics from the collection.

Magical Girl Transform!!!

Creativity is the strongest pillar of this microgame. The gameplay is elegantly simple: make the required pose to defeat the villain, but it feels incredibly rewarding. The challenge scales perfectly as the difficulty ramps up, and it excels at delivering a highly satisfying animation as a payoff.

This game is a brilliant example of taking a complex technical system, such as Inverse Kinematics (IK), and distilling it into a highly accessible, minimalist gameplay loop.

The B Wizard

This was easily one of my favourites for three distinct reasons:

Scope: Typing games are perfect for microgames because they offer immediate engagement in a short time frame.
The Twist: Unlike standard typing games where you type exactly what you see, this prototype forces a cognitive twist: you must do a letter replacement on the fly (replacing every 'A' with a 'B').
Worldbuilding: The mechanic ties directly into the lore from Blake's very first prototype in this module, where a wizard stole the letter 'A' and forced the world to use 'B' instead. Continuity across weekly prototypes is a fantastic touch!

Cat Slap

The physical mechanics of swiping the mouse were explored heavily by Toby this week across various prototypes, but Cat Slap stood out the most. Why? Because it absolutely nails the satisfaction at gaming. The visual feedback is incredibly satisfying, seamlessly matching the on-screen reaction with the physical, kinesthetic movement of the player's mouse.

Healer POV
Healer POV

As a World of Warcraft healer myself, this prototype immediately caught my attention. I am quite a fan of the clicker/idle genre, but designing a good one is notoriously challenging. How do you make repetitive clicking engaging? The concept of healing a tank via a clicker mechanic is highly clever. While I believe the core loop has the potential to introduce more challenging resource management, it delivers perfectly on the "healer fantasy." It provides both the stress of keeping a tank alive and the inherent satisfaction of making a number go up.

Reflective Practice: The Power of Minimalism
This week made me realise the immense value of microgames as a development tool. They are the perfect environment to quickly playtest an isolated mechanic and gauge player feedback before expanding it. By simplifying an idea down to its most minimalist core, you quickly discover if a mechanic is actually fun, or just masked by complex systems.

Action Plan for Next Sprint Inspired by this week's microgames, my goal for the next prototyping sprint is to apply this minimalist philosophy to my own work. I will focus entirely on a single mechanic. Instead of adding more and more systems into a game, I will spend my extra time purely on refining and balancing one mechanic.

See you next week for another update! 🛼🤟🏽

Procedural Gradients, Hotfixes, and the Power of QA

Jesús Pineda — Sat, 07 Mar 2026 14:48:57 +0000

Hellu, and welcome back to another weekly update for A Wargame Without Compromise (WWC)! 👾

This sprint was a masterclass in time management and the iterative nature of game development. The beginning of my week started a bit slower than usual; balancing the heavy workload from my Rapid Games Prototyping (RGP) module and personal commitments meant I had to be highly strategic with my time once I jumped back into the WWC codebase.

Agile Rituals & Scope Management
We kicked off our weekly meeting with our now-standard "Rose, Bud, Thorn" retrospective, which continues to keep our team communication healthy and transparent.

First, we addressed an issue with the Unit Movement. We made a strict scope-management decision. Rather than rewriting the entire movement system in one day, which could introduce new bugs and block the team, we implemented an easy hotfix. This stabilised the build immediately and allowed us to keep moving forward without feature creep.

Technical Spotlight: Procedural Texturing & Animation Curves
My primary focus this week was bringing the map to life. I finished the core documentation for the map generation and moved directly into colour texturing.

To achieve a natural look, I researched Sebastian Lague's highly regarded procedural generation techniques and adapted them to fit our specific grid system.

Animation Curves: Instead of relying on the Perlin Noise height values, I implemented an AnimationCurve in Unity. This exposes the data to the inspector, giving us visual, granular control over the terrain's height distribution without touching the script.
Seamless Gradients: To prevent harsh lines between different biomes (e.g., sand transitioning abruptly to grass), I engineered a system to apply colour gradients. The colours now blend seamlessly based on the vertex height data, making the environment look significantly more organic.

The best moment of the week was seeing our QA in action. Allen did a phenomenal job pushing the map generator to its limits. He created some incredibly creative, complex maps that I hadn't even imagined were possible with my current implementation. Seeing the system's flexibility validated all the hard work; it was incredibly rewarding.

The rest of the team has been crushing it as well. The UI is now successfully integrating with character actions, and new mechanics, such as the die system, have been merged. The most exciting news? The game is currently in a playable state!

My kudos this week go to Mohamed. Despite having very limited time due to personal reasons, he improved his output tremendously and successfully delivered his tasks. Recognising and supporting teammates when they push through external challenges is what makes a great studio culture.

Reflective Practice: Research vs. Iteration
My biggest takeaway this week involves the balance between immediate implementation and technical research. When implementing the terrain colours, I realised that some of the foundational work I did in previous sprints could have been significantly enhanced had I studied resources like Lague's tutorials before writing the initial code.

While I simply didn't have the time to do that deep-dive research weeks ago, this experience reinforced a valuable lesson: taking the time to review existing industry solutions before building custom architecture almost always yields a more robust result. However, I also recognise that in Rapid Prototyping, getting a functional baseline first and iterating later (as I did this week) is a valid and necessary approach to keep a project moving.

Action Plan for Next Sprint
Looking ahead, my goals are:

Robust Refactoring: I will take my current terrain generation implementation and make the architecture more robust, applying the structural lessons I learned this week.
Standalone Repository: I plan to organise the code and move it into my own standalone repository to share my work and use it as a portfolio piece.

Thank you so much if you got here!

See you next week for another update! 🛼🤟🏽

Reaching the Demo

Jesús Pineda — Mon, 02 Mar 2026 18:44:36 +0000

Hellu, and welcome to my fourth week at A Wargame Without Compromise (WWC)! 👾

Our primary goal for this sprint was to finally deliver a playable version of our game. We had a higher capacity this week because our other module assignments did not overlap, but we still faced a massive mountain of integration work.

Early in the sprint, I spotted a critical workflow issue, multiple team members were working on similar core files simultaneously, most notably the GameManager. The GameManager was still under active development, but it was a hard dependency for everyone else's features to function properly.

To unblock the team and prevent catastrophic merge conflicts, I took the initiative to restructure our version control workflow. I created a centralised dev branch based on main. I then integrated the work-in-progress GameManager into this dev branch and updated all other active feature branches to point to it. This allowed everyone to use the current state of the core architecture without breaking the main production branch, drastically reducing the risk of major merge conflicts down the line.

My specific feature task was relatively straightforward, create a bullet trail particle effect when a character shoots. It was really enjoyable to continue messing around with Unity's particle systems. However, while the visual trail itself was not difficult to create, I severely underestimated the time required to integrate it into the codebase. Because our systems were not properly connected at the time of completion, the integration took much longer than anticipated.

My final effort of the week was assisting Josh in assembling the actual Demo build just before our team standup meeting. I felt that this sprint involved a lot of rushing, trying to integrate code, resolve dependencies, and update scripts simultaneously. It was a bit exhausting, but seeing the playable game made it absolutely worth it.

I want to give kudos this sprint to Allen, who invested a lot of time into researching and implementing the Game Manager System!

Action Plan for Next Sprint
With the demo ready, I can finally return to my favourite area: algorithms!

Terrain Generation: I will continue updating the procedural terrain. If time permits, I aim to implement texturing and potentially some foliage algorithms.
Capacity Planning: I have a heavy workload in other areas next week, so I will ensure I strictly time-box my terrain tasks to avoid overcommitting.

Reflective Learning
While everything came together in the end, the "integration crunch" was a wake-up call. We need to pay much closer attention to the code's architecture. This sprint taught me that a feature isn't truly "done" until it is cohesively integrated. Moving forward, we need to communicate our dependencies earlier to avoid this disjointed scramble at the end of the sprint.

Thank you so much if you got this far!

See you next week for another update! 🛼🤟🏽👻

References:

Driessen, V. (2010) A successful Git branching model. Available at: https://nvie.com/posts/a-successful-git-branching-model/ (Accessed: 23 February 2026).

Competitive Puzzles

Jesús Pineda — Sun, 22 Feb 2026 16:27:35 +0000

Hey Gamers!

As part of the Rapid Games Prototyping module, we are tasked with reviewing a peer's game every two weeks. The challenge is to analyse a game built in just one week, so here is my weekly review!

The theme for this week was "The Greatest Tournament" with the modifier "Monochromatic". My pick for the week? Discoku, a competitive Sudoku type game, in a 1v1 form, using colors instead of number.

First Impressions
My immediate thought upon playing was simply: "This is very clever." The name itself is genius, and as a Sudoku lover, I grasped the core loop incredibly fast. The experience felt a lot like playing competitive Tetris, intense, high-stakes, and a lot of fun!

Mechanics & Balancing
The mechanics are simple but rewarding. You navigate the Discoku grid, randomly, and a "blocker power" appears on the screen, which, when the first player presses the ability button, freezes the other player's grid for a short time.

However, this mechanic highlights a balancing issue. Currently, the blocker power rewards players' speed on the keyboard, allowing them to pull further ahead if they are already ahead, which can be frustrating for the losing player. To improve the user experience, the game would benefit from a "catch-up" mechanic. As seen in games like Mario Kart or Crash Team Racing (Shortcat, 2023), giving the most powerful items to the players who are behind helps balance the scales and keeps the match tense until the very end.

Additionally, the control scheme required a full-length keyboard (using the right-side numpad) for the second player. For better accessibility, utilising the arrow keys would have been a more universal choice.

Visuals & UX
The music and visual aesthetic added a lot of appeal; it genuinely felt like being in a disco, making it highly immersive! However, there was a minor User Experience (UX) flaw regarding visual hierarchy. Because of the monochromatic modifier, it was difficult to notice which cell in the grid was selected (it was only slightly darker than the rest). Highlighting the active cell with a bolder outline would have greatly improved player navigation.

Reflection: How this influences my work
Playing Discoku made me reflect on the concept of "Games with a twist" and how adding or removing a single element changes the entire feel of a game.

Once again, this week I found myself focusing too heavily on complex backend systems. I strayed so far from my initial vision that my core gameplay loop (inspired by "Musical Chairs") was completely lost. I ended up twisting the mechanics to fit a forced narrative, which ultimately resulted in a game that felt a bit creepy rather than fun. Seeing the effective simplicity of Discoku was a wake-up call.

My primary goal for next week's prototype is to implement a very simple mechanic and polish the "game feel" until it shines. I may still explore complex systems to learn new things, but they will be strictly treated as "nice-to-have" features, not the end goal.

Conclusion
Discoku is a fantastic, highly enjoyable prototype. It delivered perfectly on the theme and offers an exciting, fresh twist for puzzle lovers!

References

Shortcat321 (2023) Are ITEMS based on DISTANCE in Mario Kart 8 Deluxe? Available at: https://www.youtube.com/shorts/rmLS3YB9uYA (Accessed: 22 February 2026)

Scoping and Lerp

Jesús Pineda — Sat, 21 Feb 2026 14:51:28 +0000

Hellu, and welcome to my third week at A Wargame Without Compromise (WWC)! 👾

For this sprint, our primary goal was to deliver our first playable demo. It was a challenging objective; while we had all the individual pieces built, the real test was connecting them. Predictably, we ran into some complications.

Capacity was our first hurdle. We should have limited our sprint scope, taking into account that half the team had demanding external work commitments over the Valentine's Day weekend. Furthermore, we experienced some workflow disconnects. We were developing individual features, but the centralising architecture, specifically the State Machine and Game Manager, was not ready yet.

We expected the State Machine to be finished earlier in the sprint to allow for seamless integration. Sadly, we underestimated the scope of this task because the team wanted to ensure the system was robust. This delay is not the end of the world; it is a common pitfall in new projects when integrating systems with which the team has limited prior experience. We overcame this bottleneck by having a discussion to refine the State Machine's requirements and doing some knowledge transfer. The key takeaway from this sprint is the necessity of better refinement and realistic capacity planning before a sprint starts.

In addition to supporting the team's core goals, my specific tasks for this sprint included:

Refining the Rewind Ability: Resetting the rewind points after an action other than moving was triggered.
Smoothing Terrain Under Buildings: Modifying the flat terrain around newly placed buildings to look more natural.
Terrain Deformation: Creating visual craters in the mesh upon collision.

Rewind Ability Refining
This was straightforward to implement. With the Event Handler already in place, I simply listened for the shooting event and cleared both the rewind and fast-forward stacks when it triggered.

Smoothing the Terrain
To tackle terrain smoothing, I had to map out the math on paper first. Following a discussion with our tutor about the concept of Lerping (Linear Interpolation), the area around a building, I researched distance calculations. I found an excellent resource by Quilez (2019) detailing mathematical formulas for shapes and point distances. This helped me understand how to calculate the distance from a given point and Lerp the altitude based on that distance, the building's base altitude, and the current point's altitude. I iterated through the gridMap[][] area (adding a margin) and discarded the strictly occupied points using the occupiedMap[][] so the terrain directly underneath the building wouldn't be altered. This is the result:

Terrain Deformation
Initially, I thought deforming the mesh would be highly complex because I wasn't sure how to pinpoint the exact collision coordinates. It turned out to be quite manageable. Unity’s OnCollisionEnter method provides a Collision object containing the contact points. Using that precise point, I looped through the surrounding vertices matrix of the mesh, calculating the Pythagorean distance to ensure the crater was circular rather than box-shaped, and applied a Lerp to deform the area.

Having finished the task ahead of schedule, I added some particle effects to make the crater visually appealing. This was a great opportunity for me to step outside my pure-code comfort zone and learn something new about VFX and game feel. This is the result:

Action Plan for Next Sprint
Our goal of a fully playable demo remains. To achieve this, my concrete action plan is to step back from terrain generation features and dedicate my time to stabilising the gameplay and codebase. I will assist in fully integrating the State Machine with the rest of the game's mechanics.

My teammates have developed some fantastic systems this week, such as piercing shooting mechanics and a UI system to track unit status. Finally, I want to give my kudos to Josh this week! As a leader, he has planned effectively around our delays to ensure the best possible outcome for the team.

Thank you so much if you got this far!

See you next week for another update! 🛼🤟🏽👻

References:

Quilez, I. (2019) The SDF of a Box. Available at: https://www.youtube.com/watch?v=62-pRVZuS5c (Accessed: 18 February 2026).

Team building and Game Dev

Jesús Pineda — Wed, 11 Feb 2026 22:18:49 +0000

Hellu, and welcome to my second week at A Wargame Without Compromise (WWC)! 👾

This week began with a code review of our previous deliverables. It was empowering to see every team member explain their achievements; the commitment to individual tasks is high, and the receptiveness to feedback has created a very positive environment. However, due to increased academic workload from other modules, our team had limited availability this sprint. Consequently, we adjusted our scope to be realistic, a crucial practice in Agile development to avoid burnout.

My primary goal was to finalise the building placement system. The map now supports a list of buildings that are automatically placed without overlapping. I used the Occupancy Grid Mapping Nirwan (2021) to verify whether the space in the grid was already taken or not. To solve the issue of the environment looking static or "boring," I implemented a random rotation system.

Implementation: Buildings now instantiate with discrete rotations (0, 90, 180, 270 degrees). This adds visual variety while maintaining the grid-like structure required for gameplay.

During our Monday meeting, I proposed a "Rose, Bud, Thorn" session LUMA Institute (no date), to serve as an icebreaker before diving into technicalities. Drawing from my previous professional experience, where my ex-teammate Ashley used to like doing these sessions and I think they are really fun! I found that Discord chats can feel quite "cold".

Rose: A highlight/success.
Thorn: A challenge/pain point.
Bud: A new idea or something to look forward to.

The group was very receptive. This exercise isn't just for fun; it effectively builds psychological safety, allowing us to understand each other's emotional states before critiquing work. It bridged the gap that digital communication often creates.

We also focused on refining workflows and QA. Allen has proven invaluable in this regard, adopting a "breaker" mindset, pushing features to their limit to find edge cases. He discovered an issue with the map size limits, which we have now capped to prevent performance degradation. Catching this in the early stages saved us significant refactoring time later.

It wasn't all smooth sailing. I spent significant time assisting Allen with Git LFS (Large File Storage) conflicts, specifically regarding the Wwise audio integration.

The Issue: Binary files were not locking correctly, causing merge conflicts.
The Fix: We implemented a temporary workaround, we couldn't fix the LFS issue on his branch so we created a new one, fresh from main, but with the .gitignore and .gitattributes updated before the Wwise integration, but this consumed valuable development time.

I finished the sprint by developing the Movement Restriction System based on stamina and time manipulation.

Rewind mechanic overview: The player now features a Stamina system where movement consumes energy based on a Stamina Per Step property.

By pressing the Toggle Rewind key, the player enters Rewind Mode. In this state, the player can:

Hold Rewind: Backtrack through previous positions to recover spent stamina.
Hold Fast Forward: Return toward the "future" point if they have already backtracked.

The process is finalised by pressing Toggle Rewind again. This commits the changes, restores the calculated stamina, and clears the Fast Forward buffer while maintaining the history for further rewinding.

Logic: I utilized the logic demonstrated by Brackeys (2017) regarding storing transform data in lists, but adapted it to store "Stamina States" rather than just positions, also, instead of using Lists to keep track of the points where the player was, I used Stacks, GeeksforGeeks (2026), since their use case was better in this situation, because we always remove the last visited position.

Action Plan for Next Sprint: I want to make the team more involve on Discord discussions. When we meet in person, everyone shares their ideas and thoughts about our process, development, and mechanics, but on chat, not everyone does. I think a good idea would be to encourage emoji reactions, at least to know if everyone agrees with the ideas, or if they have read the chats.

I'm very happy with the outcome of the week, we have made a lot of progress given our time constraints, I feel that next week we will have a very very good progress.

Thank you so much if you got here!

See you next week for another update! 🛼🤟🏽

References

Brackeys (2017) REWIND TIME in Unity. Available at: https://www.youtube.com/watch?v=eqlHpPzS22U (Accessed: 11 February 2026).
GeeksforGeeks (2026) Stack Data Structure. Available at: https://www.geeksforgeeks.org/stack-data-structure/ (Accessed: 11 February 2026).
LUMA Institute (no date) Rose, Thorn, Bud. Available at: https://www.luma-institute.com/rose-thorn-bud (Accessed: 11 February 2026).
Nirwan, D. (2021) Occupancy Grid Mapping with Webots and ROS2. Available at: https://towardsdatascience.com/occupancy-grid-mapping-with-webots-and-ros2-a6162a644fab/#:~:text=The%20occupancy%20grid%20mapping%20is,spaced%20binary%20(random)%20variables. (Accessed: 6 February 2026).

Why Simple Mechanics Win in Prototyping?

Jesús Pineda — Mon, 09 Feb 2026 02:37:55 +0000

Hey Gamers!

As part of the Rapid Games Prototyping module, we are tasked with reviewing a peer's game every two weeks. The challenge is to analyse a game built in just one week, so here is my first review!

The theme for this week was From A to B with the modifier Off-screen: implement a real-world element into the game". The result? Rat with a Gun (LifeIsForLego, 2026), a physics-based platformer where you must use the recoil of a gun to propel a rat through the air.

First Impressions & Onboarding One of the strongest aspects of the prototype was that no tutorial was needed. All controls were explicitly displayed on-screen. This approach, similar to The Binding of Isaac or many Ubisoft titles, is incredibly valuable in a Game Jam or prototyping setting. When there are dozens of games to test, time-to-fun is a huge factor, and this game respects the player's time immediately.

Mechanics as Difficulty Sliders The reloading mechanic was particularly clever, it "spices up" the gameplay while acting as a hidden, organic difficulty slider. As discussed by GMTK (2024), games like Super Mario often include elements that allow players to adjust the difficulty through their own playstyle. In Rat with a Gun, bullets reload one by one when you touch the ground. If you want an "easy mode," you can simply wait for a full reload. However, for a "hardcore" experience, you can wait strictly for the necessary bullets and speedrun the level. This execution was simple yet profound.

The "Juice" and Emergent Gameplay It is impossible to ignore the pigeons. They explode upon death, which is both satisfying and hilarious. During our feedback session at the university, the entire room laughed when the explosions triggered.

However, since the core mechanic is physics-based, a strong addition would have been to apply directional force to the character from these explosions. This could introduce emergent gameplay, allowing players to use enemies to reach previously inaccessible platforms or add chaos to the movement.

Visuals & Polish There were a few minor issues regarding clarity. The colour contrast of the spikes made it difficult to see how many bullets were left in the UI, and there were issues with some platforms, so that they seemed that you could go below one platform, but in fact, your movement was locked with the platform from above. However, the overall aesthetic was cohesive, and nothing felt out of place.

Reflection: How this influences my work Analysing Rat with a Gun has shifted my perspective on my own prototyping process. I tend to focus heavily on complex systems, but seeing how much enjoyment players got from the simple "pigeon explosion" feedback loop reminded me that "game feel" (juice) is just as important as the code behind it.

Inspired by the effective simplicity of Rat with a Gun, for my next prototypes, I plan to shift my focus toward the creative process, such as 3D modelling and 'game feel', instead of prioritising complex algorithms. While I feel confident in my technical implementation skills, this review reminded me that I should explore aspects where I am less experienced to become a more well-rounded game developer.

Conclusion The ending was hilarious, and the inclusion of a second gun showed great potential for progression. While it doesn't radically reinvent the "From A to B" theme, it is a fantastic execution of a user-centric idea. You don't play this thinking, "How is the theme integrated?" but rather, "This movement is cool!"

From my perspective, with more time, this game has the potential to become a really good Rage Game, like "Getting Over It with Bennett Foddy game type", "Golfing Over It with Alva Majo" or "I wanna be that guy", which are platformer games with the idea is get as high as possible with some difficult controls or physics. With more levels, it can be a successful speed run game

GGs, WP! 👾👻

References

Brown, M. (2024) Super Mario's Invisible Difficulty Settings. Available at: https://www.youtube.com/watch?v=gkvyYTSKTQY (Accessed: 9 January 2026).
LifeIsForLego (2026) Rat with a Gun [Downloadable game]. Available at: https://lifeisforlego.itch.io/rat-with-a-gun (Accessed: 2 February 2026).