Attribute</th>	Effect</th></tr></thead>
Cost</td>	Makes your ship more expensive (but shiny and pretty as well)</td></tr>
Space</td>	Most modules take up some precious space on a ship, but some can extend it</td></tr>
Range Bonus</td>	Increases/Decreases the range a ship can distance itself to the nearest colony</td></tr>
Interstellar Speed Bonus</td>	Increases/Decreases speed for long range travel</td></tr>
Interstellar Stealth Bonus</td>	Makes ships more/less detectable while in flight</td></tr>
Hit point Bonus</td>	Increases/Decreases the hull of a ship to take more of a punch</td></tr>
Shield Bonus</td>	Similar to hit points, but weak against energy weapons - strong against physical weapons</td></tr>
Combat Speed Bonus</td>	Increases/Decreases speed for combat</td></tr>
Combat Repair</td>	Repairs ships by a small amount each combat turn</td></tr>
Particle Damage</td>	Adds particle beams with some strength as combat and point defense weapons</td></tr>
Projectile Damage</td>	Adds projectile weapons with some strength as combat weapon</td></tr>
Missile Damage</td>	Adds missiles with some strength as combat weapons</td></tr>
Combat Stealth</td>	Makes ships harder to hit or easier to hit in combat</td></tr>
Colonists</td>	This allows a ship to colonize an empty planet</td></tr> </tbody></table> A ship, by itself is just a hull. The collection of modules selected will determine its purpose. But, there's no free lunch. All modules will be balanced, one way or another.</p> For example, a missile launcher weapon will most likely take up a lot of space and will not be cheap. A particle beam weapon on the other hand could be smaller and cheaper. But at the cost of reduced combat stealth, and a weakness in damaging the hull of enemy ships.</p> Once again this reminds of RPG attributes on items: </p> That is intentional.</p> I really want to enforce that ships are good at some things and bad at others. Otherwise you will end up with the typical "high tech jack of all trades" ships. Also, the number of designs should be limited, as with ROTP</a>. I would like the player to see each design as a "character". Although with some serious multiple personality disorder.</p> So modifying a design should be possible. What happens with the existing ships? They could keep their original design. But then, the game could just have unlimited designs. They could be scrapped. They could be retrofitted. Or something in-between.</p> No code was harmed</del> written for this post. As mentioned before, I already have a small code base. But exploring (no pun intended) the design space is more of an issue for now. So next time we take a look at Expanding</em>.</p> MOO resp. ROTPR inspired 4X game Unknown — Sat, 30 Jul 2022 00:00:00 +0000 So Sonko</a> started a new project. Following suit, I jumped back in time to already have a game project on-going for quite some time now. A bad habit of mine is to reach some milestone and then "pause" (drop) the project. But now I'll return to it, and as a small incentive to keep on it, I'll start this blog.</p> As with Sonko, this means my StarCraft AI related projects are on hold (don't worry, the basil ladder</a> will keep running).</p> Also, on a rather technical note: I dropped Jekyll as a static site generator and moved to zola</a>. Every Jekyll upgrade wasted a lot of time to get it running again. Zola is just one binary, and it should run fine on github actions as well.</p> 🔗</a>Introduction</h1> I played Master of Orion 2</a> (MOO for now) a lot when I was younger. Even back then I tried to create my own clone of the game. But the scale of the game was a bit to much for me back then - maybe even today.</p> But not all thing were good. It irked me a bit how much the game slowed down in the later phases due to the massive amount of micro-management.</p> Fast forward some 30 years and some more MOO games. I always was a fan of easy to learn hard to master games. Almost none of the games inspired by it (or being successor to) seem to do that. They just upped the complexity.</p> Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.</p> </blockquote> Antoine de Saint-Exupéry, Airman's Odyssey</li> </ul> Remnants of the Precursors (ROTPR for now) has a simple interface. Maybe even a bit to bland. But it gets the job done. I did not really play the original Master of Orion</a>, I was still ~~wasting</del> enjoying my time with~~ Civilization</a>.</p> I do like the simpler colony management, which avoids going through every colony in the mid-late game. Spying is a bit strange, it is not really obvious what multiple networks and/or high spendings are doing.</p> Master of Orion 2 (not 1) is a bit different, more complex in some aspects (colony management) and less so in others (less diplomacy/spying).</p> The UI is a bit dated, and looks only good when shrunk down. Still looks nice though.</p> 🔗</a>Designing My Game</h1> My game already has quite a lot of code, but barely anything to show. I decided to create the game abstraction in code as a first step. This was a mistake in my opinion. While its clear that the inner game model should be sound, only testing it via unit tests is rather dull.</p> It currently covers the basics of building ships and colonizing other systems. Like any software architecture, it is best to delay the choices which "cost" the most - as long as possible. This might sound unintuitive, but help not wasting a huge amount of time due to some bad "large" initial decisions.</p> Although I got some basics covered, I want to explore design space a bit further before continuing/refactoring.</p> I know a few things I want</em> in the game design:</p> Colonization should be per star system (like ROTPR). Colonizing individual planets really takes its toll on usability. Multiple different factions owning each a planet in a system? A separate UI for planets in a system? It just makes things more tedious.</li> Research based on a RPG like skill tree. Even ROTPR, which tries to make research meaningful succumbs to the "unimportant research item" problem.</li> </ul> </p> Tech items above are just examples (for some I don't have an idea on what they do), I do want to make it unconventional - yet useful. Every tech has 3 upgrades which will improve on the previous state in one way or the other.</p> Ideas for unconventional techs:</p> Fanatics - For every upgrade, establish a colony on any unoccupied star system</li> Boost - Increase productivity of a single colony for a short while</li> </ul> Ideas for more conventional techs:</p> XYZ Armor - Unlocks a type of armor, further upgrades improve efficiency</li> XYZ Weapons - Unlocks a type of weapon, further upgrades improve efficiency</li> Productive - Increases productivity per upgrade level</li> </ul> Now the real change comes with the way you unlock techs. Usually, you designate a research topic and after some turns you'll get it. This is not the case here.</p> Instead, you build up research points - and once you have enough you can immediately unlock or upgrade a tech. This allows for fast reaction to new circumstances. There are also only a very limited amount of techs to unlock. With either, MOO2 or ROTPR I always feel like the actual decision of what to research matters little. Yes, some do - but you can always replace them later with something else. I want the player to be able to focus on a certain play style, stick to it, but still be able to win.</p> That's all for today!</p> Next Time: Gameplay Loop</p> A son was born Unknown — Sat, 16 May 2020 00:00:00 +0000 This was meant to be a tech related blog, mostly for Broodwar AI related stuff and private projects. Since private projects are included, I guess one could call my son a private project.</p> Screaming into the light, he was born in late February. His name is Benjamin, which I am certain means horse-dung in some weird language. I do not care, go away! And due to Corona, we have been left alone for most of the time since then.</p> My last blog entry was in January, and up until now I really did not have the energy to write a new article. But since most of my free time is now reserved for serving the little demon, I'll just write about what I know best now: My spawn. Prepare for many picture which may or may not include my son (hint: nope, no pix from him - maybe in a later post).</p> As with all babies, he is cute (actually I believe mostly parents find most babies cute, for my part they look like french baguettes mostly...). If you remember Tamagochi, it is really its human form.</p> Lucky for me, we have a spare room - otherwise working would be very hard due to missing shut-eye. Which means shift 1 is work, shift 2 is work, shift 3 is sleep. And things like this</em> mostly eat into shift 3.</p> A little human goes through a lot of development phases. There is the cute phase...</p> </p> Then there is the crying phase...</p> </p> And there is the default happy phase</p> </p> OK, the last one might be slightly exaggerated. And it is not the default. At least for my son, most of the time he is pretty happy.</p> You are supposed to react to the baby's needs. Ignore that at your own peril (eardrums). Really, a lot of time I look at my son and this is what I see:</p> </p> I believe the general baby package works like this:</p> You receive it</li> It comes un-boxed, without manual - W.T.H.?</li> It must already be defect, or is it supposed to behave this way</li> Your midwife (its common to have one here) tells you a lot of good info, and a lot of mumbo-jumbo.</li> She tells you what homeopathy "stuff" (I refuse to say medicine here) you can give you baby - that is ok, since placebo also works for babies. (Btw did you know, there is also a nocebo</a> effect? Cool!)</li> She tells you to see an osteopath (that is so much dumbfuckery). Uuuuhhhh magic energy waves uuuuhh</li> You start to get a grip on it... or do you?</li> </ul> Thing is, the first few weeks you could care less. Your baby can see like 30cm (about 12in you strange people who stopped in time). It can't really focus or look at you. After that it actually can focus you, which is good - it can now target practice with its sound-wave gun while looking at you</em>.</p> Then it starts to smile at you. First for short periods of time, then more. It might also randomly switch from crying, screaming, and laughing.</p> We're currently within the Stan phase. What that is?</p> </p> And with that, I will conclude today's rant</em>.</p> Comments for static pages? - Part 2 Unknown — Sat, 25 Jan 2020 00:00:00 +0000 Looking back</a>... I need a bit of DIY GitHub API for Rust.</p> 🔗</a>Still step 2: Create a branch and PR automatically</h2> Thankfully, the V3 API</a> is really simple.</p> Using our tRusty language, we can define some structs to be serialized to JSON for requests:</p> #</span>[</span>derive</span>(</span>Serialize</span>)</span>]</span></span> struct</span> CreateRef</span> {</span></span> r#ref</span>:</span> String</span>,</span> //</span> The name to be used</span></span> sha</span>:</span> String</span>,</span> //</span> The commit SHA to point to</span></span> }</span></span> </span> #</span>[</span>derive</span>(</span>Serialize</span>)</span>]</span></span> struct</span> CreateFile</span> {</span></span> message</span>:</span> String</span>,</span></span> content</span>:</span> String</span>,</span></span> branch</span>:</span> String</span>,</span></span> committer</span>:</span> UserRef</span>,</span></span> }</span></span> </span> #</span>[</span>derive</span>(</span>Serialize</span>)</span>]</span></span> struct</span> UserRef</span> {</span></span> name</span>:</span> String</span>,</span></span> email</span>:</span> String</span>,</span></span> }</span></span> </span> #</span>[</span>derive</span>(</span>Serialize</span>)</span>]</span></span> struct</span> CreatePR</span> {</span></span> title</span>:</span> String</span>,</span></span> head</span>:</span> String</span>,</span> //</span> The branch to be merged</span></span> base</span>:</span> String</span>,</span> //</span> The target branch for the merge (ie. master)</span></span> }</span></span></code></pre> The basic steps we want to do are described by these:</p> Create a branch, using `CreateRef</code>. Git uses refs for things that "have" commits. A branch is just that!</li>` `Create a file on the branch with CreateFile</code>. UserRef</code> will be used as committer (me in this case).</li>` `The last step is to create a PR with CreatePR</code> (quelle surprise), to merge the branch back.</li> </ul> The file we want to create has to be converted to base64 to be used by CreateFile</code>. The content itself should be YAML and contain this:</p>`#</span>[</span>derive</span>(</span>Serialize</span>)</span>]</span></span> struct</span> Comment</span> {</span></span> id</span>:</span> String</span>,</span></span> r#ref</span>:</span> String</span>,</span></span> message</span>:</span> String</span>,</span></span> name</span>:</span> String</span>,</span></span> url</span>:</span> String</span>,</span></span> date</span>:</span> u64</span>,</span></span> }</span></span></code></pre> Luckily serde</a> comes to our rescue once again and happily creates a serializer to yaml here. Another helpful small library provides base64 encoding. The result is this:</p> let</span> file</span> =</span> CreateFile</span> {</span></span> message</span>:</span> "</span>Comment</span>"</span>.</span>to_string</span>(</span>)</span>,</span></span> content</span>:</span> encode</span>(</span>&</span>serde_yaml</span>::</span>to_string</span>(</span>&</span>comment</span>)</span>.</span>unwrap</span>(</span>)</span>)</span>,</span></span> branch</span>:</span> branch_name</span>.</span>to_string</span>(</span>)</span>,</span></span> committer</span>:</span> UserRef</span> {</span></span> name</span>:</span> owner</span>.</span>to_string</span>(</span>)</span>,</span></span> email</span>:</span> owner_email</span>.</span>to_string</span>(</span>)</span>,</span></span> }</span>,</span></span> }</span>;</span></span></code></pre> The requests itself look quite similar. As an example, here's the CreateFile</code> one:</p> fn</span> create_file</span>(</span></span> client</span>:</span> &</span>reqwest</span>::</span>blocking</span>::</span>Client</span>,</span></span> owner</span>:</span> &</span>str</span>,</span></span> repo</span>:</span> &</span>str</span>,</span></span> path</span>:</span> &</span>str</span>,</span></span> create_file</span>:</span> &</span>CreateFile</span>,</span></span> )</span> -></span> reqwest</span>::</span>Result</span><</span>reqwest</span>::</span>blocking</span>::</span>Response</span>></span> {</span></span> let</span> url</span> =</span> url</span>::</span>Url</span>::</span>parse</span>(</span></span> format!</span>(</span></span> "</span>https://api.github.com/repos/</span>{</span>}</span>/</span>{</span>}</span>/contents/</span>{</span>}</span>"</span>,</span></span> owner</span>,</span> repo</span>,</span> path</span></span> )</span></span> .</span>as_str</span>(</span>)</span>,</span></span> )</span></span> .</span>unwrap</span>(</span>)</span>;</span></span> client</span>.</span>put</span>(</span>url</span>)</span>.</span>json</span>(</span>create_file</span>)</span>.</span>send</span>(</span>)</span></span> }</span></span></code></pre> No, reqwest</code> is not a typo! It's actually a popular library</a> (I don't mean the javascript one). I don't really need non-blocking I/O here, so the blocking</code> client is put to good use.</p> The whole Rust project can be found in my GitHub repo</a>.</p> I tried to solve this "problem" with some constraints:</p> It should be inexpensive</li> It should respect the privacy of my readers</li> It should be simple enough to fix or port</li> It should not depend too much on third parties</li> </ul> Using GitHub for the blog and for comments is very inexpensive. I use no third party commentary service, as such the privacy is protected as much as is possible here. The HTML part is very simple and only depends on Jekyll</a>. The Rust part is also simple and fits in less than 300 lines of code of Rust.</p> Success ✓</p> If you have any comments, please leave them down below - since you are actually able to do so now!</p> Comments for static pages? - Part 1 Unknown — Tue, 21 Jan 2020 00:00:00 +0000 This</a> is actually a static page hosted by GitHub</a>, powered by Jekyll</a>. But how to get a comment section?</p> 🔗</a>Give Me Comments</h1> Weeeelll.... You could use a service like Disqus.</p> Or, you use the idea from damieng</a>.</p> Jekyll has a neat feature: you can place data files under _data</code> and access in Liquid templates.</p> And that's more or less the starting point. Add comments as data and render them via Jekyll (utilizing Liquid).</p> Using the folder _data/comments/{slug}/</code> to place comment files in. (slug</code> being the "slugified" post name.) The actual files can be in a few formats, but I used yaml. Here is an example comment:</p> ---</span></span> i</span>d</span>:</span> 1579711318_617889634</span></span> r</span>ef</span>:</span> b</span>asil-timeouts</span></span> m</span>essage</span>:</span> T</span>esting comments</span></span> n</span>ame</span>:</span> B</span>ytekeeper</span></span> u</span>rl</span>:</span> "</span>"</span></span> d</span>ate</span>:</span> 1579711318</span></span></code></pre> id</code> is the id of the comment and</em> the base name of the file: 1579711318_617889634.yml</code>. ref</code> is a reference for what the comment was for. Ie. a slug or the id of another comment (not yet working here). message</code> is too complicated to explain... really. So is name</code>. url</code> is the website a user gave and will be used to render the commenter's name as a link to the site. date</code> a simple timestamp and, as you might have noticed, part of the id</code>.</p> But having the comments stored as data will not be enough, unless I can convince people to check out the GitHub repo for comments.</p> 🔗</a>Render Me Comments</h1> This one will be quick. I use a modified version of damieng's _includes</a>. Since I modified the structure a bit I had to adapt it. I also changed the layout bit, the final version can be seen down here (unless it does not work in which case: bummer).</p> For now they look ok but will certainly need more fine-tuning, especially once it's possible to reply to individual comments as well.</p> Storage place for comments ✓</p> Rendering comments ✓</p> Adding comments: ❌</p> 🔗</a>Add Me Commentse</h1> This could be as simple as people wanting to comment grabbing a fork of my repository and adding a comment file in data and creating a PR for it. I'm pretty sure this avoids all comment spamming bots and requires almost no moderation.</p> You don't want to fork? Ok, I'll give you commit r... waaait.</p> So basically, using damieng's idea:</p> I want a PR for each comment</li> I want branch and PR to be automatically created</li> Once I merge it, GitHub will automatically update and voilà</li> </ul> 🔗</a>Step 1: Create a service that accepts comments</h2> This could be any form of (micro) web service. Damieng used Azure Functions. But Amazon Lambda or Google Functions would be fine too. But I'm oldschool... I already have a VPS, so I use CGI</a>!</p> I'm also a experienced Java developer, so I used Kotlin</a>. J/K of course I used Rust</a>.</p> I learn Rust as I go (I already tried that once but the burrow checker tried to murder me in my sleep), so take everything here with a grain of salt.</p> So, let's start with some Rust code. There is this really nice library called serde</a> which has a ton of serializers and deserializers for various formats. Like urlencoded</code> which is what a simple form post will send.</p> Now let's write the code to process a POST</code>ed comment:</p> #</span>[</span>derive</span>(</span>Deserialize</span>)</span>]</span></span> struct</span> Post</span> {</span></span> r#ref</span>:</span> String</span>,</span></span> message</span>:</span> String</span>,</span></span> name</span>:</span> String</span>,</span></span> url</span>:</span> String</span>,</span></span> redirect</span>:</span> String</span>,</span></span> }</span></span></code></pre> For those who have never seen C, a struct</code> is like a class</code>: A container for fields.</p> That's it! The derive</code> attribute with the Deserialize</code> argument will create the code to dump in a urlendcoded</code> string and get out an instance of Post</code>:</p> let</span> post</span>:</span> Post</span> =</span> serde_urlencoded</span>::</span>from_bytes</span>(</span>body</span>.</span>as_slice</span>(</span>)</span>)</span>.</span>unwrap</span>(</span>)</span>;</span></span></code></pre> I omitted the boilerplate code to read the data from stdin</code> - which is how you get data with CGI</code>. The full code can be seen in my GitHub repo</a>.</p> 🔗</a>Step 2: Create a branch and PR automatically</h2> Creating a branch and pushing it should be fairly simply with GIT</code>'s CLI. But for the PR, the GitHub API will have to be used.</p> It can also be used to create a branch and (!) even create a file in there. So I just have to use a GitHub API Rust implementation to solve this. Actually, there are a few - but they are mostly unmaintained. They also don't allow the shenanigans I need.</p> To be continued</em></p> Slow bots on Basil Unknown — Mon, 13 Jan 2020 00:00:00 +0000 If you haven't yet, check out BASIL</a>. It's a 24/7 Starcraft league, but for bots! It usually runs fine nowadays. But sometimes an external hiccup occurs. One of those is the problem of detecting who to blame if a game times out. It works fine if the game ends with the in-game timeout of 60min, since the Tournament Module</a> BASIL uses will make both bots leave and select the winner based on the score (That might be unfair, but that's a topic for another post).</p> But if a game gets killed because it took to long (wall-clock time), what then? There are no scores, no replays - nothing essentially. Besides a bot just hanging, most bots just take their time. So I wanted to penalize the slower bot in that case. This looked like a good idea back in the beginning. For dll</code> bots this works fine, but for client</code> bots, it didn't work up until BWAPI 4.4</a>.</p> As of today that means that games timing out in that fashion will not be counted. One could abuse this by timing out intentionally for imminent losses. I don't expect this to happen, the bot community is generally competitive, but also friendly and fair. (Totally unrelated: I can actually disable bots permanently)</p>

bytekeeper.org

BASIL broke

Unknown — Sat, 28 Feb 2026 00:00:00 +0000

So, in the almost 8 years (insane!) it was running, BASIL had few hiccups. Recently it failed hard and was down for a few days. First: It's back up again, but the rabbit whole was deep.

🔗</a>The Game Server</h1>
The first few years the machine running the games had issues with the network drivers (Linux). It first started loosing the connection then either hang or Kernel-panicking. A workaround was to restart it regularly. Mind you: this strategy is used by professional business software as well --- I'm in good company.
After a few years the issue suddenly was fixed. I can only assume some Kernel dev had the same issue an was motivated enough to fix it --- THANK YOU for that.
🔗</a>Basic Setup of BASIL</h2>
The "game" machine was kind of running fine after that point --- without any scheduled restarts. The file serving machine started to get problems soon after. It's a VPS and has limited disk space. And it started to fill up. It serves replays, game logs and all sorts of aggregated JSON data. Everything is pretty small, but multiplied by a few thousand it gets large very quickly.
Using two machines has several benefits:

A VPS running games would be very expensive (good CPU, a lot of memory)</li>
Hosting a web-server at home, even with Cloudflare "buffer" might get hammered</li>
Using one machine for both:

Could be abused to influence the games being played</li>
My internet being down would mean: no more public data</li> </ul> </li> </ul>
🔗</a>Woes of Producing a lot of Data</h2>
The fix here was simple. Archive all old files and sync only recent ones. That way the VPS should never be filled beyond capacity. This worked fine for a few years. I will eventually have to manually move the archives to another place as disk slowly fills up.
Now let's head back to more recent days. On Feb. 19th - Dan destroyed BASIL with his custom CherryPi build. Okay, maybe it just made me check the machine and restart after installing security fixes. After that I did the usual check: Did the service start, are games being played. BUT: I did not check if games were actually running successfully.
Unfortunately, they did not. I tried some quick fixes but to no avail.
🔗</a>Down the Rabbit Hole</h1>
So the journey began:
I suspected a security update broke something. I found it had upgraded from Ubuntu 24.4.3 to 24.4.4. There was nothing extremely suspicious about that. So I started a headful game. I suspected a crash. But it ran. The other bot just did not join. Observing that one I saw why: No hosted games were listed.
🔗</a>Why You Not Join Game</h2>
Why though? Either the host did not "send" its game or the client did not receive it. So I fired up tcpdump</code> inside the docker network used by sc-docker</code>. I did not remember the UDP port so a quick internet search revealed 6112. Nothing showed up when I tried to start a game. So I (falsely) assumed that nothing was being sent. I tried WINEDEBUG</code> - figuring out the potential params with some ChatGPT help. It did not help much. So I decided to add strace</code> to the sc-docker image and ran wine with strace (only the network related calls). It did call sendto()</code> --- which is the Linux syscall for sending on a socket.
`So it was sending. But why was it not receiving anything. I decided to tcpdump</code> on the network bridge of docker. Thankfully, without port range. Because DAMN YOU internet, it announced games on port 6111 and not 6112.`
🔗</a>UDP Broadcasting</h2> So I ran tcpdump</code> inside a docker container, and lo and behold... wait, again - nothing! So I tried to manually broadcast UDP packets on 6111. And they got received. What the actual ... But there was a difference compared to my broadcast. It did use the subnet's broadcast address. Starcraft uses 255.255.255.255. This in itself should not be a problem, and it worked before. At this point I tried all kinds of shenanigans, checking netfilter, and iptables. All looked fine. At some point I decided to want to see "more" data about UDP packets being sent by Starcraft. With some more help ChatGPT figuring out the obscure and cryptic arguments of tcpdump, I finally got more info. In case you want to try: tcpdump -i br-<yourbride> -nnve udp port 6111</code>. 🔗</a>It's Not Only the IP</h2> While packets were sent to 255.255.255.255, they were not sent to the MAC address FF:FF:..:FF. But to a concrete one. Whereas my manually sent packets were sent to that MAC address. So some new code started to decide to route differently. I suspect a kernel "fix". Figuring out the 255...255 address it might have decided that lo</code> was a good choice - but I don't know. I did not check. Whatever the cause is, packets were not broadcast - because it's not a broadcast address. 🔗</a>Fixing the Problem</h2> Because, in that case the fix might have meant to remove lo</code> --- nah. Another option would have been to patch Starcraft. Kind of overkill. A "good" solution might be to write a tool that captures those packets and re-broadcasts them properly. So, nobody would actually try an ugly hack like rewriting UDP packets via netfilter. Or would they? Hint: Yes. My netfilter foo is pretty bad, so ChatGPT helped once again - the basic idea being pretty simple: Create a priority prerouting rule that captures packets targeting 6111 and set the target MAC address to ff:...:ff. Like this: table inet filter { chain input { type filter hook input priority filter; } chain forward { type filter hook forward priority filter; } chain output { type filter hook output priority filter; } } table bridge starcraft_fix { chain prerouting { type filter hook prerouting priority -200; udp dport 6111 ether daddr set ff:ff:ff:ff:ff:ff } }</code></pre>🔗</a>Conclusion</h2> Making a 28-year-old game run reliably on a OS (Linux) that is wasn't meant to run on, in a setting (headless) it was not meant to run on, with hooks (BWAPI) it was not supposed to have --- is a challenge. Most bot authors use Windows or macOS - so neither this problem nor the solution might apply. But if you sc-docker games suddenly stop working it "might" be this issue. If you're not on Linux - the fix might be different, but maybe I saved you a few hours finding the problem. (PS: I used enough em dashes to trigger an LLM "alarm". I let ChatGPT proof-read but all the text is mine.)

Why You Don't Finish Unknown — Mon, 08 Sep 2025 00:00:00 +0000 Do you start projects only to abandon them soon after? You might be fleeing. Don't get me wrong, trying and failing is absolutely acceptable. How else could you learn, unless you make mistakes. But you have to allow yourself to make them. Sometimes it is difficult to decide, but a project that clearly is going nowhere is fine to abort. Don't push through if it makes no sense. As long as a project will teach you something useful, it is probably worth pursuing. What is useful? That is a decision only you can make. Listen to others, but don't let someone else make that decision for you. 🔗</a>Abandoning a Project</h1> If you are about to abandon a project, you need to reflect on the reasons. Is there some new thing you are more interested in? If you follow that path, the next shiny idea will make you abandon that one next. An endless spiral of broken projects. You will never see their potential. Unless you finish something, everything will be a guaranteed failure. 🔗</a>Flight</h2> What if your novel idea is just coping, or you have no new idea, but are just bored? The real reason might be fear. Whatever you create: Will it be good enough?</li> What will people think of it?</li> Will I disappoint myself?</li> Will anyone use it?</li> Are you wasting your time?</li> </ul> That is the trap of vanity. A harmful trait that will prevent you from developing further. You cannot make progress without stumbling along the way. Regarding the topic of no one using your result: A few is enough for me; so is one; and so is none --- Seneca </blockquote> If it is a waste of time, why did you start it in the first place? There must have been a reason. Learning something at the very least. Producing something of value as a bonus. But avoiding adversity by chasing new projects will never show you what you are capable of, or what you are not yet capable of. Maybe, that was why you diverted yourself in the first place, wasn't it? 🔗</a>Volatility</h2> Let's assume you really found something new and so it's not fear that drives you. If you jump ship, you only proved that you get distracted by the tiniest of things. Instead, write the idea down. Let it simmer for three days. If it is still hot, you may try it out. If not, pursue it at a later point --- after finishing your current project. 🔗</a>Learning to Learn</h2> Abandoning a project will waste a great opportunity: Learning what doesn't work --- and why. Not finishing means you don't have to think about failure. If you endure, not only will you hone your skills. You can analyze your flaws reflecting on a finished project. It could be a success, but you will never know. 🔗</a>Summary</h1> You are not finishing projects because you fear that it is not perfect. You fear that others' opinions --- and your own --- will cast it as a failure. So if you want to start finishing projects: Accept that you lack the skills, but are willing to learn them.</li> When being distracted by a new shiny idea, write it down --- but tell yourself: "I understand that this diversion is an exit provided by my mind to protect my ego". Don't even consider it until some time has passed.</li> Think of what your project could be. If you don't do it, nobody will. Does it really deserve to be abandoned, or does it deserve a chance to succeed?</li> Think of what you could learn by continuing. All those skills learned will make every further step better.</li> </ul> The only real failure is never to finish. A Rant on Software Development Bloat Unknown — Fri, 05 Sep 2025 00:00:00 +0000 In my opinion, software development has become rather bloated. If that is not the case for you, feel free to skip - or continue and enjoy some schadenfreude. This is just me ranting, don't mind me. Much of this I experienced at some points in my career. Some of it I heard from friends. Some of it from social media. Disclaimer: As with most developers</del> people, I am in a bubble. We got pretty good at pushing out MVPs. A reasonably good-looking UI, some backend scaffolding - that is done in days instead of months. How did we get there? Frameworks! We got so many, the start is basically plug-and-play. In some areas we got so many frameworks, it is overwhelming. JavaScript frameworks anyone? Frameworks are nice. But many frameworks start to create an ecosystem after a while. You get more tools, but also more restrictions. This can be good and bad. On the one hand, working with the framework becomes more productive. On the other hand, learning the framework gets harder - so is integration with other libraries/frameworks. 🔗</a>Dependencies</h1> Adding a new library or framework to your project? Are you thinking about the implications as well? Your co-workers will also use them. You will use them. There should be a cost-benefit analysis for adding dependencies --- every time. We mostly see the benefits while developing. Yes, we don't have to write code. Yes, someone else might have solved it better than you could. And yes, if there's a community --- you don't have to support the code (as much). What it costs us? Google might suddenly drop the project, and you're left with a huge chunk of software --- heavily intertwined with a framework that is no longer maintained.</li> Complexity of your software increases, because you opted for the "common" solution --- instead of the simple one.</li> You add bugs and security holes, which you probably cannot fix quickly --- other than asking someone else to do it, most likely a volunteer in an open-source project.</li> You don't fully understand the framework, so your misuse adds more bugs. Thankfully, you can fix those yourself.</li> Updating a dependency can lead to conflicts if transitive dependencies don't line up.</li> </ul> 🔗</a>Dependencies Part 2</h1> Actually, there's a hidden gem. Tool dependencies are often overlooked. They're quite useful, until they're not. 🔗</a>Your IDE</h2> Dev Containers, pre-configured IDEs, IDE setup guides? All useful. But again, nothing is free. For smaller projects, this part is usually not problematic. But for long-running products and projects... As with all software, IDEs get updated, abandoned, and have bugs. You can enforce specific IDE setups to prevent this, but you will also make enemies among your co-workers on the way. Most of us customize their IDE experience. If you enforce your specific setup, you're just evil. If you enforce the common ground it's fair, but everyone will be unhappy. 🔗</a>Enforced Formatting</h2> Yes, it's nice once your team agrees on formatting. And that can be pretty unpleasant. But is your formatting enforced? Git pre-commit hooks? IDE integration? What happens if the formatter fails? It happens more often than you would expect. Or the IDE plugin differs from the plugin in the build tool, or the CLI tool you use. You use more than one tool? That can happen if one tool only handles a part of what you want. But what happens if both tools have overlapping responsibilities. And they disagree? (Oh yes, they will.). 🔗</a>Build Tool</h2> Depending on the programming language, the number of build tools is ... enormous. They can be configured to death and bring all sorts of joy. Oh, your software is polyglot? Multiple build tools? Sounds like fun. Works fine on your continuous integration (CI), but building it on your machine is a chore? Scripted steps on your CI, manual steps locally --- nice! 🔗</a>Automated Testing</h2> Unit tests take a second each, and there are 8,000 of them? Integration tests (for brevity's sake, I'll only distinguish between unit and integration tests here) are so slow you extracted them into separate build steps. Even your CI won't run them unless you ask it to, if you know how to ask. And if the CI is even on same system and not split across multiple systems. 🔗</a>Continuous Integration</h2> I mentioned it above, but CI is not something that magically appears. It has its own scripts and systems. It can be documented quite well, but often is not. It can be on one platform, but can be spread across platforms. Since your build and tests run in up to four hours there might be a slight problem if multiple developers are doing builds. It crashes, it fails randomly, it costs a ton of money. And you got one person who knows the configuration, two if you are lucky. I mean, at least you have got CI and are not building the latest release on an individual developer's machine. 🔗</a>Verdict</h1> You will manage. If you can influence things, try to keep the environment simple --- not only the code (bloated architectures and design are topics for another time). If it's out of your control, don't get infuriated. You cannot change it, so accept it. Either way, it's always a good time to learn the good and the bad stuff here. Don't get angry at your co-workers; most of them want to do what they think is right. They might be wrong, you might be wrong. Especially on that point, reflect on your opinions. If they seem wrong, change them. If not, help the other person if possible --- otherwise, don't. A few suggestions that might help: Require a short cost‑benefit note for new dependencies.</li> Add automated dependency update tests in CI.</li> Enforce one authoritative formatter.</li> Make builds reproducible locally (container or script).</li> Refactor tests to run fast.</li> Try to make builds as fast as possible locally.</li> Assign and rotate CI/dependency owners.</li> </ul> GameDev Review: Star Renegades Unknown — Tue, 09 Jan 2024 00:00:00 +0000 I promised a review before</a>. I did not start</a> with it, oops. So let me catch up! 🔗</a>What Came Before</h1> I was a bit surprised to find that the game was developed by Massive Damage, Inc.</a>. They are the makers of Halcyon 6</a> - which gained some small hype 2017/2018. I bought the game and found it to be Okish. I played it a few hours and it seemed to lack focus. There were only a few updates, I'm not sure they "fixed" that. It could be a "me" problem. This however, is not a review of Halcyon. 🔗</a>Presentation</h1> The game looks great. At least if you like pixel art. That mixture of 3D and pixel art - its just working great for me. The anime sequences are good enough. They don't seem to fit too well, but it must have been a ton of work, I can appreciate that. In combat, characters don't just aim and shoot, they get a real cool animation - and most of the time its not too long to be annoying in the long run. 🔗</a>Core Game Mechanics</h1> Clearly, combat is the main mechanic of the game. But there are other aspects. 🔗</a>Walking Around</h2> Between battles you run around maps, unlocking regions and finding (some) items. This is a strange beast. While it could add to the overall game by being a freely roamable map, it is extremely linear. Its also not polished, sometimes you need to click around a lot to find a spot the characters will move to. It looks nice, and the concept of finding loot on it is also cool. But that also means little, since you just click on anything that could have loot in the area you're in. For me, this part of the game could very well be left out, resp. replaced with some narrative. Or, improved to be of value - or even be fun. 🔗</a>Socializing</h2> Also between battles you get to socialize with your companions. This is done by "cards" that you can let a character play targeting some other character. This idea is often found in the big RPGs, like Dragon Age: Origins</a>. But its more deeply integrated in those (yes, the sex aspect could be a major point - but it requires non-pixel art graphics I guess). Its carried through the narrative. After you gather you party you play the game with them, learning about theme and getting to like them. Star Renegades tries to be a roguelike-like, your party might differ for each play-through. The narrative is slim, you don't really build a connection with them. The socializing (camp) aspect seem extremely "added" - and while you reap some benefits (if two characters like each other, they can do combos), it feels a bit awkward. 🔗</a>Combat</h2> Now we're getting down to the nitty-gritty core gameplay. The unique feature of combat seems to be the ability to "push" initiative of the enemies. You can even push them to the point they won't be able to take their "turn". As you have ample ability to push, you could win without taking damage. So the devs limited this. Enemies already pushed to the next turn (I know they use another term, but I'll stick with turn here) cannot be pushed further. Maybe this mechanic can be made to work. They seemed to have tried and gave up. "Why?" you ask. Because they loaded up the game with buffs, stats and actions. But most of those things are not relevant at all - or at least appear to be irrelevant. The initiative manipulating mechanic seems to target more tactical players. But the added noise seems to try to cater to the RPG crowd. But since customization of characters is fairly limited, that seems a bit weak as well. Also, there are some quality of live bugs: Enemies are previewed to blow up, yet they don't. Enemies are shown to be pushed into the next turn, only to find they sometimes still get to shoot at you. 🔗</a>Respecting the Player's Time</h2> After a few hours of easy to a bit less easy combat, I encountered a very strong enemy. I lost. But why? I could not figure out a reason. Maybe I was stupid? But all the enemies before were so darn easy. So it felt like a punishment. Or a "hey we're a roguelike-like" message - in case you did not get it. 🔗</a>A Nemesis System</h2> It has one. I'm not sure it works. It works well for Shadow of Mordor</a> - but that is really kind of an open world game. You can choose to engage or to ignore your nemesis. And your enemies would climb ranks. However, in Star Renegades - it's more of a level up system for them. 🔗</a>Summary</h1> Don't get me wrong, I actually enjoyed playing Star Renegades. I might play it a bit more, it just looks fantastic. Its weakness is the gameplay which swings from too easy to too hard with not much in-between. And they suffer from the "one more feature" syndrome. Less would have definitely be more here. What I learned for my game? That I need to reevaluate all "features" later on and drop those that don't make the game better. Next time, we'll be diving into some market analysis! Remnants of the Vanquished Unknown — Tue, 19 Dec 2023 00:00:00 +0000 Now, let me reveal the name of the Unnamed Game</a>. This time, we will focus on some more technical aspects of the game. As a disclaimer: I use Bevy, which more or less enforces the use of an Entity Component System (ECS). ECS is kind of a hype (micro-services anyone?), of course it can be used for everything - but does it fit everything? Still, I am not yet turning my back on Bevy just yet, so I'll have to make do. 🔗</a>Short Recap</h2> Last time</a> I was babbling about model and visual components. I laid out some rules I "found" for turn based games using ECS: Only core game logic systems may modify game logic components.</li> Only core game logic systems may remove game logic entities. They should send events in that case.</li> Non core game logic systems may add and modify their components to game logic entities. They must also ensure to clean up after themselves by removing components when systems go out of scope.</li> Non core game logic systems must handle entities suddenly disappearing and appearing.</li> </ul> Alas, while I still think those are valid - a more restrictive approach might be necessary. Let's take a step back and re-evaluate the current design approach. 🔗</a>Different Representation of What the Player Sees and What the Game "Thinks"</h1> I mentioned before</a>, that its harder for turn-based game to work with entities. ECS' are designed to run continuously, so for "discrete" components (discrete in time) - the result is stuttering. But what does that mean? Let's dive into the problem, by looking at several approaches on how to model game entities. For the sake of understandability, we'll limit ourselves to one discrete event: A ship getting destroyed. 🔗</a>Visual Components and Model Components Share Entity</h2> In this scenario, what the game "thinks" and what the player sees are the same. For the most part. Sounds simple enough. But, it has some repercussions. 🔗</a>Immediate Model Updates: A No-Go</h3> To the left is a representative entity. It contains hit points as a model component and a sprite as a visual component. The entity is in the process of being destroyed. To the right is the game state, separated by UI (visuals) and Model (what the game thinks). The UI is red, because the entity suddenly disappears which is inconsistent with what the player expects to happen (things going boooom). But the model is consistent (in a more computer sciency term - all invariants are held). Conclusion: This is essentially a bad option, the game is for the player - not for the CPU or my peace of mind. 🔗</a>Delayed Model Updates: So-So</h3> A similar representation as before, but this time the entity is not destroyed immediately. Instead, the "planned" destruction is communicated by an event or a flag in some component. The UI has plenty of time to show explosions and whatnot. But, as indicated by the red model state, there's a period where the model's invariants don't hold: a "dead" ship shouldn't be present anymore. They will have to be removed later, by game model systems mind you, if the non-game-logic systems start meddling around things will get messy). This will obviously work, but is a bit "ugly" from a technical point of view. The game logic systems will have to "mark" things other game logic systems will "later" do. In-between the game model is in a meh state. If, for example, the player was to leave the game (saving it in the process), loading it later would start by playing some animation - or not. It depends on whether the UI systems recreate the UI components for the already "marked as dead" ship. Conclusion: This approach works but carry the stench of potential problems when restoring the game state. 🔗</a>Separate Entities: Good, but More Effort</h2> With this design, there are no "reds". There is an entity for the model and an entity for the UI. The UI will try to keep entities in sync. If an entity in the model is destroyed, the UI can keep its entity around and start the destruction animation. The model's invariants are held, and the player won't be confused. But we pay a price, we need to sync the relevant data. However, it offers the choice to diverge more freely from ECS in the model. The core game model does not need to be based on ECS at all. Conclusion: This will work, but will also be more effort to implement. 🔗</a>Summary</h2> As always, there is no single best solution - all have draw-backs. Coming from a business development perspective, it often pays to separate domain models: "Sourcing" is the term for where data is coming from. Basically, that is, what I will be doing. That means "Separate Entities" is the way to go from here. It also means I do not have to use ECS for the core game. Which means I can use a separate package (crate in Rust terms). That means Bevy will "just" be the frontend - which I could replace without touching the game rules at all. 🔗</a>Conclusion</h1> Having designed and implemented multiple smaller games using ECS, there is a challenge in using it for turn-based games. Using a separate World</code> and schedule is something that can be used to make it work. But the gains are small in my opinion. As shown above I faced basic problems with my approach. I want to avoid wasting time later on, trying to synchronize all the data for entities that are a mixed bag of real-time components and turn-based components. Thanks for sticking around, maybe you learned something - I sure did. See you next time... Shogun Showdown Core Mechanics Unknown — Wed, 06 Dec 2023 00:00:00 +0000 As promised</a>, in this post, we will take a look at the game Shogun Showdown</a>. It is still in early access, but has very good review scores and a sizeable amount too. Its Steam page tells it's "inspired by great games like Into the Breach, Darkest Dungeon, Crypt of the Necrodancer, Slay the Spire and so much more". That is similar to the inspirations behind my own game. As my in-development game shares some of these traits, this game certainly is one I need to take a closer look. 🔗</a>A Quick Detour: My Game</h1> I'm on a journey</a> to create and publish a game. The plan is to create a rogue-like with turn based combat, as mentioned just above. To not fumble blindly in game design, I want to check out and review similar games. But, mostly from a mechanics perspective. So let's get back to Shogun Showdown... 🔗</a>What is the Game?</h1> It's a turn-based, rogue-like battler set in a Japanese-inspired setting. It features nice pixel art and a good soundtrack. I have not yet beaten the game, but from my current knowledge it basically has a few scenes: a Shop scene</li> a Combat scene</li> an Upgrade-only scene</li> </ul> And while there are some random elements, the combat is pretty much deterministic. Since players will spent most of their time in that scene, let's dive deeper: 🔗</a>The Combat Scene</h1> Let's start with a look on a typical combat scene: As mentioned, there's not much randomness going on. The player has a set of actions, they can perform. Most will "end the turn" for the player and the enemies get to act. The game, like mine, tries to take elements from Into the Breach</a>. Reduced to 1 dimension, they left out units to protect. Its feasible to add those, so they might show up in a future update. The game also uses different "field" sizes, depending on the scenario. Also, like in my imagined game, there are no decks. You get actions, and that's all you get (mostly). Besides movement, the actions are similar to cards in other games. You can upgrade them, "drawing" is emulated by cool-downs. A very clever idea is the stacking of actions. It allows delaying attacks, unleashing multiple attacks in quick succession, damaging multiple enemies. It's neatly embedded, and required to defeat certain game stages. Another nice mechanic is the movement of the player and enemies. That includes actions that the player and enemies can use to move multiple tiles. It requires careful planning to avoid taking damage when moving to close to an enemy. Enemies behave pretty deterministic and their chosen actions and action executions are at all times visible to the player. As with Into the Breach, this adds a nice puzzle-like feeling to the game: "How can I solve this without taking any or much damage?" Sometimes (at least for me) it backfires a bit. Some enemies can attack from afar. If you focussed on close combat your only option is to try to get another enemy in-between. It feels a bit like "iterative deepening": You make a bit of progress in the game, suddenly an enemy shows up that thwarts your choices. Maybe it's still possible to win, and it's just my skill (or lack thereof). I did not get that feeling in Into the Breach, it always seemed fair. Alas, it was not in early access, so I'll cut Shogun Showdown some slack. 🔗</a>Summarized</h2> Movement and attack ranges give of a nice "chess"-like feeling. Enemies with no line-of-sight generally will just idle. But the "initiative" (i.e. the order in which units are taking turns) of the enemy is hidden. So, when you manage to get enemies to attack each other (which is a really nice mechanic), you don't know which one will attack first. The game is pretty forgiving, for a rogue-like. Health flasks and other consumables help, when a bad choice makes for a dire situation. 🔗</a>Compared to My Game Idea</h2> 🔗</a>Stacks vs Board</h3> The stacks in my prototype are similar to the one dimensional "board" in this game. This choice naturally leads to a reduced set of actions. The player can not attack any random enemy, but will have to select one of a few viable targets. Same for the enemies, many just can't target the player due to other units being in the way. Its more natural than the stacks in my prototype, which allow targeting the top ship only, most of the time. 🔗</a>Damage Management</h3> Another thing is the damage management. Its basically the core of Into the Breach, and also of Shogun Showdown. My prototype does things differently. You can almost never avoid taking damage. Instead, something that fits the lore of a science fiction game, I added shields. Shields get replenished fully at the start of each combat. Since damage cannot be avoided, the goal is to distribute the damage across all player ships to avoid actual hull damage. 🔗</a>Movement</h3> There is no actual movement per se in my game idea. Actions will usually put a ship to the bottom of the stack. Some can actions allow changing the player stack. Some modify the enemy stack. This differs a lot from Into the Breach and Shogun Showdown. In both games the player can actively move unit(s). For Shogun Showdown, this means an actual turn. For Into the Breach, the player still can perform an action. Not diving into this too much for now, it essentially means I might need to re-design movement in my game. 🔗</a>The Other Scenes</h1> There are shopping, upgrade and path selection scenes. The least important seems to be the path selection one. It has not struck me as very important on what benefits selecting different paths might have. I guess one could just remove it and tell a linear tale, for now. Upgrading seems kinda important, but most of the time its "you gain some you lose some". Even upgrades that cost "money" are sometimes not game-changers. I should play a bit more (almost certainly not because its a fun game) to check this further. Shopping... I mean, it allows adding more tiles and has actions and such. But it feels a bit superfluous. I'm also pretty sure the sense of "puzzle combat" will be gone once I have a lot of actions available. Into the Breach managed to get superb gameplay by having about 6-8 actions (besides moving around) in a whole session. 🔗</a>Verdict</h1> Its a fun game. Combat feels nice for the most part and when I am surprised, its mostly through my own lack of planning. There's no observable narrative, the setting is very cool - the game really needs one. The world map serves no other purpose than to click a random next location. Upgrading and shopping seems a bit superfluous. BUT - this is an Early Access game. The actual combat is so much fun, I am pretty sure the devs can improve the other aspects. It could stand right there, next to Into the Breach - with some work. For my journey, it shows some the flaws in my game design I need to address. Its such a wonderful time in which I can validate ideas also by looking at what other people did. Not that this approach did not work many years ago, but the amount of good quality (and bad quality) games is huge. Thanks for reading - next time I will write about my prototype again. Stay tuned. The Yet to be Named Game - Continued Unknown — Sat, 25 Nov 2023 00:00:00 +0000 In the last</a> post, I showed some of the goals I want to achieve with my game. Including some early screen shots. I decided to replace the AI generated ships with some procedural generated ships - lets have a look: While not exactly beautiful, and not even in the style I want the game to be - it's a better placeholder. It should not agitate people as much, as AI generated art would. Other than that, due to me being sick all week - not much changed. I made some small progress on the "star travelling map" (fancy), were a player can choose their path through the game. So instead of game design, this time we'll take a look at a technical aspect. 🔗</a>What Engine am I using</h1> Bevy</a>. Wait... I said wait! I know its in Rust</a> and I understand that is a hype topic. It is my current language of choice, and while Bevy might be far from complete, doing a prototype in it should be fine. That inevitably means one thing: I am using an Entity Component System (ECS</a>). And this is a turn based game. 🔗</a>How to Design Entities and Systems for a Turn Based Game</h1> It might not be obvious, but real-time games are far easier to do with ECS. System could be executed slightly out of order, or not at all for some frames. It's not something that a player will notice, or at least care much. If an enemy dies one frame too late it can always be excused. Visible glitches like projectiles passing through enemies are a lot more noticeable, so you're not free to ignore the effects. In turn based games however, things get dicier. Systems running out of order are immediately apparent. Attacking an enemy which stands around with 0 health until the next turn? No-go. Ordering an attack move and the game first attacks and then moves? Not good. Another problem: Usually all systems run every frame. You cannot design systems that run once per turn. At least, not as easy. While I do have some experience in turn based games and in ECS games, I did not do both at the same time yet. Turns out, the real question to ask is 🔗</a>What is a Turn?</h2> In chess its after you moved your piece. In a game like Slay the Spire</a> its when you hit that end turn button. But how should systems react to that? In real-time games its pretty easy: You assign the player input to some component and some system will use that and manipulate other components. You can do that in a turn-based game too. For example have a Attack</code> component that has the target</code> and the weapon</code> in it. And once the system handling that is done, remove or clear that component. Oh, why do you get that strange feeling of "wrongness"? 🔗</a>How to Handle Input</h2> I cannot tell for you, but I can tell for me: Components are there to capture the state of the application/game. But attacking in a turn based game is not a state change itself. The state of the game should reflect the action, but not necessarily contain the action as part of the state. (Of course there are exceptions to that rule, this is just the general advice of avoiding littering your entities with input components) Events</code> (or Signals) are part of most ECS'. And a good fit for the discrete nature of input in a turn based game. You would not want to use it for real-time games mostly. For example, pulling the trigger to fire non-stop in an action game does not lend itself well for events. The player holding the trigger is part of the state of the game. On the other hand, the player pressing jump</code> should only be part of a component, if they can vary the height of the jump by pressing longer or shorter. If not, an event will most likely suffice. 🔗</a>ECS Systems</h2> Now for my game that means, every system can run continuously (and if I wasn't a pedantic, even ignore the order partially - one frame more or less won't hurt). Most will only do something if they receive an event. This helped also in determining the solution for another problem: When should the AI execute its turn? 🔗</a>The AI's Turn</h3> There's not much of an AI in the game. Still, it has to perform its turn execution at some point. Previously it executed immediately after the player did. That is a problem. For the player, it looks as if the AI did nothing - because all units just "jumped" and were done. So I added a hacky ai_can_move</code> field that was read and modified by multiple systems. That way I could animate the player action, wait a short moment and execute the AI actions. It works, but it was not nice having that flag and the toggling logic. What I really wanted ... and "now its ok for the AI to execute its moves" event. Far simpler than the flag. 🔗</a>Game "Model Components" and "Visual Components"</h2> With that all "solved" for now, I still had to figure out how to represent all the entities. I wanted the game to work without any graphics. So I created a "game model", based on entities. They would just contain the components required to run the turn based systems. Systems that rendered things should use their own entities and keep them in sync with the model entities. And I immediately ignored that and added Sprite components to model entities (in a system outside of the core game systems mind you). This made implementing the prototype faster, but I would have to refactor the code to have a separation later. But I noticed, even for my game - that was not true. At least not completely. As long as I would not touch model components in other parts of my game - I could add and remove any components I liked. Same for the other way around, model systems should not touch other components. With one exception, model systems are allowed to remove entities, and therefore delete components of other systems. Removing an entity should therefore be accompanied by an event, so other systems can react. This does not have to be explicit, Bevy for example sends a RemovedComponent</code> event. But if you need more data, a custom event would be the choice. 🔗</a>How to Handle Mixing Visual and Game Logic Components</h2> This is, of course, dangerous to some degree. If you are careless, this might leave core game components in a desolate state. But it saves time and performs (not really important here) better. So lets summarize the rules to make it work: Only core game logic systems may modify game logic components.</li> Only core game logic systems may remove game logic entities. They should send events in that case.</li> Non core game logic systems may add and modify their components to game logic entities. They must also ensure to clean up after themselves by removing components when systems go out of scope.</li> Non core game logic systems must handle entities suddenly disappearing and appearing.</li> </ul> 🔗</a>Conclusion</h1> This time we have taken a look at how to design entities to work for the core game and one or more scenes. Events are a key element to keep things simpler and loosely coupled. ECS obviously is not the one-size-fits-all solution, but with some thinking the shoe fits quite good. I played some Shogun Showdown</a> (purely for research purposes of course). I did promise to do a review of another game, but that will have to wait. So next time, really: A review of shogun showdown, from a core mechanics point of view. The Yet to be Named Game Unknown — Thu, 16 Nov 2023 00:00:00 +0000 Previously</a> we took a birds eye view on the topic of the game development process. Or, to be more precise, the model in my mind. I plan on refining and correcting it as I go and learn. 🔗</a>Current State of My Game</h2> I can actually show a screenshot of my prototype: It contains a background I made and some ships an AI model created (for the prototype only, I will create or commission the real art). To the left are the player ships, to the right the enemy ships (I did not even bother to make the "look" toward the player ships). 🔗</a>Game of Stacks</h3> What is shown above contains the basic idea of the game: You and the enemy have a stack of ships.</li> Either "player" can only perform actions with the ship on top</li> Actions generally evolve around stack manipulation</li> Actions doing damage will do so only to the top enemy ship for the most part I intend to not change these, if possible.</li> </ul> Things that are not set in stone, but shown above: The action the enemy ship "would" take if it was on top. The reason it shows up for all enemies is that a player action could move an enemy to the top.</li> Health and shield. Not only does it work for a sci-fi setting, it adds a tactical layer - shields will be replenished at the start of combat.</li> </ul> Here are the current actions of the top ship (it is taking the role of a "tank" in classical RPG terms): Lets take a look at the actions (keep in mind this is a very early prototype and things can and will change here): Skip: all ships can do this, reasons for using it: Ship is on cooldown, all relevant actions are on cooldown, or the player wants to avoid cooldown. It will just move the ship to the bottom of the stack, ending the players turn.</li> Relinquish: The ship will move down one spot in the stack, the new top ship will immediately be ready for action. This allows the player to perform an action of another ship. This will mostly move the original ship back up on the top, which will take the response (its the tank after all).</li> Taunt: The enemy ship will take some small damage and the current ship will not be moved away. This allows the player to letting the current ship take a hit that would otherwise target the next player ship.</li> Attack: A light attack, after which the ship will move to the bottom of the stack. This is one of the simpler damage dealing actions, with a predictable stack positioning.</li> </ul> As you might have guessed, predicting the position of enemy and player ships is required to make effective use of the players fleet. In my last post I commented on the inspiration for the game. Funnily enough, its main source is Into the Breach</a> and not Slay the Spire</a>. But it differs a lot: The obvious difference is, its not played on a grid.</li> And the player doesn't get to freely move around ships in the stack.</li> Its also hard to avoid taking damage.</li> </ul> Some of these limit the choice a player has each turn. One thing I try to compensate that is the addition of shields. The amount of health and shields is still very low, I want to make each turn as decisive as possible. It wouldn't work if players and enemies would have at it for hours. 🔗</a>Challenges</h3> Besides using bevy</a>, which might be a questionable decision - creating a turn based game in real-time engine poses some challenges. Since systems run all the time, they need to "not do anything" as long as neither the player, nor the AI makes moves. There's also the problem that AI actions should be delayed - or appear delayed to avoid confusing the player. But the harder challenge was and is making the core mechanics "fun". I am a firm believer of "less is more" - so I am trying to add as little as possible at a time to test if I can improve the prototype. It kind of boils down towards the target audience, which in turn is also determined by the number of choices a player has at each "turn" when "playing" something: Obviously this plot has no indication of "fun" in it. There's always a "player" having fun at any point. Depending on the person, almost everything on that plot might "fit" at some point. Why did I show it? All human interaction can be placed somewhere on there. To the left your influence is miniscule (only few people can influence book authors). To the right your choice is abundant. Think hiking. For games it has additional consequences: To the left you will basically make an interactive movie. That means extremely high production value or an artistic product. To the right its also very high production value. Or so flexible it's almost a content creation tool. Factorio</a>, Minecraft</a>, ... I want my game to be in the middle. Enough choice to make every decision count. Not so extremely limited that the game is pretty much deterministic. Games tend to look simpler there, but the mechanics are polished to death. It will be tough and I expect the game to suck, but me a huge learning experience. 🔗</a>Short-Term Goals</h3> Tweaking the core mechanics. Implementing the "paths" a player can take. Adding environmental effects, like a solar flares of a local star damaging shields of all ships. Adding energy that can be used to upgrade ships. And repair cores to heal ships after combat. And in-between that: Testing testing testing, finding people who will play-test such an early prototype. 🔗</a>Long-Term Vision</h3> I do have a nice narrative, and hope to add it in the game without boring players. I also would like to add side-quests, that can force players to take certain paths but will give rewards. For example, taking a friendly ship along and bring it to some destination. 🔗</a>Outlook</h3> I hope to have the core mechanics basics done in time for the next update. I also want to do some reviews of similar games I played to get inspiration. The reviews will be focussed on the core mechanics mostly. I'll start with Star Renegades</a>. Feel free to suggest topics you want me to dive into. I'll do so even when I have no clue what I am talking about, I'll just fake it. Seems to work well enough. Game Development: A Personal Journey Unknown — Thu, 09 Nov 2023 00:00:00 +0000 Today, let's take a peek at game development in general. Similar to what I already did a while ago</a>. A few months ago I picked it up again and to flesh out the design more and do some prototyping. It was nice and all, but I made the classical mistake of having a scope that would take years to implement. Depending on what you want to achieve, that could be okay - or not. In my case, I want to learn the whole process: Game Design</li> Game Development</li> Game Marketing</li> Game Self Publishing</li> </ul> I've been reading books and listening to audiobooks on the topic for a few years now. Its not all wasted time, but as an experienced software developer I can say: Only practising the art will make you really learn it. I am very certain that is true for almost anything that exists. 🔗</a>The Game Development Process</h1> Disclaimer: I did not yet publish or finish any game. This is what I learned from various sources I read. This is a rough diagram on how I imagine the development process generally works: The arced arrows represent loops on the timeline of development. I also think the span of the loops are essentially "true" in relation to each other. The prototyping phase will be shorter than the release phase. It, in turn, will be shorter than the implementation phase. This is not a reflection of my experience, but of the things I learned, reading from other gamedev blogs and post mortems. As you can see, I believe marketing should start even before the design or the prototype is done. There's no point were you should stop doing it. Change design as much as you like in the prototyping phase. Be more conservative in the implementation phase, unless play-testing shows your game sucks, then - uh - "pivot". Don't really change the design in the release phase, you probably will regret it - not having enough time to flesh it out and implement it. Content creation is pretty simple. Once you get your prototype running, keep the game playable as much as possible. If not for yourself, do it to have the opportunity to have people test it. Even better if you get a streamer to test an early version. 🔗</a>My Game Development Experience Up to Now</h1> I guess I should have started with the drawing above, and then make a plan for my game. I might have noticed earlier that I cannot create a large game and learn the rest of the development process in a reasonable time. To be able to practise anything besides the development itself, I needed to shrink my scope severely. I decided on a game that would take a few months to develop. Going even further, like a one-month project, would be sufficient to help my learn self publishing. Maybe even game design. But marketing would be lacking. According to some sources</a>, you need at least 6 months for things to get rolling. So my plan was to create a game in 3-4 months. I understand, that it will take longer. The plan was based on the untrue assumption, that I could work on the game for roughly 2 hours every day of the week. It doesn't matter that it will take longer, what matters is that it prevents feature creep due to a tighter schedule. 🔗</a>What I learned so far</h2> I had a basic idea, and decided to dive right into prototyping. This strategy usually serves me well, since most daily programming problems don't require much thought or planning. To be fair, I think programming for over 30 years helps a bit. Turns out, with games you pay a high price doing that. I started my prototype and then tried to iterate with different mechanics which lead to a lot of refactoring. Don't get me wrong, this is certainly a good idea once you have some basic mechanics settled. But at that time, I had barely a grasp. So my first lesson learned: 🔗</a>Don't skip the design part</h2> I did not want to waste more time, so I did something strange. I took a notebook, left the computer and started scribbling ideas. I drew the "scenes" I had in mind already. Then started sketching gameplay mechanics, and wrote down what came to mind. I did not fully flesh out the design on paper, but I had some nice narrative going. And, more importantly, I found the base mechanics I want to adhere to. 🔗</a>Where I am at</h2> So, I am still in the early stages. I don't want to reveal the current game design. Not for fear of someone stealing my ideas, ideas are available in abundance</a>. Let's just say I got my inspiration from games like Slay the Spire</a> and Into the Breach</a>. And yet, it is neither a card battler, nor has a chess-board like map. I'm currently iterating, trying to flesh out my idea. I don't yet see my prototype or core gameplay loop being fun. But I am convinced that I can change it, to be fun: The goal now, and my main focus of work, is to "fix" this problem. If I can make it click - the rest will follow. Comments - Take 3 - On Zola Unknown — Fri, 03 Nov 2023 00:00:00 +0000 A while ago</a> I added comments for my Jekyll base blog. Since then, I switched to zola</a>. Its basically a Rust based "clone" of the static site generator (SSG) Hugo</a>. Compared to Jekyll, it is a lot faster, and I found it to be a lot simpler. However, Zola has its own set of challenges. For instance, changing themes is nearly impossible and theme extension can get messy. That is the story for a future post. At some point I might consider creating my own SSG. Building a small one should be easy enough (and due to GitHub's Actions it could be used immediately). Why did I move? Jekyll was basically the go-to SSG back when GitHub only supported it. And it always supported an outdated version. And Jekyll is generally pretty slow. And after some small update I could not get it to run on my machine in a reasonable amount of time (minutes is reasonable here). Searching for a new led me to Hugo, and then in turn to its Rust "clone" Zola. I tend to prefer applications written in Rust nowadays, but only slightly - due to the fact that I could contribute code. Oh and, while migrating, I trashed the comment functionality - oops. Now its time to restore it back to its old (and pretty empty) glory. Previously</a> I used CGI. It's a bit archaic and cumbersome. So here's what we'll do: First, we'll transform it to a web service</li> We'll switch from our custom (and now obsolete) GitHub client to a working one I don't have to maintain</li> Our Javascript client needs to be re-added to the new Zola generated site</li> </ol> Here's a sequence diagram of how it is supposed to work: 🔗</a>Our own Web Server</h1> Now, first, we need to implement our own TCP stack... J/k we'll use hyper</a>. We could use Axum</a> but we won't be needing any full blown web server anytime soon. Let's fire up a simple server at 127.0.0.0:3000</code>: use core::convert::Infallible; use hyper::service::{make_service_fn, service_fn}; use hyper::{Body, Error, Request, Response, Server}; use std::net::SocketAddr; /// This is the actual endpoint: /// It should take a comment from a user by POST request and convert it to instructions on GitHub. /// The result should be a branch which includes the comment. And a PR for the branch for easy review and merge-ability. async fn post_comment_service(_req: Request<Body>) -> Result<Response<Body>, Infallible> { Ok(Response::new("Hello World".into())) } #[tokio::main] pub async fn main() -> Result<(), Error> { let addr = SocketAddr::from(([127, 0, 0, 1], 3000)); let post_comment_service = make_service_fn(|_conn| async { Ok::<_, Infallible>(service_fn(post_comment_service)) }); let server = Server::bind(&addr).serve(post_comment_service); server.await }</code></pre> Simple enough. 🔗</a>Choosing a GitHub Client for Rust</h1> According to GitHub</a> - there's no official client for Rust. But there are two third party clients. Octocat</a> seems to be on the decline. I'm sorry if I misjudged here, I just compared the activity to the alternative Octocrab</a> which has a lot more "everything". A quick check reveals it seems to be able to create branches, commits and PRs - everything we need. So we're using that, just a quick cargo add octocrab</code>. 🔗</a>Representing Comment Requests and Comment Data</h1> Most of the post handling code is the same as before, for brevities sake I will only skim through here: /// This is the request from a client #[derive(Deserialize, Debug)] pub struct Post { path: String, message: String, name: String, url: String, } /// This will be serialized into a comment file on GitHub #[derive(Serialize, Debug)] struct Comment<'a> { id: &'a str, message: &'a str, name: &'a str, url: &'a str, date: u64, }</code></pre> So, let's modify our post_comment_service</code> to actually do something. First we need to grab ourselves the content and then deserialize it to a Post</code>: let Ok(post_request) = hyper::body::to_bytes(body).await else { [...] }; let Ok(post): Result<Post, _> = serde_json::from_slice(&*post_request) else { return Ok(Response::builder() .status(StatusCode::BAD_REQUEST) .body("Invalid JSON".into()) .unwrap()); };</code></pre> Quick note: Using Axum, this would have been a lot shorter. The next steps: Create a branch</li> Add the comment to the correct comments.yaml</code> file</li> Create a pull request</li> </ol> Creating a branch requires a commit SHA it is based on, so we grab that and create a branch of it: let master_sha = match repo .get_ref(&Reference::Branch("master".to_string())) .await .expect("Could not get master ref") .object { Object::Commit { sha, .. } | Object::Tag { sha, .. } => sha, _ => unreachable!(), }; debug!("Creating branch {} from {}", branch_name, master_sha); repo.create_ref(&Reference::Branch(branch_name.clone()), master_sha) .await .expect("Could not create branch");</code></pre> Now, due to technical limitations (Zola can read a yaml file, but not a set of files) we need to have all comments of a blog in one file. This will be called comments.yaml</code> as stated above. A new comment should not just overwrite all other comments, so we first need to grab the file if it exists. let content_items = match repo.get_content().path(&path).send().await { Ok(content_items) => content_items, Err(_) => { info!("Assuming no comments present yet at {}", path); ContentItems { items: Vec::new() } } }; // There can't be more than one file with the same name: assert!(content_items.items.len() <= 1); let content = content_items.items.iter().next();</code></pre> Now lets create or append to the existing comment file: let new_comment = serde_yaml::to_string(&[&comment]).expect("Could not convert comment to yaml"); // Yes, this name is rubbish let author = CommitAuthor { name: "Comment0r".to_string(), email: "none@example.com".to_string(), }; if let Some(content) = content { // GitHub API requires the SHA of the old file to update it let (mut content, sha) = (content.decoded_content().unwrap(), content.sha.clone()); writeln!(&mut content, "{}", new_comment).expect("Could not add comment to file"); repo.update_file( &path, format!("Added comment from '{}'", comment.name), content, sha, ) .branch(&branch_name) .commiter(author) .send() .await .expect("Could not update file"); } else { debug!("Creating new file at {}", path); repo.create_file( &path, format!("Added comment from '{}'", comment.name), new_comment, ) .branch(&branch_name) .commiter(author) .send() .await .expect("Could not create file"); } </code></pre> I decided against parsing the existing file. It should be fine. If it's not, I can fix it manually, its a YAML</a> file after all. Instead, just a "grab the existing content" and "append new comment" in YAML format, if nothing is there "create a new file" and "write the comment as initial content". Last but not least, I don't want to manually merge or create pull requests, so let's do that as well: oc.pulls(&config.owner, &config.repo) .create( format!("New comment from {}", comment.name), branch_name, "master", ) .send() .await .expect("Could not create PR");</code></pre> This will create a PR with the title "New comment from " trying to merge the new branch into master. Now, this service serves no purpose, if no-one ever calls it. That would be... 🔗</a>The Client Part</h1> I'll omit the html part for now, it's mostly a boring form with a name, an URL and a message field - and a submit button. The "interesting" part is the JavaScript client, that will do the following: Take the comment</li> Send it to an endpoint</li> Show the user a success or error page</li> </ol> Here is the first part: const form = document.getElementById('commentForm'); form.addEventListener('submit', function (event) { // Don't submit actually event.preventDefault(); const formData = new FormData(form); const commentData = { name: formData.get('name'), url: formData.get('url'), message: formData.get('message'), path: '{{ current_path | safe }}', };</code></pre> Don't get confused by the {{ ... }}</code> stuff, that's part of the template engine Zola uses (Tera</a>). With the data firm in our grasp, onwards to step 2: // Now post the comment to the service fetch('{{ config.extra.api_url | safe }}/comment', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(commentData)</code></pre> And finally step 3: }).then(response => { if (response.ok) { form.reset(); window.location = "/pages/submitted"; } else { window.location = "/pages/submission-failed"; } }).catch(error => { window.location = "/pages/submission-failed"; });</code></pre> I also clear the form when the submit succeeded. Otherwise, returning to the page would keep the form content. On error, I let the content stay, maybe it was just a hiccup after all? 🔗</a>Security</h1> The service itself is pretty small. Due to Rust's nature, I consider buffer under/overflow attacks to be pretty unlikely. Not impossible mind you. Rust could have some memory safety bug. Hyper uses some unsafe</code> and could have a bug there. Same with tower</a> which I will use below. I pass much of the user entered data to Octocrab, which in turn relies on other libraries and interacts with GitHubs API. I expect their API to refuse any malformed requests, otherwise its their problem (unless..). 🔗</a>Threat Model</h2> The service will run on a trusted machine (due to access to a personal access token from GitHub). It is meant to run behind a reverse proxy, but should also work as a public service. It will not guarantee to work under a DOS attack, but it will guarantee not to let an remote attacker DOS the whole host system. The main DOS vectors against the host system are: Sending large chunks of data in a post request which would then be sent to GitHub (clogging up up- and downstream)</li> Sending many small requests which would result in a multiple of API calls to GitHub</li> </ul> 🔗</a>Changes Required by the Threat Model</h2> First, lets limit the input our services receives to have some basic DOS protection: let body = Limited::new(req.into_body(), 100 * 1024);</code></pre> Let's also do some basic rate limiting: let post_comment_service = make_service_fn(|_conn| async { Ok::<_, Infallible>(RateLimit::new( service_fn(post_comment_service), Rate::new(1, Duration::from_secs(10)), )) }); </code></pre> It would certainly be better to limit per IP. But the intention here was not to prevent DOS attacks to the service itself, just the host system. 🔗</a>What's Next?</h1> Obviously, the code could be improved - it was basically almost completely rewritten in about 2 days. This will have to wait for another time... 🔗</a>Conclusion</h1> It was a fun and sometimes tedious exercise. Hyper's API is "strange" - services return a Result<.., Infallible></code>. Why not just the real result. I guess I could read up on the reason, but its certainly hidden very well. Octocrab is pretty decent. It's a bit cumbersome at times (i.e. send()</code> for API that retrieves things). Authenication is really annoying and lacks documentation - but is easy enough once figured out. I ran into an issue where I configured the wrong URL to access GitHub - I swear I saw it somewhere in the Octocrab repository. This was made even worse by the API suddenly trying to deserialize incomplete JSON objects from GitHub (like cut off after 21 characters, without any reason why). It took a fair bit longer than expected. The parts I did not present: The cloudflare config to route the api</code> sub-domain to my VPS</li> My VPS' Apache2 config for a secure reverse proxy</li> Getting a signed certificate</li> </ul> I hope you enjoyed this post of mine, feel free to comment. It should work now. If not, I'll just assume you're happy and live in blissful ignorance. 4X Game Loop Unknown — Fri, 05 Aug 2022 00:00:00 +0000 I think I don't really need to explain what a 4X game is, maybe not even what the 4X stand for. But, I'll do it anyway - the gameplay loop of a typical 4X game is: eXplore</li> eXpand</li> eXploit</li> eXterminate</li> </ul> Much of the fun of this simple formula comes from the fact that none of those factors stands on its own. You usually cannot expand without exploring first. Sometimes to expand by exterminating an enemy at a location first. What is there to exploit, if you did not expand before? And how will you exterminate, if you lack the resources you ought to have exploited first. Let's dive deeper into the abyss</del> parts of such a game: 🔗</a>Exploration</h2> The most basic approach is sending out scouts. An alternative would be spying. Maybe diplomacy uncovers some secrets as well. Keywords: Scouts</li> Diplomacy</li> Special events</li> Spies</li> Racial abilities</li> Tech abilities</li> </ul> 🔗</a>Expansion</h2> Again, there's the direct way of sending a colony ship (settler). Alternatively you can take over an enemy colony. A random encounter could grant you a new colony. Keywords: Colony ships</li> Outposts</li> Diplomacy</li> </ul> 🔗</a>Exploitation</h2> Pumping up the population. Building factories. Gather food. There could be a lot of resources to be gathered. Also things like research are part of this. There are also hidden resources. A large army could incline neighbours for that large tribute. Keywords: Research</li> Mining</li> Taxation</li> Diplomacy</li> Spies</li> Production</li> </ul> 🔗</a>Extermination</h2> Send your force and crush your foes. Or let your spies sabotage the heck out of them. Or let some allies or vassals handle it. Keywords: Battle ships</li> Planetary defense</li> Spies</li> Diplomacy</li> </ul> 🔗</a>Design for my Game</h1> I planned on covering all topics above, but that is basically to large for a single post. In the last post I covered a few basics of research. I will try a breadth-first approach in design and switch to another topic. Let's tackle... 🔗</a>Exploration</h2> The basis for almost all games here is using some sort of scout. It would not make sense to change that, it is pretty much what players expect to find. But, what is a scout? A special ship (surveyor anyone)? A player designed ship? Pre-designed units have a large benefit: They can be balanced pretty well. The player chooses which ship to build, but not what it is composed of. Player designed ships are way more interesting in concept. In practice, it boils down to a few ships with a specific purpose (like scouting). Remnants of the Precursors for example allows only a few designs, which emphasizes that. 🔗</a>Ship Design</h3> I do think, limiting the number of designs is good idea. But for the actual design of a ship I have another idea. As usual, ships are composed of different modules. Each module modifies some attributes of a ship: Attribute</th> Effect</th></tr></thead> Cost</td> Makes your ship more expensive (but shiny and pretty as well)</td></tr> Space</td> Most modules take up some precious space on a ship, but some can extend it</td></tr> Range Bonus</td> Increases/Decreases the range a ship can distance itself to the nearest colony</td></tr> Interstellar Speed Bonus</td> Increases/Decreases speed for long range travel</td></tr> Interstellar Stealth Bonus</td> Makes ships more/less detectable while in flight</td></tr> Hit point Bonus</td> Increases/Decreases the hull of a ship to take more of a punch</td></tr> Shield Bonus</td> Similar to hit points, but weak against energy weapons - strong against physical weapons</td></tr> Combat Speed Bonus</td> Increases/Decreases speed for combat</td></tr> Combat Repair</td> Repairs ships by a small amount each combat turn</td></tr> Particle Damage</td> Adds particle beams with some strength as combat and point defense weapons</td></tr> Projectile Damage</td> Adds projectile weapons with some strength as combat weapon</td></tr> Missile Damage</td> Adds missiles with some strength as combat weapons</td></tr> Combat Stealth</td> Makes ships harder to hit or easier to hit in combat</td></tr> Colonists</td> This allows a ship to colonize an empty planet</td></tr> </tbody></table> A ship, by itself is just a hull. The collection of modules selected will determine its purpose. But, there's no free lunch. All modules will be balanced, one way or another. For example, a missile launcher weapon will most likely take up a lot of space and will not be cheap. A particle beam weapon on the other hand could be smaller and cheaper. But at the cost of reduced combat stealth, and a weakness in damaging the hull of enemy ships. Once again this reminds of RPG attributes on items: That is intentional. I really want to enforce that ships are good at some things and bad at others. Otherwise you will end up with the typical "high tech jack of all trades" ships. Also, the number of designs should be limited, as with ROTP</a>. I would like the player to see each design as a "character". Although with some serious multiple personality disorder. So modifying a design should be possible. What happens with the existing ships? They could keep their original design. But then, the game could just have unlimited designs. They could be scrapped. They could be retrofitted. Or something in-between. No code was harmed</del> written for this post. As mentioned before, I already have a small code base. But exploring (no pun intended) the design space is more of an issue for now. So next time we take a look at Expanding. MOO resp. ROTPR inspired 4X game Unknown — Sat, 30 Jul 2022 00:00:00 +0000 So Sonko</a> started a new project. Following suit, I jumped back in time to already have a game project on-going for quite some time now. A bad habit of mine is to reach some milestone and then "pause" (drop) the project. But now I'll return to it, and as a small incentive to keep on it, I'll start this blog. As with Sonko, this means my StarCraft AI related projects are on hold (don't worry, the basil ladder</a> will keep running). Also, on a rather technical note: I dropped Jekyll as a static site generator and moved to zola</a>. Every Jekyll upgrade wasted a lot of time to get it running again. Zola is just one binary, and it should run fine on github actions as well. 🔗</a>Introduction</h1> I played Master of Orion 2</a> (MOO for now) a lot when I was younger. Even back then I tried to create my own clone of the game. But the scale of the game was a bit to much for me back then - maybe even today. But not all thing were good. It irked me a bit how much the game slowed down in the later phases due to the massive amount of micro-management. Fast forward some 30 years and some more MOO games. I always was a fan of easy to learn hard to master games. Almost none of the games inspired by it (or being successor to) seem to do that. They just upped the complexity. Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. </blockquote> Antoine de Saint-Exupéry, Airman's Odyssey</li> </ul> Remnants of the Precursors (ROTPR for now) has a simple interface. Maybe even a bit to bland. But it gets the job done. I did not really play the original Master of Orion</a>, I was still wasting</del> enjoying my time with Civilization</a>. I do like the simpler colony management, which avoids going through every colony in the mid-late game. Spying is a bit strange, it is not really obvious what multiple networks and/or high spendings are doing. Master of Orion 2 (not 1) is a bit different, more complex in some aspects (colony management) and less so in others (less diplomacy/spying). The UI is a bit dated, and looks only good when shrunk down. Still looks nice though. 🔗</a>Designing My Game</h1> My game already has quite a lot of code, but barely anything to show. I decided to create the game abstraction in code as a first step. This was a mistake in my opinion. While its clear that the inner game model should be sound, only testing it via unit tests is rather dull. It currently covers the basics of building ships and colonizing other systems. Like any software architecture, it is best to delay the choices which "cost" the most - as long as possible. This might sound unintuitive, but help not wasting a huge amount of time due to some bad "large" initial decisions. Although I got some basics covered, I want to explore design space a bit further before continuing/refactoring. I know a few things I want in the game design: Colonization should be per star system (like ROTPR). Colonizing individual planets really takes its toll on usability. Multiple different factions owning each a planet in a system? A separate UI for planets in a system? It just makes things more tedious.</li> Research based on a RPG like skill tree. Even ROTPR, which tries to make research meaningful succumbs to the "unimportant research item" problem.</li> </ul> Tech items above are just examples (for some I don't have an idea on what they do), I do want to make it unconventional - yet useful. Every tech has 3 upgrades which will improve on the previous state in one way or the other. Ideas for unconventional techs: Fanatics - For every upgrade, establish a colony on any unoccupied star system</li> Boost - Increase productivity of a single colony for a short while</li> </ul> Ideas for more conventional techs: XYZ Armor - Unlocks a type of armor, further upgrades improve efficiency</li> XYZ Weapons - Unlocks a type of weapon, further upgrades improve efficiency</li> Productive - Increases productivity per upgrade level</li> </ul> Now the real change comes with the way you unlock techs. Usually, you designate a research topic and after some turns you'll get it. This is not the case here. Instead, you build up research points - and once you have enough you can immediately unlock or upgrade a tech. This allows for fast reaction to new circumstances. There are also only a very limited amount of techs to unlock. With either, MOO2 or ROTPR I always feel like the actual decision of what to research matters little. Yes, some do - but you can always replace them later with something else. I want the player to be able to focus on a certain play style, stick to it, but still be able to win. That's all for today! Next Time: Gameplay Loop A son was born Unknown — Sat, 16 May 2020 00:00:00 +0000 This was meant to be a tech related blog, mostly for Broodwar AI related stuff and private projects. Since private projects are included, I guess one could call my son a private project. Screaming into the light, he was born in late February. His name is Benjamin, which I am certain means horse-dung in some weird language. I do not care, go away! And due to Corona, we have been left alone for most of the time since then. My last blog entry was in January, and up until now I really did not have the energy to write a new article. But since most of my free time is now reserved for serving the little demon, I'll just write about what I know best now: My spawn. Prepare for many picture which may or may not include my son (hint: nope, no pix from him - maybe in a later post). As with all babies, he is cute (actually I believe mostly parents find most babies cute, for my part they look like french baguettes mostly...). If you remember Tamagochi, it is really its human form. Lucky for me, we have a spare room - otherwise working would be very hard due to missing shut-eye. Which means shift 1 is work, shift 2 is work, shift 3 is sleep. And things like this mostly eat into shift 3. A little human goes through a lot of development phases. There is the cute phase... Then there is the crying phase... And there is the default happy phase OK, the last one might be slightly exaggerated. And it is not the default. At least for my son, most of the time he is pretty happy. You are supposed to react to the baby's needs. Ignore that at your own peril (eardrums). Really, a lot of time I look at my son and this is what I see: I believe the general baby package works like this: You receive it</li> It comes un-boxed, without manual - W.T.H.?</li> It must already be defect, or is it supposed to behave this way</li> Your midwife (its common to have one here) tells you a lot of good info, and a lot of mumbo-jumbo.</li> She tells you what homeopathy "stuff" (I refuse to say medicine here) you can give you baby - that is ok, since placebo also works for babies. (Btw did you know, there is also a nocebo</a> effect? Cool!)</li> She tells you to see an osteopath (that is so much dumbfuckery). Uuuuhhhh magic energy waves uuuuhh</li> You start to get a grip on it... or do you?</li> </ul> Thing is, the first few weeks you could care less. Your baby can see like 30cm (about 12in you strange people who stopped in time). It can't really focus or look at you. After that it actually can focus you, which is good - it can now target practice with its sound-wave gun while looking at you. Then it starts to smile at you. First for short periods of time, then more. It might also randomly switch from crying, screaming, and laughing. We're currently within the Stan phase. What that is? And with that, I will conclude today's rant. Comments for static pages? - Part 2 Unknown — Sat, 25 Jan 2020 00:00:00 +0000 Looking back</a>... I need a bit of DIY GitHub API for Rust. 🔗</a>Still step 2: Create a branch and PR automatically</h2> Thankfully, the V3 API</a> is really simple. Using our tRusty language, we can define some structs to be serialized to JSON for requests: #[derive(Serialize)] struct CreateRef { r#ref: String, // The name to be used sha: String, // The commit SHA to point to } #[derive(Serialize)] struct CreateFile { message: String, content: String, branch: String, committer: UserRef, } #[derive(Serialize)] struct UserRef { name: String, email: String, } #[derive(Serialize)] struct CreatePR { title: String, head: String, // The branch to be merged base: String, // The target branch for the merge (ie. master) }</code></pre> The basic steps we want to do are described by these: Create a branch, using CreateRef</code>. Git uses refs for things that "have" commits. A branch is just that!</li> Create a file on the branch with CreateFile</code>. UserRef</code> will be used as committer (me in this case).</li> The last step is to create a PR with CreatePR</code> (quelle surprise), to merge the branch back.</li> </ul> The file we want to create has to be converted to base64 to be used by CreateFile</code>. The content itself should be YAML and contain this: #[derive(Serialize)] struct Comment { id: String, r#ref: String, message: String, name: String, url: String, date: u64, }</code></pre> Luckily serde</a> comes to our rescue once again and happily creates a serializer to yaml here. Another helpful small library provides base64 encoding. The result is this: let file = CreateFile { message: "Comment".to_string(), content: encode(&serde_yaml::to_string(&comment).unwrap()), branch: branch_name.to_string(), committer: UserRef { name: owner.to_string(), email: owner_email.to_string(), }, };</code></pre> The requests itself look quite similar. As an example, here's the CreateFile</code> one: fn create_file( client: &reqwest::blocking::Client, owner: &str, repo: &str, path: &str, create_file: &CreateFile, ) -> reqwest::Result<reqwest::blocking::Response> { let url = url::Url::parse( format!( "https://api.github.com/repos/{}/{}/contents/{}", owner, repo, path ) .as_str(), ) .unwrap(); client.put(url).json(create_file).send() }</code></pre> No, reqwest</code> is not a typo! It's actually a popular library</a> (I don't mean the javascript one). I don't really need non-blocking I/O here, so the blocking</code> client is put to good use. The whole Rust project can be found in my GitHub repo</a>. I tried to solve this "problem" with some constraints: It should be inexpensive</li> It should respect the privacy of my readers</li> It should be simple enough to fix or port</li> It should not depend too much on third parties</li> </ul> Using GitHub for the blog and for comments is very inexpensive. I use no third party commentary service, as such the privacy is protected as much as is possible here. The HTML part is very simple and only depends on Jekyll</a>. The Rust part is also simple and fits in less than 300 lines of code of Rust. Success ✓ If you have any comments, please leave them down below - since you are actually able to do so now! Comments for static pages? - Part 1 Unknown — Tue, 21 Jan 2020 00:00:00 +0000 This</a> is actually a static page hosted by GitHub</a>, powered by Jekyll</a>. But how to get a comment section? 🔗</a>Give Me Comments</h1> Weeeelll.... You could use a service like Disqus. Or, you use the idea from damieng</a>. Jekyll has a neat feature: you can place data files under _data</code> and access in Liquid templates. And that's more or less the starting point. Add comments as data and render them via Jekyll (utilizing Liquid). Using the folder _data/comments/{slug}/</code> to place comment files in. (slug</code> being the "slugified" post name.) The actual files can be in a few formats, but I used yaml. Here is an example comment: --- id: 1579711318_617889634 ref: basil-timeouts message: Testing comments name: Bytekeeper url: "" date: 1579711318</code></pre> id</code> is the id of the comment and the base name of the file: 1579711318_617889634.yml</code>. ref</code> is a reference for what the comment was for. Ie. a slug or the id of another comment (not yet working here). message</code> is too complicated to explain... really. So is name</code>. url</code> is the website a user gave and will be used to render the commenter's name as a link to the site. date</code> a simple timestamp and, as you might have noticed, part of the id</code>. But having the comments stored as data will not be enough, unless I can convince people to check out the GitHub repo for comments. 🔗</a>Render Me Comments</h1> This one will be quick. I use a modified version of damieng's _includes</a>. Since I modified the structure a bit I had to adapt it. I also changed the layout bit, the final version can be seen down here (unless it does not work in which case: bummer). For now they look ok but will certainly need more fine-tuning, especially once it's possible to reply to individual comments as well. Storage place for comments ✓ Rendering comments ✓ Adding comments: ❌ 🔗</a>Add Me Commentse</h1> This could be as simple as people wanting to comment grabbing a fork of my repository and adding a comment file in data and creating a PR for it. I'm pretty sure this avoids all comment spamming bots and requires almost no moderation. You don't want to fork? Ok, I'll give you commit r... waaait. So basically, using damieng's idea: I want a PR for each comment</li> I want branch and PR to be automatically created</li> Once I merge it, GitHub will automatically update and voilà</li> </ul> 🔗</a>Step 1: Create a service that accepts comments</h2> This could be any form of (micro) web service. Damieng used Azure Functions. But Amazon Lambda or Google Functions would be fine too. But I'm oldschool... I already have a VPS, so I use CGI</a>! I'm also a experienced Java developer, so I used Kotlin</a>. J/K of course I used Rust</a>. I learn Rust as I go (I already tried that once but the burrow checker tried to murder me in my sleep), so take everything here with a grain of salt. So, let's start with some Rust code. There is this really nice library called serde</a> which has a ton of serializers and deserializers for various formats. Like urlencoded</code> which is what a simple form post will send. Now let's write the code to process a POST</code>ed comment: #[derive(Deserialize)] struct Post { r#ref: String, message: String, name: String, url: String, redirect: String, }</code></pre> For those who have never seen C, a struct</code> is like a class</code>: A container for fields. That's it! The derive</code> attribute with the Deserialize</code> argument will create the code to dump in a urlendcoded</code> string and get out an instance of Post</code>: let post: Post = serde_urlencoded::from_bytes(body.as_slice()).unwrap();</code></pre> I omitted the boilerplate code to read the data from stdin</code> - which is how you get data with CGI</code>. The full code can be seen in my GitHub repo</a>. 🔗</a>Step 2: Create a branch and PR automatically</h2> Creating a branch and pushing it should be fairly simply with GIT</code>'s CLI. But for the PR, the GitHub API will have to be used. It can also be used to create a branch and (!) even create a file in there. So I just have to use a GitHub API Rust implementation to solve this. Actually, there are a few - but they are mostly unmaintained. They also don't allow the shenanigans I need. To be continued Slow bots on Basil Unknown — Mon, 13 Jan 2020 00:00:00 +0000 If you haven't yet, check out BASIL</a>. It's a 24/7 Starcraft league, but for bots! It usually runs fine nowadays. But sometimes an external hiccup occurs. One of those is the problem of detecting who to blame if a game times out. It works fine if the game ends with the in-game timeout of 60min, since the Tournament Module</a> BASIL uses will make both bots leave and select the winner based on the score (That might be unfair, but that's a topic for another post). But if a game gets killed because it took to long (wall-clock time), what then? There are no scores, no replays - nothing essentially. Besides a bot just hanging, most bots just take their time. So I wanted to penalize the slower bot in that case. This looked like a good idea back in the beginning. For dll</code> bots this works fine, but for client</code> bots, it didn't work up until BWAPI 4.4</a>. As of today that means that games timing out in that fashion will not be counted. One could abuse this by timing out intentionally for imminent losses. I don't expect this to happen, the bot community is generally competitive, but also friendly and fair. (Totally unrelated: I can actually disable bots permanently)

bytekeeper.org

BASIL broke

Why You Don't Finish

🔗</a>Flight</h2> What if your novel idea is just coping, or you have no new idea, but are just bored? The real reason might be fear. Whatever you create:</p> Will it be good enough?</li> What will people think of it?</li> Will I disappoint myself?</li> Will anyone use it?</li>

A Rant on Software Development Bloat

GameDev Review: Star Renegades

Remnants of the Vanquished

Shogun Showdown Core Mechanics

🔗</a>What is the Game?</h1> It's a turn-based, rogue-like battler set in a Japanese-inspired setting. It features nice pixel art and a good soundtrack. I have not yet beaten the game, but from my current knowledge it basically has a few scenes:</p> a Shop scene</li> a Combat scene</li>

The Yet to be Named Game - Continued

The Yet to be Named Game

🔗</a>Game of Stacks</h3> What is shown above contains the basic idea of the game:</p> You and the enemy have a stack of ships.</li> Either "player" can only perform actions with the ship on top</li> Actions generally evolve around stack manipulation</li>

Game Development: A Personal Journey

Comments - Take 3 - On Zola

🔗</a>The Client Part</h1> I'll omit the html part for now, it's mostly a boring form with a name, an URL and a message field - and a submit button. The "interesting" part is the JavaScript client, that will do the following:</p> Take the comment</li> Send it to an endpoint</li>

4X Game Loop

MOO resp. ROTPR inspired 4X game

A son was born

Comments for static pages? - Part 2

Comments for static pages? - Part 1

Slow bots on Basil