Infinicity

About this game

Latest news

• Announcements·26 Dec 2025Official

  Procedural Object Placement with Variable-Radius Poisson Disk Sampling and noise

  When generating large procedural worlds, placing objects believably is harder than it looks.Trees shouldn’t overlap. Rocks shouldn’t clump unnaturally. Buildings need breathing room. And ideally, all of this should be controllable, performant, and compatible with procedural generation.A few years ago, while working on procedural world generation for my game, I ran into exactly this problem i.e. placing objects of varying sizes, driven by noise, with zero overlap.This post is a write-up of how I approached that problem, what didn’t work, and the solution I ended up shipping.The ProblemAt a high level, I wanted to:Place objects procedurally across a 2D surfaceAllow each object to have a different radiusGuarantee no overlapRetain a natural, non-grid-like distributionBe able to bias density using noise or gameplay logicClassic Poisson disk sampling gives you a nice "even but random" distribution but it assumes a fixed minimum distance between points. That assumption breaks down immediately when object sizes vary.Why Standard Poisson Disk Sampling Falls ShortTraditional Poisson disk sampling works by enforcing a single global minimum distance between samples. That’s great if every object is the same size.But once you introduce variable radii:A small object can sit comfortably near another small objectA large object needs more spaceThe minimum distance is no longer constantYou can try to cheat by inflating everything to the maximum radius but that leads to:wasted spaceoverly sparse distributionsloss of detail where small objects should be denseIn short: the distance constraint needs to be local, not global.Idea: The Radius Is the ConstraintInstead of thinking in terms of "points with a minimum distance" I reframed the problem as:Each object has a radius, and no two objects' influence circles may overlap.That seems obvious in hindsight, but it changes how you structure the algorithm.Instead of asking:"Is this point at least D away from others?"You ask:"Does this object’s r...
  Read full article on Community Announcements (bensan.morris)

• Announcements·17 Dec 2025Official

  Turning Real Footage into Game Animations (and Why I Open-Sourced the Tool)

  One of the challenges I’ve been thinking about a lot while working on Infinicity is animation.I wanted characters that feel hand-animated and expressive but without relying on huge animation budgets or locking myself into a very rigid art style. I also wanted a workflow that lets me iterate quickly i.e. change timing, style, or scale without redoing everything from scratch.That led me down an interesting rabbit hole: Can I turn real video footage into clean, stylised sprites that actually work in-game?It turns out: yes (but not without a bit of engineering).The problemTraditional sprite animation usually means:drawing every frame by hand, orrelying on skeletal animation that doesn’t always fit a specific styleBoth approaches are valid but they can be slow to iterate on, especially when you want to experiment.What I wanted instead was:to capture simple footage (even just me in front of a wall),extract only the person cleanly,and then turn that into animation-ready sprites that I could stylise and tweak.The solution (high level)I ended up building a two-stage pipeline:Stage A High-quality person extractionThis stage uses a research model called Robust Video Matting to separate a person from the background across an entire video, producing clean RGBA frames with proper edges (hair, limbs, motion blur, etc.).This step is slow and compute-heavy, but it only needs to run once per video.Stage B Game-focused post-processingThis stage is fast and highly tweakable. It:crops the animation consistentlynormalises everything to a fixed sprite sizeskips redundant frames automaticallyapplies pixel-art style quantisationpacks everything into a spritesheet with metadataThe important bit is that Stage B can be rerun endlessly with different parameters, without redoing the expensive extraction step.That makes experimenting with animation style and timing much more fun.Why this matters for the gameThis pipeline exists for one reason: to make the animations in Infinicity better and more ...
  Read full article on Community Announcements (bensan.morris)

• Announcements·13 Dec 2025Official

  Player moddable terrain feature added

  I’ve added a new feature that lets players tweak the mountain noise layers in real-time. Previously, the terrain was generated using layers of noise with fixed frequency and amplitude. Now players can adjust these parameters to shape the mountains exactly how they like whether that’s jagged peaks, rolling hills, or something in between.This gives a lot more expressive freedom while exploring or creating in the game. It’s a small change under the hood, but it opens up possibilities for player created personalized landscapes to help support an additional layer of player created gameplay challenges.Some examples:See the video below for a sneak preview:
  Read full article on Community Announcements (bensan.morris)

• Announcements·9 Dec 2025Official

  Dev Blog: Tile caching

  Tile Caching = 159x Faster City StreamingToday I want to share a technical update rather than a visual one but it’s a huge boost for performance. My game uses procedural city tiles. Generating a full city tile costs around 1 millisecond. When the player is flying fast over the world, dozens of tiles may need to be created quickly, and that can become a bottleneck even when each tile is loaded in a background thread (actually as a tile load task serviced by a fixed sized pool of threads). So I implemented a tile caching system and the speedups are dramatic.Benchmark ResultsHere’s how long each operation now takes:Full city generation: 1.08 msGenerate + save to cache (first time): 4.09 msLoad from cache (disk hit): 6.79 µsLoad tile already in memory: 6.8 nsThat means loading from cache is roughly 159x faster than generating a tile from scratch. That’s a huge performance win for streaming an open world.How the Cache Works The core idea is simple:Generate the tile once.Serialize the result to disk.Next time, load it instead of regenerating it.Some technical details:I compute a BLAKE3 hash of the map file to detect changes. If the map changes, the cache automatically invalidates.Each tile uses a filename based on its coordinates, e.g. 5_7.bin.Tile requests return a std::shared_future, so only the first thread generates the tile others wait for the same result.The system is fully thread-safe and works perfectly with my streaming worker threads.Where the Cache LivesThe game ships on Steam for Windows and Linux, including AppImage builds. AppImages are mounted as read-only, so the cache must go into the player’s writable directories, not beside the game files. Here’s where tile cache files are stored: Windows: %LOCALAPPDATA%/Infinicity/TileCacheLinux / Steam Deck: $XDG_CACHE_HOME/Infinicity/TileCache or ~/.cache/Infinicity/TileCacheThis keeps everything clean, safe, and consistent with OS conventions. What I (re)LearnedCaching procedural data is a massive win for performanc...
  Read full article on Community Announcements (bensan.morris)

• Announcements·15 Nov 2025Official

  Dev Diary: Modding support

  I've been adding in modding support and wanted to share its progress.The modding feature allows a player to direct the 3D procedural generation (biome layout, enemies, objectives etc) by way of a simple 2D map editor. The map editor enables hassle free, quick and easy creation of worlds and challenges by allowing the user to simply paint layers onto the map (a grid). Once saved, clicking play launches the player into their creation.Painting a city and enemy layout and then flying through trying to survive your creation is actually a lot of fun (see below for a work in progress preview).
  Read full article on Community Announcements (bensan.morris)