In the last couple of months I had a lot of spare time (thanks to Covid)
I have been working on a C# cross platform game development framework .
Basically it’s updated C# bindings (using UrhoSharp binding tools) for Urho3D .
Currently runs on Windows,Linux,Mac,iOS,Android.
No dependency on Xamarin.iOS or Xamarin.Android .
First class Visual Studio Code support on all 3 platforms Linux,Window,MacOS (autocompletion , debugging , Mobile deployment for iOS and Android)
Why I did it ?
Because I can
And I wanted to check how much effort would it take to embed the Mono runtime into Urho3D.
It was quit challenging but I am quite happy with the result.
it is still W.I.P. and I don’t know yet how much time will I continue to invest in this , it all depends on the feedback I will get from the games development community and my interest in this.
Not right now
I looked briefly into UrhoSharp’s UWP implementation , so in theory it should be possible but will require some work , I can’t provide any estimate at the current present time .
My current objective is to stabilize it first on the 5 supported platforms before trying to add more platforms .
Right , the package contains all the required scripts
And precompiled binaries.
The source code is scattered over several repositories.
I provided all the links to the source code in Github
Just read the Readme file carefully.
The only thing I didn’t provide yet is how to build and assemble this package , which is done manually.
This is still an ongoing development and the structure of the package might change .
Once I will be satisfied with the end result
I will provide an how-to to build it.
Thanks for the feedback
There are still issues that have to be resolved
Such as project size which I find it to be unacceptable , Working on reducing it .
Android AOT support , for now only supports JIT (currently only iOS and Desktop support AOT)
Maybe UWP support.
Some annoying bugs that have to be fixed
And more goodies later …
Reduced project size from 440 MB to 58 MB (18 MB for Assets Data/CoreData).
One will have to call “configure.sh/configure.bat” once (or it will be called transparently once a new project is created).
This script should be called every time the Urho.Net folder is moved to another destination .
I added a new VS code Action : “Shift+Ctrl+P Clean” (Shift+Command+P Clean on Mac)
Will delete/clean all the folder/files that were generated during the build process (Desktop/iOS/Android)
Are you intend on making working on engine any more approachable? Working on a complicated project it is inevitable that one will have to modify engine to add features. Seem like not only adding stuff to engine is complicated, exposing new functionality to C# is also a major obstacle.
Just yesterday I added new functionality and a new sample that reflects it. @Lumak’s OffroadVehicle Sample in C# (see link bellow).
One will have to use the latest Urho.Net branch to check it.
Currently I am writing Hot-Reload sample (I am very eager to know how it will work).
Frankly I don’t know what are my next plans .
I decide what to do next after my morning coffee , just trying to enjoy the process .
I wrote some other working solutions , see below .
I decided to halt although other game dev teams showed some interest in one of these solutions.
Hashlink runtime integration
(Some other game engine dev team showed some interest in this one)
This is hardly a fair comparison. Unity is far more complete than any opensource hobby project will ever be. And yet, while only a fraction of unity users have source code access, majority (again im talking about commercial projects that are not of irrelevant size) need it. Internet is full of “unity this”, “unity that”, “unity but stalled our progress” etc etc. Those people would be perfectly happy fixing bugs they encounter themselves, but they can not. The fact that they can not does not mean they do not need it.
Basically what im saying is that a convenient way to develop entire codebase is paramount to the project success. Unity is so popular for a reason - it drastically reduces iteration times. Scattering codebase across multiple independent projects, where final product is stacked on to pile of binary artifacts, some of which need generating on a specific operating system is opposite of low iteration times.
Awesome! I can share how i did it. Nothing spectacular really. All you do on hot-reload is:
Unregister factories that create objects backed by C#.
Load new .net assembly.
Register factories of types from the new assembly.
This still has a minor memory leak as we do not unload out of date assemblies. Flax has custom patches for mono to do that. I read that .net core is getting this functionality officially as well. I plan to investigate this when .net runtimes used on all platforms (including mobile) support this. I suspect this will be with .net 6, when it is ported to mobiles, but im not certain.
P.S. To avoid file-in-use issues you should never straight-load .net assembly produced by compiler. Instead this file should be copied, and also patched a bit to fix .pdb path so debugging works. Then load a copy. When original file updates - make a new copy and do the same. If you would load a file produced by compiler, you wont be able to update code and recompile as file now is in use and remains such for the duration of application execution.
Thanks for the tips .
Yes I am aware of locked dll file issues .
Basically in my implementation I am loading the source file into memory and compiling it using the the Roslyn compiler and using the generated assembly to instantiate the component .
I load the source file of the modified component
if compilation succeeds , go through all the nodes in the scene that contain this component
– remove old one , instantiate new one and add it to the node.
It supports only Desktop (Windows,Mac,Linux)
My Hot-Reload sample implementation can be found in the link below (must use the latest Urho.Net main branch)
P.S. Flax is an good example on what can be achieved by 1 person (after 8 years of development)
I know that there is some hype around it but I don’t think that it is in any way
posing a threat/challenge to any game engine because if its licensing terms .
More Demo Samples (verified on desktop and mobile , at least most of them)
Also Updated Urho.Net , in sync with my own latest Urho3D master branch.
Added support for HDPI on iOS Metal graphics backend
(In VS-Code it’s “Shift+Cmd+P , Run Action , ios-deploy-metal or ios-build-metal”).
If you try them , make sure you are using the latest Urho.Net master .
Every time you update Urho.Net , first make a clean build in your project
(In VS-Code it’s “Shift + Ctrl/Cmd + P , Run Action , clean” )