<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Ecs on Lorbic</title><link>http://localhost:1313/tags/ecs/</link><description>Recent content in Ecs on Lorbic</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sat, 08 Aug 2026 10:00:00 +0530</lastBuildDate><atom:link href="http://localhost:1313/tags/ecs/index.xml" rel="self" type="application/rss+xml"/><item><title>Part 4: Refactoring to SoA ECS: Bitmasks and Flat Component Arrays</title><link>http://localhost:1313/structure-of-arrays-ecs-bitmasks-golang/</link><pubDate>Sat, 08 Aug 2026 10:00:00 +0530</pubDate><guid>http://localhost:1313/structure-of-arrays-ecs-bitmasks-golang/</guid><description>&lt;p>When I started building &lt;em>Derelict Facility&lt;/em>, my initial instinct for game actors was standard Object-Oriented design: create an &lt;code>Entity&lt;/code> struct, add pointers for position, sprite, and stats, and store them in a slice (&lt;code>[]*Entity&lt;/code>).&lt;/p>
&lt;p>It worked fine for five entities. But as soon as I added automated doors, save terminals, and active power grids across a 1000-tile map, keeping track of separate heap pointers became a headache. My Go profiler showed GC pauses spiking while the CPU spent more time chasing heap pointers across non-contiguous memory than actually updating game state.&lt;/p></description></item></channel></rss>