Thanks for your support! I hope you will enjoy the game!
1,303 karma · joined August 25, 2016
We just didn't have time to test things. We need to get Linux and Mac machines and test things thoroughly before claiming official support.
However, we are hoping to polish our modding APIs and allow players to add more layers to the simulation like what you described :)
It's just all those small things that has to be right to make it work cross platform.
Making Unreal rendering layer would obviously be a huge task. Our current solution is overfit to Unity since the separation was done for ease of development and testing, not for support of different renderers. However, the communication between core sim and rendering is mostly based on (custom) events.
Sim runs in a separate thread. Once it is done, renderer can read data (sync) and launch the sim for another iteration. We do this at 10 Hz. In the meantime, the renderer should interpolate all moving objects from state (t-1) to (t) so that movements are smooth (say for target of 60 FPS).
For example, a `TreeRenderer` can listen to `TreeManager.TreeAdded(TreeId id)` and `TreeManager.TreeRemoved(TreeId id)`, and handle rendering of the trees however it pleases. Trees don't move so this one is easy. `VehiclesRenderer` has to also update a vehicle state on every sync.
One can also inspect sim state without usage of events. For example, our debug renderer just draws a picture of a game state by simply looping over all entities.
Reality is of course much more complex. If you happen to own the game, our DLLs are non-obfuscated and quite easy to read with tools like ILSpy :)
Initially, we asked them to do things "realistically", but not looking too brand new. Eventually, we had a good set of models that we could use as a style reference. We had to redo some models that were not fitting the style and we still have a list of models to improve.
One thing that we learned early is that all models need to have a common scale, otherwise details like doors look bad when scaled differently on each model. We have established a metric system, each tile in game is 2x2 m, all railings are 1m tall, all doors are 2m, etc.
Now we have a doc with all our notes regarding style and rules that we share with new artists.
The trailer does have a sound, it's narrated. You need to enable it or just watch in on YouTube: https://youtu.be/U0d7z2sBr-4
That was hard, basically nearly no spare time. For some time I was also working part-time.
> Are you happy with your work work life balance?
Until now there was unfortunately no balance, all work. I am hoping that things improve from now.
> Have you tried a publisher?
No, we have got many enquiries and emails but we were not compelled by them.
> What financial expectations do you have for being able to keep on it?
The hope is to earn a similar or slightly lower amount compared to a SWE job (on average). If this game won't provide enough to pay my bills long term, then things will need to be changed.
> How do you balance family and friends?
This is also hard to balance, and pandemic made it only worse. Lots of online calling and rare visits.
PS: There is a time-lapse recording functionality in the game, I am hoping as players get more comfortable, they will make some awesome timelapses of mining operations!
Also, reality and real industrial processes was a source of inspirations. I have probably watched all episodes of How it's made!
But just for the record, I have probably a few hundred hours in Factorio and ~60 hours in Satisfactory. I also enjoyed Anno series, DSP, Tropico series, W&R: Soviet republic, Factory town, Oxygen not included, Frostpunk, and OpenTTD :)
You can actually increase the ocean size in settings, making way more space if you decide to move mountains and make new space by landfilling oceans.
> My only request would be to make it so you can click on a product and have it take you to the recipes involving it.
Try right-click!
> I also really like the design choice to not have to lay power lines everywhere.
Haha, this was removed due to time constraints. We were thinking to have it introduced in some lightweight fashion, like substations that cover large area, but this is still in "thinking" phase.
1. All 3D assets and music was done by our contractors. All paid work. On average, one model is probably around $500.
2. C#. We both were familiar with it and it is a great language. Lots of nice features, easy to work with, lots of tools, less error prone (looking at you C++), has reflection (very helpful for serialization and code gen), and if you know what you are doing, it can be very performant (avoid allocations, use structs, etc).
3. Great question, yeah, our project is separated to code and graphics. All code is in separate project completely decoupled from Unity. Unity just gets a compiled DLL. Unity has only assets that are referenced by string paths. We also have a separate projects for "data", where all the game entities are instantiated and filled with data. Core project has just functionality with no data. The entire game is one "scene" in Unity, we manage everything internally (like main menu vs. game).
4. We started in 2D, but it seemed "lame", not good looking. Very quickly we started prototyping in 3D and that felt better. Especially the dynamic terrain and mining.
Trucks not needing roads was actually our "feature". You just build things and logistics network will figure things out. This goes hand-in-hand with the free-form mining (also our big feature), since that would be impossible to do with roads.
However, we do hear many people wanting roads, especially later on, it is on our list of potential additions.
Vehicles having no collisions is a technical limitation. Path-finding on dynamic terrain on a large grid, with constraints on vehicle size (small trucks fit under some buildings, large excavators wont) is just too hard to solve with vehicle avoidance. Even with local avoidance vehicles would get stuck too much. One-way roads are probably the answer. Maybe some best-effort local avoidance could be done to minimize it.
PS: I have rewritten the path-finding code 3 times. It's quite complex...
However, it's not always that easy as checking a box. For example some shader optimizations may be specific to DirectX. File system works differently (no "User/Documents" on Mac). Or issues with native libraries.
Our game does work on Linux Proton though, that was a surprise to us.
First, you need people to man your machines and vehicles. You need to first get your workers somewhere (takes time) and also take care of them (food, water, trash, etc). If you scale too fast, you might run out of food and people will starve.
Another aspect is maintenance. Unlike in Factorio, you cannot just spam buildings to scale, because you need to spend materials to maintain your buildings. If you scale too fast, your things will start breaking down (later you can recycle spend products in maintenance to recoup the costs).
Finally, there are a many potential dependency "traps". Scaling too fast and ran out of coal => no steam => steam turbines shut down => no electricity => you built backup diesel generators, fine => now they drained all diesel reserves, oops => trucks cannot deliver food => starvation.
There are many ways how to prevent such death spirals, but my point is that in Factorio (or similar sim games), you cannot loose by scaling too fast. But in COI will. :)
PS: There is air/water pollution too! People will get sick and may die.
The hard truth is that Mac users represents less than 1% of our potential user base and it is hard to justify the time to support Mac. We are planning to revisit this decision soon and see how much effort would it be.
Retarding "the leap", I was around 5 years in before quitting (crazy, I know!). I've had saved up enough for 2-3 years without salary. I have only considered quitting once we had a solid vision for the end-product and a working prototype that is "playable", although lacking content, balance, and some features. Before this stage, we were pivoting every quarter and that was not a good time to make the leap.
The decision on where to stop and call it Early Access was very hard. We were adding things till the last moment, but what helped us was our Kickstarter where we promised a deadline. From that point it was basically "what can we possibly put in given a fixed release date" and it was just a lot of prioritization to include only the most important features. Feedback from beta players helped with this a lot!
The trouble with release is that now any changes must be backwards-compatible, making all coding 3x harder and slower. Any new features now are much more costly.
Good luck to you and I hope to read similar post from you some time in the future :)
Or saving image where Photoshop often does not remember from where the file was opened, or that I have to manually select a file type from a drop down. In gimp, just type the extension. I also like scripting and automating using python.
On the other hand, Photoshop excels in layer effects. In gimp, these effects are applied and you cannot mutate the underlying layer (like change text with shadow and bevel).
Our "team" is tiny, it's just two of us. We've been working on it past 6 years as a hobby project over the weekends. Last year we decided to quit our tech jobs and focus on this full-time. We work with freelancers who do 3D art and music for us.
This could be even cooler in multiplayer where many people could be controlling different parts of the factory, different vehicles, etc. But this sounds like a little too much work to get it "right".
For example, the way how terrain collapses during mining is balanced to make a fun game rather than trying to be super realistic. We don't take into account weather effects (esp. rain). Also, in reality, hard rock needs to be blasted, but we don't have this feature (yet). Refilling of vehicles is mostly automatic, given that they have fuel available somewhere reachable. Etc...
On the other had, similar to other sim games, you will certainly need to think and plan your mine/factory well in order to be successful.