A game I have been working on in 2019 and wanted to upload here so I can look at it again when I’m older. It’s another project of mine and of course another one that didn’t get the chance to see the light of day. My idea was to create an idle factory game in 3D that always runs in the background and doesn’t cheat you by giving you less income when it runs in the background.
Another challenge I assigned myself was to decouple my “backend” code completely from the visuals. That meant no MonoBehaviours, no Update loop, none of that. Instead I was back to using normal C# classes, constructurs and the new keyword. Good times. Once that was done I’d write MonoBehaviours that acted as Frontend and synced their visuals with the Backend. This had several advantages. I could design my backend however I wanted, which meant I could make it frame independent and thus determenistic. It worked with ticks instead of time/delatime and I could simulate as many ticks per frame as I wanted. Hell, I could simulate a million ticks in one frame and calculate the profit of a day in miliseconds, without bothering about the expensive cost of creating MonoBehaviours. Another advantage was the forced decoupling from logic and visuals. All of the calculations, creation and destruction of resources etc. happened in the backend, which didn’t even know of any frontend. And thus the third advantage emerged, which I considered to be more important than it actually was. I could change the Frontend, which meant at any point in time I would be able to switch from 3D to 2D if I wanted, without risking changes in the core functionality. This is great, but honestly… who switches the style mid production?
Of course it wasn’t all bloomy. There were downsides. One of them were the synchronization nightmares and reimplementation of the same functionality. The backend can create a lot of resources, the frontend renders a lot of resources. So were you’d usually be done with 1 object pool you will now use 2 object pools. Then comes the tedious task to create a visual representation of the resource that gets created in the backend and then connecting the resource to the target. Because you have to destroy the visual representation if the exact resource in the backend is destroyed. Same when you rotate a tile, destroy a tile, etc. It gets really tedious. Also, if you play the game and a resource disappears or anything else happens, you don’t know if the backend or frontend misbehaved.
This topic honestly deserves it’s own page. But first I have to dig the grave for Factory Line. RIP in peace.
ayellowpaper 