Modern open source game engine

 
Bonta-Kun
Topic Author
Posts: 3
Joined: Wed Jul 19, 2017 10:30 am

Engine is looking great.

Sun Sep 17, 2017 6:44 pm

Hey, I have been following this project for a while now and it looks very impressive! I have a couple of questions though, as I am looking to teach my brother scripting. He is pretty new to programming, so C++ is not for him. Here is what i need to know:
- What is the status of C# scripting? I am moving away from unity, but it is just to nice to work with.
- What is the status of the Editor, I know it has been left behind for a bit.
- Particles. The only real feature missing for what I need. I might take a stab at them anyway.
Depending on what is next, I might try this engine out. Stability is not really big factor for us, as we are not planning on shipping this game. Other than those, the engine is perfect. 
 
User avatar
BearishSun
Banshee Developer
Posts: 64
Joined: Fri Sep 23, 2016 9:52 am

Re: Engine is looking great.

Sun Sep 17, 2017 7:17 pm

Hello. It's been a while since I properly tested both C# scripting and the editor. They were fully (as much as possible for an in-dev engine) functional back then. The main concern are the changes I've been making to the script bindings in the last few months, which I've been slowly upgrading to a new better system, but I have never properly tested all of the ported code. Also features added in the last few months need to be properly tested, and exposed (i.e. new renderer features). I don't expect there are many hard to fix problems, so if you run into anything report it and I'll likely take care of it quickly, or at least get you on the right track. 

Also, I wouldn't be building any large scenes in the editor just yet. Resource formats and encoding haven't been fixed yet, and will be broken at least once before release (meaning you'd need to rebuild the scene when that happens).

I'll be focusing back on C# scripting and the editor soon after I wrap up Mac and Linux ports (very early next year).

I agree particles are an important feature, and they will be one of the first things I will focus on after v1.0 release (if you or someone else doesn't do it before me).
 
Bonta-Kun
Topic Author
Posts: 3
Joined: Wed Jul 19, 2017 10:30 am

Re: Engine is looking great.

Sun Sep 17, 2017 7:33 pm

Thanks for the reply, We won't really be doing any scenes for a while, and even then, they wont be big. I should give the editor a new compile with all the changes, as last time the performance was pretty slow, but I believe that was to do with the post-process not being finished. I am a c# and webdev, and have been wanting to get into C++ for a while now,and your code is amazing, but I will probably start with a little bit of editor work first.
 
User avatar
BearishSun
Banshee Developer
Posts: 64
Joined: Fri Sep 23, 2016 9:52 am

Re: Engine is looking great.

Sun Sep 17, 2017 7:37 pm

For fast editor make sure to compile in Release mode. (Although you will need to compile and run the editor at least once in Debug mode before doing that, in order to perform initial asset import step)
 
Bonta-Kun
Topic Author
Posts: 3
Joined: Wed Jul 19, 2017 10:30 am

Re: Engine is looking great.

Mon Sep 18, 2017 5:41 pm

Hey, another question i forgot to add, how is the data for a built game stored? Is patching / modding setup? Not really important for what i was talking about earlier, but still would be nice to know for the future. Also, as even more of a side note, how hard would it be to move from tiled deferred to clustered forward for opaque objects? 
 
User avatar
BearishSun
Banshee Developer
Posts: 64
Joined: Fri Sep 23, 2016 9:52 am

Re: Engine is looking great.

Mon Sep 18, 2017 6:10 pm

All resources are stored in a standardized binary format, and since the engine is open source it shouldn't be hard to make a modding tool that allows you to edit the resources. Resource format encoding can also be overridden with just a few modifications, so if you wanted to you could implement a JSON or XML resource format, for even extra modability.

Moving to clustered forward should be straightforward for the most part, just moving a few lines around in the render compositor code. However some effects like indirect lighting, SSAO and possibly others rely on GBuffer information. So even if you move to clustered forward you'll probably still need to write most of the GBuffer data, or re-think how those effects work (which would be a lot more work and would likely involve creation of uber-shaders where all those effects are performed in a single shader).

Who is online

Users browsing this forum: No registered users and 1 guest