3 ms·

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
    Awesome thank you for that insight sounds great ! If I had any free time would be a fun project to try to implement the API in Unreal but really not necessary game looks great amazing work!
  - BorisTheBrave 4y ago
    So, just to be clear, you have almost no Unity objects in your scene. The tree renderer reads data from your core game lib, and draws it. Which Unity API do you use for the actual drawing?
cloudmike 4y ago
Very interesting. Like the sibling comment, I'm also curious about your API for this. 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.
digitalmouse 4y ago
Reminds of flashpunk and flixel

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
  Awesome thank you for that insight sounds great ! If I had any free time would be a fun project to try to implement the API in Unreal but really not necessary game looks great amazing work!
- BorisTheBrave 4y ago
  So, just to be clear, you have almost no Unity objects in your scene. The tree renderer reads data from your core game lib, and draws it. Which Unity API do you use for the actual drawing?

cloudmike 4y ago

Very interesting. Like the sibling comment, I'm also curious about your API for this. 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.

digitalmouse 4y ago

Reminds of flashpunk and flixel