Show HN: A friend and I spent 6 years making a simulation game, finally released
More than 6 years ago, me and my friend from university were playing around with an idea of making a game we always wanted to play. We worked on it on weekends but the progress was quite slow, especially due to so many dead ends and wasted effort.
Eventually however, we solidified our direction and decided to take the risk to resign from our well paid SWE jobs and work on it full time. It took more than a year but yesterday we have finally released it on Steam: https://store.steampowered.com/app/1594320/Captain_of_Indust...
I am still not sure if this was a good decision financially, but unlike in a corporate environment, I am so much happier working on a product that I can put my love into and see people enjoy it, see my direct impact, and be able to make big decisions (although this also adds a lot of stress).
I also quite enjoy the added SWE challenges. I had to write so many complex algorithms (path-finding, logistics, serialization, ...) and optimize things down to bits (shaders, compression of in-memory data, ...) that were rarely required by my corp job.
Anyhow, this is getting a little long, feel free to ask any questions, I will do my best to answer them.
288 comments
[ 1.5 ms ] story [ 304 ms ] thread;-)
Looks really good. Congrats man. 84% overwhelmingly positive isn’t anything to sneeze at too. The experience must have been amazing. I learned more about computers in developing games that were 1% of what you’ve done. No matter the financial outcome you are winning at nerd life, which is the only life that matters (other than to your spouse your family and friends).
Notably also, plenty of games work fine under Wine, but Steam client itself doesn't—on Mac.
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.
Eg you would never use /tmp or %USER%/AppData, but call a function File::getPath(TempDirectory) or something like that.
C# has the very Windows-centric https://docs.microsoft.com/en-us/dotnet/api/system.environme...
Unity itself has the Application.*Path properties for some more general cross-platform-aware paths. https://docs.unity3d.com/ScriptReference/Application.html
It's just all those small things that has to be right to make it work cross platform.
In the old days, Java would advertise itself as being cross-platform (Write once, run anywhere!), but in practice, rarely worked that way.
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.
I may be straying away from M1-related issues now, but I've also been seeing widespread Linux-style "why can't I share my screen?"-type problems. Not to mention fear of installing new updates and things breaking. It's like Mac is now the worst of both worlds of old Windows and Linux.
To be fair, I'm not actually a Mac user - this is just stuff I've been observing from the outside.
(+) Impressive performance while staying literally quiet and cool all the time. My MBP's fans kicked in only once—when using ffmpeg. This in itself has pushed the industry forward. We shall see what Intel and AMD have to offer soon.
(-) Apple is obviously, well, Apple. They broke some things that used to work perfectly (or things for which there used to be a workaround). Apple is pushing a vision for user experience, which tbh, is not always ideal, but I get that. For this vision, they sacrifice so many things along the way (see this for example: https://medium.com/@parttimeben/mac-it-just-works-horribly-c...).
Docker has been working well for me. But I agree that some changes (esp. M1) have made macOS feel a bit like Linux.
In short; it started out rocky, but, if you are careful and use only native application so Rosetta doesn’t kick in, it is a phenomenal machine (I have the air); great keyboard, touchpad and screen, great battery life and it stays cool throughout a development day.
If you need x86/64 binaries, then these laptops are not a good choice; wait until there are m1 arm targets.
$1000 "arm board" with impressive power and performance envelopes will get you some market share, especially if the existing ecosystem bends to the manufacturer's will. As they do.
I fully expect the first company to really try and make an impressive risc-V workstation to clean up in that market, especially with people like myself that use higher end consumer parts as servers.
It's just a different software stack (OS, Drivers, Window management/UI, Sound, Networking, file access). It has similar barriers/differences in Linux. It requires extra build/compile pipelines at the minimum and most cases it means some refactoring of your code. In the worst case your gfx/audio/netcode is just plain incompatible (hard coded for a Windows/DirectX stack), meaning you have to rewrite quite a bit to abstract away the differences. This counts even in unity, it just helps here and there with making it cross platform and enforcing an opinion. These guys didn't use much of Unity and seems to use unity just as a rendering pipeline.
People who buy macs tend not to game on them much, they buy it for other reasons. I think people who owns macs and play games, tend to have consoles or even a gaming rig (since they can most likely also afford those to begin with).
https://store.steampowered.com/hwsurvey/Steam-Hardware-Softw...
Right?
1: https://www.phonearena.com/news/app-store-users-spend-more-t...
2: https://timesofindia.indiatimes.com/gadgets-news/iphone-user...
[0] https://www.codeweavers.com/crossover
How did you determine this? Factorio is available for Mac. How did they, and other game developers, justify the work for a Mac port?
[1] https://store.steampowered.com/hwsurvey/Steam-Hardware-Softw...
This project is in C# so that's the first hurdle, I'd guess.
The Uno platform is a third party project that ties this, and more, together to enable building single code-base cross platform apps with native UIs simultaneously targeting Windows/iOS/Android/Web (WebAssembly)/Linux/macOS/Surface Duo.
https://store.steampowered.com/hwsurvey/
Have you tried sending out a survey asking “how much would you be willing to pay for this game?”
It doesn't look like a game where micro-transactions would work either.
Nice trolling.
Linux would be of course on dev's own website, like for Factorio ? (Or Itch.io I guess ?)
I would definitely also just release for one platform, Windows that is, and then consider every platform added after that as a bonus.
https://www.codeweavers.com/crossover
I used to be in the game industry a long time ago, and while I'm no longer in it I still try to work on game in Unity (turn based strategy game right now) with my very limited energy in my spare time. I've been out of the whole industry long enough I don't really even know where to chat and bounce ideas off of other indie devs, or find people to work with. Some Discord channels? Itch.io forums?
About how much did you have saved up to take that year leap to work on it full time? How far along were you? At some point I'd like to make a similar leap but I don't think I have enough cushion built up to do that yet.
Also at one point did you decide the game was good enough to put up on Early Access? Core game loop? Core game loop plus certain nice to have features?
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 :)
Congrats on your release!
Like I'm not in the board game industry, but people in the board game industry are pretty much all on Facebook in certain Facebook groups, and I'm friends with a decent number of them, and get notifications when they post, and then I can comment on their posts, so I've gotten to know several people in the industry fairly well over the years, and hang out with them at conventions or whenever they're in the area.
In comparison, despite having been on r/gamedev on and off over the years, I know zero people through that in person. I know a few game developers still but only because I used to work with them professionally (it's a fairly small scene where I live).
Yeah, I think I'm quite a ways away from going Early Access. Part of me also wonders if it may be more lucrative to focus on VR at the moment, with all the recent headset sales (>10 million Quest 2 headsets sold) and the dearth of new content on the platform.
But my game could work for pancake screens too, and was originally intended for that alone. I am currently developing the game with porting to VR in mind, like trying to keep it playable on VR, and sending builds to my VR headset periodically to make sure things don't crash and framerates are still decent.
This is the "Recall Singularity" Discord server. It's a bunch of factory and sim game developers and fans discussing science, programming and game-dev.
The Recall singularity itself is a space-ship factory game I'm working on part-time. It's one of many factory games being made by members of the server.
I've been watching Captains of industry for a while, it's great to see it released. I hope to see you guys on the discord!
No affiliation, but when I was into gamedev a few years back, the "game dev league" discord was really amazing. There were a ton of knowledgable people in there, like fholm (who I think was the creator of Photon Bolt)
PS. I think I could just watch the excavator digging holes all day.
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!
One of my favorite aspects of Factorio was that the environment constrained your scaling. Grow out too fast and your tech won't be able to hold back the evolved hordes. Build too far away before you can defend it and it you'll be defending too far and wide before you even know it.
@iliketrains May I ask if this game will have an environmental component/conflict to constrain the player scaling various concerns and prevent it from becoming a uneventful sim?
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.
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.
Did you fallow a sociotechnical approach? What school if any?
What about the economics and political things I can found there? Did you think about how this game could work as capitalism? Socialism? Cooperative factory? Having an union among the workers? Having a legislation about protecting industries of something?
What about events like the current container crisis? Or the lack of labor?
However, we are hoping to polish our modding APIs and allow players to add more layers to the simulation like what you described :)
Is the Mac/Linux community still so small that no one cares about it? I'd think with all the noise & competition for Windows gamers, surely there's an untapped market of other OS gamers!
The reason I love a similar style game, Factorio, is that it runs on Mac and other platforms!
[0] https://store.steampowered.com/hwsurvey/Steam-Hardware-Softw...
As a Mac gamer, I find I buy a good number of the "new release" games that show up for my platform if for no other reason that there aren't other games out.
Yes
On one hand it's good thing in the big picture because it's a step in geting games to run sandboxed. For ARM Macs it might be not so good.
But if a developer makes some guarantees about proton support, that'd be something else, actually.
If something doesn't work, you usually just have to report it, it will run through their QA queue to be confirmed, and then handed off to Codeweavers devs they contracted to work on Wine/Proton to fix the bug. It's a bigger hassle than just playing on Windows, but most games run out of the box now.
Native Linux versions of games basically don't happen anymore as they often end up unmaintained, lacking features or are hard to support with a small userbase on often arcane setups.
https://www.factorio.com/download
You would need to test on all platforms, regularly. You would need to be able to debug on all platforms (setting up your ide multiply times). Your bug report has to be more precise.
You also need to either fully use an technology which in theory supports all platforms out of the box OR you would need to develop everything with either multiplatfrom libs or abstract it away and use different implementations underneath.
Alone accessing a file is different on all three OSes.
The best way for a very small team is to make it on Windows and just pay someone to migrate it later if it is already successful enough.
I'm battling to find it now... but I read previously that a game studio found 1. they received a lot more variety in support tickets from people on nix (lots of interesting window managers, distros, etc)
2. A huge portion of their support tickets were from the tiny portion of customers running nix.
This was interesting for me to read at the time because I had played with Unity and Unreal Engine. I found developing for a number of platforms to be relatively trivial - but then again I wasn't trying anything particularly impressive or distributing builds etc.
[0]https://taipangame.com/
This might sound harsh: You had my undivided attention for 6 paragraphs and I have zero clue what your game is like, or why I should care to find out.
While I get your criticism on not clearly describing the game, they are not selling the game on HN, but are instead sharing the experience of developing a side project.
To me, those are the clues that tell you if you should check it out. It definitely got my interest ("hey, what could 2 developers achieve with only 1 year of full time development, and 5 years of part-time tinkering" — apparently, they can produce a great game!).
don't worry too much about making money, else you'll lose your focus
consider this: you produced an asset which is more valuable than just money: 1) IP for the game 2) knowledge from building the game 3) happiness from working on a product people really care about
nobody can take it away from you, nobody can reduce the worth of that asset
what you put into the game is still in the game
also a tip: if you have more ideas, do them now, because later you may not be able to
In the spirit of: https://i.imgur.com/HDG6mdB.jpg
The promotional video of Crane, lifting Crane, lifting Crane:
https://youtu.be/gYpMz63WAjM
I like that you actually mine the stuff in the style of mines you use and the stuff is getting removed visually.
What i find disappointing is the trucks/vehicles not needing any streets. I'm not sure if it would make the game more interesting or not though but that i have to build a bridge over a pipe for the trucks but the trucks just drive through each other... not liking it :D
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...
And bought it already!
The video's had no sound, correct?
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
A few questions:
1. How did you get all the assets for your game? Did you make them yourselves? I also work on games as a hobby, but I'm no artist so I struggle to get things looking as good as this game.
2. How did you decide to use Unity for your game engine? Did you consider any others, and if so, what was the deciding factor?
3. How did you organize your code in Unity, especially on a big, multi-year project like this? I find Unity scenes and prefabs get messy really fast. The only way around this I've found is to avoid using the scene/prefab stuff as much as possible and just focus on doing stuff with code instead. But I'd love to hear any strategies you have.
4. (Probably most related to the art question) How did you decide to make the game 3d? It just seems a lot more difficult than 2d so it seems like indies tend to avoid 3d when possible. And it definitely seems possible for a top-dow-view strategy game.
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.
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 :)
I've been using Unity in a similar way but with Luau (a gradually typed Lua by Roblox) for the API. It's been very educational to treat Unity as a box like this, and I've been making the Luau API very high-level, often following Roblox patterns (more coarsely grained).
As a side-effect of this separation, it's also refreshing to have the option to make everything work with other engines.
That's a pretty impressive budget, there must be hundreds of models in the game.
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.