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.
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
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
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]
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
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.
With the suggested method you could skip a production cycle by unlinking a producer from a consumer. Due to the setTimeout the fluctuations propagate through the factory just as they would with resource nodes flying around.
Of course the details are a bit more complicated (you don't want to miss resources or produce too much due to the abstraction), and I see why you went the easier route ;-)
Yeah, multithreading is often a pain. OTOH the gains can be enormous.
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.
I think idle games are a special case here, in that variable timesteps aren't necessarily a liability for them. In an ideal world, one would like all the systems in an idle game to be able to quickly simulate arbitrary amounts of time (for offline progression etc), and if the whole game is made that way then in principle one is immune to throttling. But I think games actually built that way are pretty few and far between.
Are the logic and the rendering loop in separate threads?
If so, how do you ensure that when the rendering loop reads the shared state, it sees something consistent (i.e. something that hasn't been updated by the logic loop in between the time when the rendering loop started accessing it, and the time when the rendering loop finished accessing it)?
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.
This is partly the fault of Steam. They simple have a single "supported" boolean. It would be nice if you could provide a warning or "partial support" label so that people had these expectations when buying the game.
Right now the flow for the user is 1. See store page 2. Buy 3. Play 4. Hit bug.
This is the moment when they find out that they bought a game that was not in fact supported. That is super frustrating (and possibly legally requires a fix or a refund). If there was a 1.5 step of "This game offers no support for Linux" or "This game offers no support for any distribution except Ubuntu 21.04" then it is much more acceptable, because I accept that detail before purchasing.
Recently stumbled over a game that did that a bit differently. On the steam page there is only support for Windows listed. But it actually downloads a Linux version. That version worked just fine for me, but they say they can't support it, that's why it's not listed. So there is more than single "supported" boolean (and games can list required Linux version in the requirements section I think).
I don't disagree that this would be beneficial, but I also don't think it would do anything to prevent the additional support burden and negative reviews in aggregate. If you need proof of this, see the amount of negative reviews on some Early Access games that are very up front about the lack of polish in their current state.
Steam is quite generous about refunding games, either because you purchased them accidentally or they didn't run correctly or any other reason, as long as you don't have more than a few hours in the game. I think that's a much better approach than having to implement what's effectively a DRM system in software, or a completely separate trial binary containing only part of the game.
> This is partly the fault of Steam. They simple have a single "supported" boolean. It would be nice if you could provide a warning or "partial support" label so that people had these expectations when buying the game.
You can have Linux builds available via Steam without listing Linux support on the store.
That is interesting, but too far the other way. I wouldn't even think to look around to see if they have an unsupported Linux version available. But maybe I'm just too picky.
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)
[1] https://ruoyusun.com/2023/10/12/one-game-six-platforms.html#...