insraq
Joined 15 years ago
Karma
669
Submissions
84
Member since
Jul 4
Recent submissions
Comment · 6 months ago
Comment · 1 year ago
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#...
Comment · 1 year ago
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
Comment · 1 year ago
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
Comment · 3 years ago
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 considerable 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/
Comment · 4 years ago
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"
Comment · 4 years ago
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).
Comment · 4 years ago
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
Comment · 4 years ago
> 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.
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.