4 ms·

Looks awesome! Congrats on the release, and it seems like you're getting a pretty good reception so far as well. A few questions: 1. How did you get all the a

by japhib 4y ago

Looks awesome! Congrats on the release, and it seems like you're getting a pretty good reception so far as well. 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.

iliketrains 4y ago
Thank you! 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.
- hoten 4y ago
  So what exactly is the utility of Unity in this setup then?
  - iliketrains 4y ago
    It is basically a big rendering library, providing C# APIs for rendering and sound. It also packages all assets, and can be used as editor.
    - mentos 4y ago
      Awesome, I’ve been developing with Unreal since 2014 recently checked out C# support with UnrealCLR it’s very basic but probably enough to create an API between your game code and Unreal. Really curious to know what level of granularity your API is at?
      - iliketrains 4y ago
        Nice! I was not aware that Unreal has C# support. 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 :)
        mentos 4y ago
- devortel 4y ago
  > On average, one model is probably around $500. That's a pretty impressive budget, there must be hundreds of models in the game.
  - davnn 4y ago
    On a related note, how did you fund the development over such a long timeframe?
    - dymk 4y ago
      From the OP, looks like five years working on it part-time while having another job, so presumably that funded it. And then one year of full time game development.
- hahamrfunnyguy 4y ago
  It sounds like you had several different contractors working on it, so what steps did you take to ensure a consistent art style?
  - iliketrains 4y ago
    Yes, multiple, three stayed with us for more than a year and are mentioned in Credits. 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.

by japhib 4y ago

iliketrains 4y ago

Thank you! 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.

hoten 4y ago
So what exactly is the utility of Unity in this setup then?
- iliketrains 4y ago
  It is basically a big rendering library, providing C# APIs for rendering and sound. It also packages all assets, and can be used as editor.
  - mentos 4y ago
    Awesome, I’ve been developing with Unreal since 2014 recently checked out C# support with UnrealCLR it’s very basic but probably enough to create an API between your game code and Unreal. Really curious to know what level of granularity your API is at?
    - iliketrains 4y ago
      Nice! I was not aware that Unreal has C# support. 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 :)
      - mentos 4y ago
devortel 4y ago
> On average, one model is probably around $500. That's a pretty impressive budget, there must be hundreds of models in the game.
- davnn 4y ago
  On a related note, how did you fund the development over such a long timeframe?
  - dymk 4y ago
    From the OP, looks like five years working on it part-time while having another job, so presumably that funded it. And then one year of full time game development.
hahamrfunnyguy 4y ago
It sounds like you had several different contractors working on it, so what steps did you take to ensure a consistent art style?
- iliketrains 4y ago
  Yes, multiple, three stayed with us for more than a year and are mentioned in Credits. 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.