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)
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.
I recently did a fairly large undertaking with TypescriptToLua.
(Porting the Lua API + types of a major music DAW to TS types to make it possible to write type-checked scripts in JS/TS).
The experience was mostly smooth, barring a few bumps of non-standard TS stuff. (It's also very actively developed)
BUT, the community is amazing. They have a Discord server where the core devs are active and very helpful, they quickly and politely helped me fix the small issues I ran into.
I never knew Haxe was capable of this, so I can't give a fair assessment, but now I am interested in trying it as well!
At the time I started working on my scripts - sometime in 2019 - I think neither Teal, nor TSToLua existed. Not 100% sure about that, but I remember searching for type systems for Lua and coming back empty handed back then :(
I'll take a closer look at both, they seem interesting.
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.
As a professional software dev who has approached gamedev a few times, I finally realized it was a theater stage and not a simulation. Every time I tried to start a game I wanted to make a simulation. I dove into graphics more, I realized it was all puppets and cutouts on a string, not some grand design.
The best graphics abstractions allow artists to pretend they’re working with just another pencil or brush. To them, it should be as non technical as possible. Without tools a perfectly functional physics system is useless since it’s only simulation. There’s no content.
You’ve effectively created a new world for the artist to operate in, but have given them nothing to use. “You need a stage to act? Well there’s a tree over there...”
They’re really good at technique and learning things, but they tend to build the work around those techniques and limitations. The tools you give them focuses their energy in the places you want. The absolute best graphics programmers get this too, and it can all end up a creative and cohesive show if done properly. There are many games that intentionally limit the art in some way to create a theme. A way to get a bunch of artists in the same creative space.
The actors work together with the crew and backstage in the best shows. And that’s a game. A tight dance between the artists and technicians. Personally that’s where my love for it comes. Putting on a good show is hella fun. And artists respect tech. They may not get it, but they always respect it. Unlike business.
I’ve written UIs for various platforms/targets including “UI frameworks” for a games engine and wow you’re not wrong. Made me beg to build web UIs again.
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