insraq

I am recently working on a "realtime with pause" style grand strategy game using my own engine (think Europa Universalis, Crusader King, Hearts of Iron).

The trick is to separate the logic simulation from other game loops (rendering, UI, input, sound, etc). So when a player pauses the game, everything else still more or less works. And the logic simulation should be able to take user "command" while being paused.

Most commands should mutate the game state and reflect in the UI immediately. A few commands that have to wait until the next tick should at least acknowledge the action result.

I wrote a post (rant)[1] about my experience of releasing a game on macOS as an indie dev. tl;dr: Apples goes a long way to make the process as painful as possible with tons of paper cuts.

[1] https://ruoyusun.com/2023/10/12/one-game-six-platforms.html#...

I have recently done an engine rewrite for my sequel game and I very much agree with this. In my postmortem[1], I wrote:

> Most people think of a “game engine” as code that is shipped with the game executable. However, that’s only half of it. The other half, which I’d argue is more significant, is the code that is not shipped with the game - level editors, content pipelines, debugging/profiling tools, development workflows, etc.

Writing tools is arguably more boring and tedious compared to writing an engine, and that's where lots of "making a game with custom engine" type of project grinds to a halt

[1] https://ruoyusun.com/2025/04/18/game-sequel-lessons.html

Just want to chime in that although this comment is a bit harsh, it does hold a lot of truth. As a game netcode engineer, most of my time is spent on latency hiding techniques and its consequences (for example, we use rollback netcode and lots of efforts are spent on minimizing visual/sound glitches when mispredict, rollback and reconcile). There are lots of middleware that help with this (eg. Photon, SnapNet, etc) but in general there's no silver bullet - it's highly gameplay specific. Even for the same game, the solution can vary depending on different trade-offs (i.e. budget, correctness/anticheat).

As to how to store the game state in memory, it's usually not something that needs much thinking: it's simply done the same way (or similar) as the game's client code. After all, netcode is mostly about efficient state replication and this saves CPU time when replicating it across clients - and gives more CPU time for minimizing bandwidth (like delta encoding, quantization, etc). If you want, you can utilize some techniques like ECS to optimize for CPU cache locality, but it affect gameplay code a lot and would need to get the whole team onboard.

Also, I just noticed the username "gafferongames" - Glenn's blog[1] has been a must-read for netcode engineers. It helped me a lot when I started working on netcode in the 2010s

[1] https://gafferongames.com/

I am a solo indie game dev - and have released Industry Idle[1] - a factory building/supply chain management/trading sim about two years ago during pandemic where I've got some free time. Now I am working on a spiritual successor called CivIdle while maintaining Industry Idle (it has a global real-time player driven market, which surprisingly takes quite some effort for maintenance, and that has slowed down the new development by a considerably amount)

P.S. Industry Idle has been open sourced a while ago, if anyone is interested in the code[3]

[1] https://store.steampowered.com/app/1574000/Industry_Idle/

[2] https://store.steampowered.com/app/2181940/Cividle/

[3] https://github.com/fishpondstudio/industryidle

No. Multithread JavaScript (WebWorker) is a bit hard to work with. So currently they are all running in the main thread, just "at separate cadences"

You are right. A heap/priority queue would be good. However the resources needs to be iterated and ticked every frame - to update the rendering data (transform) and perform culling (because the viewport might change - a player might move or zoom the camera).

Thanks for the comment. It is indeed something I've been considering. In fact, lots of the optimization done here is to move the logic away from the game objects , which should enable the flow you've described.

I ended up not doing it in this iteration because:

- cocos2d's custom shader support is kind of poor, especially documentation is pretty much zero

- the dot is not "purely" visual. For example you can trace and highlight a resource's movement. This is not a blocker per se, but requires more work

> Are the deliveries continuous and not bursty

They are not "bursty", but they can fluctuate. Power fluctuation, fuel shortage or upstream supply chain issue could cause a building to skip a production cycle - and impact all its downstream. In fact that is a core challenge in the game. So the core game logic has to be simulated, not calculated.

Doing multithread in JavaScript (via WebWorker) is kind of painful.

Hi, the game is already doing this. As mentioned in the article, logic tick is running at a much lower frequency than rendering loop (30/60FPS). When playing in the browser and is minimized, the game will simply pause - rendering and logic. Browsers will throttle timers which will cause inaccurate logic tick as well. Most idle gamers actually do not like this behavior [1] - people prefer the game to run in the background as well.

The "background mode" mentioned in the article is about the Steam version, which runs in Electron and I have to set `backgroundThrottle: false` flag. In this case, Electron will not throttle timers and I can safely disable rendering while leave the logic running.

[1] https://www.reddit.com/r/incremental_games/comments/seid8w/c...

I recently did exactly this for my game (Industry Idle) on Steam. I added Linux build but pinned a post that says "Linux and Mac support are considered experimental and are supported on best effort basis" (https://steamcommunity.com/app/1574000/discussions/0/3122659...)

Most people are very helpful and quite understanding that as a sole indie developer, it would be hard to support all the configurations. But occasionally I get angry emails and negative reviews about game not running on Linux.

Given the sales (Linux is 1% of the total sales, Mac is 3%), I would say for an indie developer, it makes more sense to put Linux support on a low priority. It is unfortunate for Linux gaming community but it is what it is.

Also even though Proton has come a long way and has become relatively stable - occassionally there are some strange issues (like Steam Cloud sync fails, etc) here and there. But overall the effort is much lower compared to maintain a separate Linux build.

That name is unfortunate because there's already a hyperscript: https://github.com/hyperhype/hyperscript which is completely different (which I am quite enjoying for constructing virtual dom in pure js)

I have evaluated several "typed Lua" solutions[1]. Haxe might be a bit too heavy-weight depending on what you try to do. There're Teal and TypeScriptToLua which might be a better fit.

[1] https://ruoyusun.com/2021/01/31/typed-lua.html

I've written some learnings after shipped my first game: https://ruoyusun.com/2018/06/15/guide-for-non-game-dev.html

As a professional software dev, I've noticed that while both game dev and software dev are "writing code", they are done in a very different way.

As a software dev, the value proposition is more or less clear before you start writing code. As a game dev, you can only start to see your value proposition after you have finished your code - that's why game code, especially as an indie without clear distinction between prototype and production phase, tend to become spaghetti really quick - and that's fine. If you spend too much time to make the code look nice, then you are not spending enough time to make the game actually fun.

Software usually has some logic behind it - it has to make "sense". A game doesn't necessarily have to make sense - it needs to "feel right" and "fun". That means your nicely designed abstractions actually won't be reusable - copy & paste is much more pragmatic. You can start to look to refactor after your game is actually successful (or fun at least) but even then you will realize that most of the code is not reusable.

A big part of your game code is actually "content", instead of "systems" - meaning they are closer to a "script" than a well architectured software code. So you write more if-else and less inheritance and encapsulation (unless you are writing your own engine, then in that case, your engine code is actually close to software projects).

And if you hate writing UI for software, you'll hate writing UI for games even more.