Coder Legion - Recent posts tagged gamedesign

Tea House Area - Fencing, Pathways, Pond Area | UE5 Devlog

Tue, 20 Oct 2026 22:36:46 +0000

In this Life of Alex devlog, I continue building the tea house area at Kazuhara Resort in Unreal Engine 5. This update focuses on defining the space with fencing, adding stones along the pathways, and introducing a pond with a bridge and fencing around its edges.

Piece by piece, the area is taking shape, with clearer routes through the garden and more detail surrounding the tea house. Join me as I bring these elements together and continue shaping a peaceful setting to explore.

Free Game Legiones Galacticas

Sun, 11 Oct 2026 10:01:01 +0000

The Reality of Modern Indie Development (And Why I Keep Making Games Purely for Passion)

When I started developing video games, I quickly realized a harsh truth: selling an indie game today is incredibly difficult. The market is saturated, and in my personal opinion, if you really want commercial success, the only realistic path is through a publisher.

I’ve developed several games (which I’ll talk about later, like my upcoming post on RoboFigther!), but I’ve never sold a single one. And honestly, it’s the best decision I’ve ever made. Developing purely as a hobby and out of passion has given me a freedom that commercial development often destroys.

From this philosophy, my latest project was born: Legiones Galácticas: Hijos de la Furia, a vertical-scrolling arcade shoot 'em up developed entirely in HTML5.

https://coderlegion.com/30663/legiones-galacticas

After months of writing code, tweaking mechanics, and balancing difficulty, here are the 4 biggest lessons I’ve learned from making games just for the love of the craft:

1. Creative freedom is priceless
By not having to worry about monetization, in-app purchases, or user retention metrics, I was able to focus on the only thing that mattered: making a fun game. I wanted frantic action, waves of UFOs, asteroids, and lasers, and that’s exactly what I built. No compromises.

2. The magic of "Zero Friction" (Why I chose HTML5)
Nowadays, asking a player to download and install an unknown indie game is asking too much. I chose to develop Legiones Galácticas in HTML5 to remove that barrier. I wanted anyone to be able to click a link and, in two seconds, be piloting a spaceship from their browser, with no downloads or endless loading times.

3. The challenge of balancing difficulty
Making an arcade game is easy; making a fair arcade game is very hard. Learning how to program difficulty progression, shield spawns, and weapon upgrades (from burst fire to continuous lasers) taught me a lot about level design and user experience.

4. Accept that marketing is a different world
Since I’m not looking for sales, my "marketing" simply consists of sharing what I do with developer communities like this one. There is no pressure, no stress over ROI. Just the pure satisfaction of seeing others enjoy something you built from scratch.

Creating video games is a massive technical challenge, but enormously rewarding. Legiones Galácticas is my little love letter to classic arcade cabinets. It is a completely free game, and you can play it directly from your browser here:
👉 https://sites.google.com/view/nekagames-es/videojuegos/legiones-galácticas

I’d love to hear what the rest of the community thinks: Do you develop with the hope of selling and making a living out of it, or do you also do it purely out of passion and as a hobby like me? Let me know in the comments!

Legiones Galácticas

Sun, 11 Oct 2026 01:22:26 +0000

https://sites.google.com/view/nekagames-es/inicio

What is Legiones Galácticas?

Legiones Galácticas: Hijos de la Furia is a vertical-scrolling arcade Shoot 'em up game, developed entirely in HTML5 by NekaGames. I created this game completely as a personal hobby project out of my passion for classic arcades. It is a fully featured game and 100% free to play directly from your web browser, with no installation required.

Key Features

In this title, you take command of a combat ship to defend the galaxy from incoming alien waves.

Pure Arcade Action: Face fleets of UFOs, heavily armored enemy ships, and dodge deadly asteroid fields.
Dynamic Combat System: Upgrade your ship's arsenal on the fly with different weapon types (from burst cannons to continuous lasers) and use force fields (shields) to survive enemy impacts.
Web Technology (HTML5): Optimized for smooth performance and accessible from any modern web browser, showcasing how fun browser-based gaming can be.
High-Score Progression: A classic scoring system that will challenge you to beat your own record in every playthrough.

Who is it for?

It is ideal for fans of retro games looking for quick, challenging sessions, as well as for fellow developers interested in seeing a fun HTML5 passion project in action.

🎮 You can play the full game completely for free directly on the website!
https://6884a5c32f169382cd3909bc--endearing-bubblegum-728660.netlify.app/

Every Game Genre Is a Spec of Systems You Can Reuse

Sun, 04 Oct 2026 15:40:33 +0000

If you have ever wanted to build a small browser game on the side, the hardest call is usually what kind of game, not which framework. Here is how to read a genre the way you would read a spec, as a list of systems with a known build order.

A Genre Defines Done

A platformer is a game loop, a physics step for gravity and jumping, tile collision, a camera that follows the player and a level made of solid tiles. A tower defense game is a pathfinding grid, a wave spawner, turrets that target and fire, projectiles and an economy. Write that list down and the project stops being open ended. You know what finished looks like, and you can estimate it.

The Shared Parts

Most of those systems repeat across genres. The game loop is universal. Object pooling shows up the moment you have bullets or particles, so shooters, runners and tower defense all need it. A save system serves idle games, RPGs and card games alike. Collision sits under platformers, shooters and physics puzzles. That overlap is why a second game ships faster than the first, you are reusing modules, not starting over.

Start With the Smallest Spec

The idle or clicker game is the smallest real spec: a click that earns currency, generators that earn it passively, offline earnings and prestige. The interesting system is the cost curve. Each extra generator usually costs a fixed multiplier more than the last, around 15 percent, so cost = base x 1.15^owned while output climbs more gently. Tuning that curve is the whole difficulty, with no collision, physics or networking. The idle and clicker game walkthrough builds one from the first click to prestige.

Choose the Engine From the System List

For 2D genres built on sprites, tilemaps and arcade collision, Phaser ships most of those systems out of the box, and PixiJS gives you raw rendering when you want to own the architecture. For 3D, Three.js is a renderer you build on and Babylon.js is closer to a full engine. Multiplayer genres add a separate decision: WebSockets for transport and often a room server like Colyseus for authoritative state.

The Takeaway

Treat the genre as the spec, list its systems, and start with the shortest list. The guide to building each web game genre breaks down eleven genres with their systems, a recommended stack and an honest difficulty rating.

Procedural Generation Is A Rules Problem, Not A Randomness Problem

Fri, 21 Aug 2026 13:17:26 +0000

Most procedural generation threads turn into algorithm shopping lists, and the algorithm is rarely what went wrong. This is a writeup on the part that actually decides output quality, which is the structure you wrap around the random number generator.

Randomness Is Not Generation

A random number generator placing blocks at arbitrary positions produces visual noise. A procedural system that builds elevation from noise, runs erosion over it, assigns biomes from moisture and temperature gradients, then places vegetation by ecological rule produces something a player reads as a landscape.

The difference is that the rules encode design intent and the randomness only supplies variety inside them. When generated output feels wrong, the fix is almost always a missing constraint rather than a better noise function.

The Trade Has Not Changed Since 1984

Rogue generated dungeon layouts in 1980 so that each run was a new arrangement of rooms, corridors and monsters. Elite fit an entire galaxy of star systems into a few kilobytes in 1984 using mathematical seeds.

Both are the same bargain you make today: spend computation to save storage. What has grown is the pipeline, from a single RNG call to layered systems combining noise, grammars, constraint solvers and now models.

Determinism Is A Debugging Feature

The thing teams skip until it hurts is reproducibility. If a player reports that the world at seed 8815 was unwinnable and you cannot load exactly that world, you are debugging by guesswork.

That means every source of randomness has to run through the seeded generator, including the ones that sneak in later: hash iteration order, floating point differences across platforms, anything reading the wall clock. One unseeded call and the seed stops meaning anything.

Where Hand Built Content Still Wins

Generated content has a distribution and the bad tail ships too. Hand built content has no tail. That is why most shipped games run a hybrid: generated layouts assembled from hand made rooms, or a generated world with authored regions dropped into it, so the pieces are always good even when the arrangement is new.

Pacing is the other thing generators do not know. A generator cannot tell that the corridor before the boss should feel long.

Longer version covering the specific algorithms, noise functions, dungeon and level generation, wave function collapse, seeds and determinism, and where AI fits into this now: procedural generation for games

The Analyst's Problem: Volume III

Thu, 16 Apr 2026 14:50:52 +0000

Welcome to Volume III of The Analyst's Problem: Diagonal Dominance. In this video, we dive deep into the spectral defence simulation I've built to demonstrate how advanced mathematical concepts can entirely replace traditional video game mechanics.

Most games rely on simple Boolean logic and basic subtraction (e.g., Health = Health - Damage). In Diagonal Dominance, we throw that out the window and drive the entire game state using continuous mathematical operators, spectral decomposition, and graph theory.

Here is a breakdown of the unique equations driving the simulation, and how these concepts could revolutionise future game engines:

The Unique Equations Powering the Game:

Quadratic Form Decomposition
Projection Operator
Phase difference
Constructive interference

The Potential for Gaming Engines:
Why does this matter? Modern physics engines and game state managers are incredibly resource-heavy. By treating a game world as a complex network driven by Spectral Graph Theory and Quadratic Forms, we can simulate highly complex, interconnected environments using lightweight, continuous equations.

Imagine an RPG where a boss's "health" isn't a number, but a matrix of stability that players must mathematically destabilise through specific environmental actions. Or procedural destruction that calculates structural integrity via graph eigenvalues rather than pre-baked physics chunks. This is the future of systemic game design.

If you enjoyed this breakdown, let me know in the comments what mathematical concepts you'd like to see visualised as gameplay next!

Support & Follow The Analyst's Problem:
► Play/Fork the Code on GitHub: https://github.com/jmullings/TheAnalystsProblem
► Subscribe to the Channel: https://www.youtube.com/@TheAnalystsProblem
► Read the E-Book: https://www.amazon.com/s?k="The analyst’s problem"
► Support the Project on Patreon: https://www.patreon.com/posts/jason-mullings-155411204

Lowpoly3D to 2D Animations

Mon, 09 Feb 2026 19:12:09 +0000

Hi all,

Intro

So I've been working on a personal project of mine for 3 month or so now and I have reached a point where I am prepping for a public facing demo. I'm currently refining some visuals at this point in time and specifically I am focused in on re-working workflow for character visuals.

A little context beforehand. The project, Rebel Hearts: "Eclypse" is inspired by classic Tactical-RPGs such as Vandal Hearts. Vandal Hearts 1 was developed & published by Konami, released in 1996. The goal of this project was to explore grid-based, turn-based combat and multiplayer networking whilst building a foundation for larger game systems. I enjoyed Vandal Hearts and wanted to reproduce that, whilst expanding further with modern day technology and mulitplayer capability.

You can see more about this over here: Rebel Hearts Eclypse, here: Tactical battleground gameplay & here: Free roam gameplay

Now given the above, we'll know the general theme and style of "squad members" as art assets. I opted for a more up-to-date visual and wanted to breifly touch upon it's work flow and process.

Lowpoly3D to 2D Animations

Here, we can harness a more modern asthetic by rendering lowpoly3D models in our chosen game engine/renderer and recording that output. We are basically rasterizing and recording. Why this way? We can optimize and save huge processing power by re-importing the 3D capture of our low-poly 3D models and running them as simple 2D sprite animations. This VS computing and rendering many 3D models is huge in terms of CPU-GPU cycles. It isn't however a all encompassing fit solution. This just makes sense in the context of this particular project' theme and style.

So here, we are using the Unity Engine, specifically version 2022.3.20f1currently. We setup a fresh new scene to setup our low-poly 3D models.

We will need to make use of a "RenderTexture" in order to enable us to record what is rendered to the camera.This render texture must be assigned to the camera we are using and our C# script that will assist with the 3D capture.

The script is light weight and effective. We supply a public bool checkbox for the inspector when we'd like to capture what the camera renders upon running. When we play, we effectively record until we stop. This is output to a folder-directory named "Frames". It is here, where we grab our raw .png output frames and throw into another tool for refinements and adjustments. I usually use Aseprite, as it's light weight and effective for these types of assets.

The below is our simple script for aiding us in this work flow.

using System;
using System.IO;
using UnityEngine;

namespace RebelHeartEclipse
{
    public class _3DLowpolyTo2DRecorder : MonoBehaviour
    {

        public float PixelsPerUnit;// = 256f;//128f;
        public Camera CaptureCamera;
        public RenderTexture RenderTexture;
        public int FrameIndex = 0;
        public bool RecordFramesUponPlay;

        private Transform _transform;

        private void Awake() => Setup();

        private void Setup()
        {
            _transform = this.transform;


        }

        private void LateUpdate()
        {
            PixelSnapLateUpdate();
            RecordFramesLateUpdate();
        }
        private void PixelSnapLateUpdate()
        {
            Vector3 pos = transform.position;
            float snap = 1f / PixelsPerUnit;

            pos.x = Mathf.Round(pos.x / snap) * snap;
            pos.y = Mathf.Round(pos.y / snap) * snap;
            pos.z = Mathf.Round(pos.z / snap) * snap;

            _transform.position = pos;
        }

        private void RecordFramesLateUpdate()
        {
            if (!RecordFramesUponPlay) return;
            if (CaptureCamera == null) return;
            if (RenderTexture == null) return;



            RenderTexture.active = RenderTexture;

            Texture2D tex = new Texture2D(
                RenderTexture.width,
                RenderTexture.height,
                TextureFormat.RGBA32,
                false
            );

            tex.ReadPixels(
                new Rect(0, 0, RenderTexture.width, RenderTexture.height),
                0,
                0
            );
            tex.Apply();

            byte[] bytes = tex.EncodeToPNG();
            File.WriteAllBytes(
                Application.dataPath + $"/Resources/Frames/frame_{FrameIndex:D4}.png",
                bytes
            );

            FrameIndex++;

            RenderTexture.active = null;
            Destroy(tex);
        }

        private void Update()
        {
            
        }


    }
}

This concludes this breif post. It is a relatively short post and somewhat surface level but I intend on posting more further along down the line.

Any thoughts and comments are welcome, please do share if any!

Have a great day,

Rick