<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
     xmlns:atom="http://www.w3.org/2005/Atom"
     xmlns:content="http://purl.org/rss/1.0/modules/content/"
     xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Astra Genesis, Devlog</title>
    <link>https://www.playastragenesis.com/en/devlog</link>
    <atom:link href="https://www.playastragenesis.com/en/feed.xml" rel="self" type="application/rss+xml" />
    <description>The Astra Genesis development journal: what I am building, what I am breaking, and why.</description>
    <language>en</language>
    <lastBuildDate>Thu, 27 Aug 2026 09:00:00 GMT</lastBuildDate>
    <generator>Astra Genesis, site vitrine</generator>
    <image>
      <url>https://www.playastragenesis.com/assets/logo/icon-512.png</url>
      <title>Astra Genesis</title>
      <link>https://www.playastragenesis.com</link>
    </image>
    <item>
      <title>A month rebuilding the Research screen, and what it taught me</title>
      <link>https://www.playastragenesis.com/en/devlog/rebuilding-research-screen</link>
      <guid isPermaLink="true">https://www.playastragenesis.com/en/devlog/rebuilding-research-screen</guid>
      <pubDate>Thu, 27 Aug 2026 09:00:00 GMT</pubDate>
      <description>Sixty-four technologies fitted into a perfectly correct and perfectly unreadable grid. It took a month to work out that the grid was not the problem.</description>
      <content:encoded><![CDATA[<p>The Research screen had existed for eight months. It worked. All sixty-four
technologies were displayed, the prerequisites were right, the queue ran. And
nobody, myself included, could decide what to research.</p>
<h2 id="the-first-diagnosis-which-was-wrong">The first diagnosis, which was wrong</h2>
<p>My first thought was: it is too dense. Eight branches, eight technologies each,
that is a wall. So I tried to declutter. I shrank the cards, added whitespace,
moved the descriptions into a tooltip.</p>
<p>It changed nothing. It was prettier and still impossible to decide from.</p>
<h2 id="the-real-problem">The real problem</h2>
<p>What was missing was not space, it was <strong>consequence</strong>. A card said &quot;Advanced
photovoltaics, cost 400 Data, 12 minutes&quot;. Nowhere did it say what that would do
to my colony, right now, with my colony.</p>
<p>The difference between the two phrasings:</p>
<blockquote>
<p>Advanced photovoltaics, +6% solar panel yield</p>
</blockquote>
<blockquote>
<p>Advanced photovoltaics, <strong>+18 power</strong> across your four solar fields, which is
enough to run the Plate Press you are missing</p>
</blockquote>
<p>The second one requires the engine to know the actual state of the save at the
moment of display. That is more work: every technology effect has to be a
function evaluable against the current state, not a line of hand-written text. I
had to rewrite the effects table for it.</p>
<h2 id="what-the-rebuild-produced">What the rebuild produced</h2>
<ul>
<li><strong>A sticky queue panel</strong> on the left, always visible, answering &quot;what is
running right now&quot; without scrolling.</li>
<li><strong>Eight genuinely colour-coded branches</strong>, with the colour reused everywhere
else in the game. Colour is not decoration here, it is identity.</li>
<li><strong>A vertical tree</strong> rather than a horizontal one, because a screen is taller
than it is wide once the HUD is accounted for.</li>
<li><strong>The tier X doctrine behind a double confirmation</strong>, because three people
picked it by accident during testing. A permanent choice deserves to be asked
twice.</li>
</ul>
<h2 id="what-i-take-from-it">What I take from it</h2>
<p>When a screen is unreadable, the temptation is to simplify it. Nine times out of
ten in this project, the real problem was not the amount of information: the
piece that lets you decide was missing. Removing is not enough. Often you have to
add the right thing, and that costs more.</p>
<p>The screen today shows <em>more</em> text than before. It is far simpler to use.</p>
]]></content:encoded>
      <dc:creator>Gaetan</dc:creator>
      <category>Design</category>
      <category>Development</category>
    </item>
    <item>
      <title>Why production never stops when you close the game</title>
      <link>https://www.playastragenesis.com/en/devlog/offline-production</link>
      <guid isPermaLink="true">https://www.playastragenesis.com/en/devlog/offline-production</guid>
      <pubDate>Wed, 12 Aug 2026 09:00:00 GMT</pubDate>
      <description>A management game that punishes absence is not difficult, it is just demanding about your schedule. Here is how Astra Genesis works out what happened while you were away.</description>
      <content:encoded><![CDATA[<p>There is one rule I set myself on day one of this project, and it has outlived
everything else: <strong>closing the game must never cost you anything.</strong></p>
<p>It sounds minor. It is not. It is the constraint that shaped the engine more than
any other, long before the art or the balance.</p>
<h2 id="the-problem-with-most-management-games">The problem with most management games</h2>
<p>In a classic online management game the loop is simple: you start a production
run, it takes eight hours, and you have to come back to collect it. Come back too
late and the warehouse is full and the rest is lost. If a player passes by during
the night, your resources leave with them.</p>
<p>That is not difficulty. It is a tax on your availability. A player who can log in
six times a day beats a player who plays better but has a job. And above all:
none of it is <em>interesting</em>. Nobody has ever told a friend about the thrilling
decision they made at three in the morning to save a fleet.</p>
<h2 id="what-astra-genesis-does-instead">What Astra Genesis does instead</h2>
<p>The engine does not simulate time continuously. It stores a timestamp, and when
you come back it works out what should have happened in between. That is what the
catch-up function does:</p>
<pre><code class="language-js">// The server replays the hours you were away, boundary by boundary:
// each construction finishing, each research completing and each
// expedition returning is handled in order, with the production
// rates as they stood at that exact moment.
catchUp(state, elapsedSeconds);
</code></pre>
<p>The detail that matters is in that last sentence. A naive catch-up multiplies the
current rate by the elapsed time, which is wrong the moment an event changes the
rates halfway through. If your factory finishes two hours after you log off, the
following six hours have to use the new throughput, not the old one. So the
catch-up cuts the absence at event boundaries and recalculates rates at each one.</p>
<p>It takes longer to write. It is also the only honest version.</p>
<h2 id="what-else-does-not-happen">What else does not happen</h2>
<ul>
<li><strong>Warehouses do not overflow</strong> in the punishing sense. A saturated chain stops
and waits; it destroys nothing.</li>
<li><strong>No event fires while you are away</strong> to take something from you. Incursions
arrive with a warning you can see before you close the game.</li>
<li><strong>There is no button to speed things up</strong> for real money, because there is
nothing to speed up: time passes the same whether you are there or not.</li>
</ul>
<h2 id="what-this-choice-actually-costs">What this choice actually costs</h2>
<p>To be honest about it: this rule makes balancing harder. With no time pressure,
the only tension left is the trade-offs. Every tier has to pose a real factory
question, or nothing is left at all. It is a game where I cannot hide behind a
countdown and pretend something is happening.</p>
<p>Good. That was the idea.</p>
]]></content:encoded>
      <dc:creator>Gaetan</dc:creator>
      <category>Development</category>
      <category>Design</category>
    </item>
  </channel>
</rss>
