Engine support .Net / mono

[CharlesWoodhill]

hoi,

another thought:
whenever i started to deal with a new engine or api (directx for example) i made the Scene or viewport onto a panel of a window
this let me acces to the full might of windows gui and all of .net and more...
can u support a dll or whatever, so that u can let run the player on an panel in an c# windowed app?

why? cause u can play around a way faster, especially when not all features are present or far from rapid usage (especially gui)
in .net u have already a cool gui/system, open file dialogs, buttons, lists,.... which of one can make its gui, not to talk about visual studios lovely gui editor, especially when doing some tests or making a isolated subsys, or simply a modding tool for ur game, then existing window system(s) are enuf, u dont need an ingame gui. ( maybe a win32 to skygui converter when u done with the testing??? )

IF u are thinking about, how to integrate c#/.net into your engine,
maybe think how u integrate ur engine into c#/.net/mono
means:
dont ONLY provide some events that the coder can implement (unity for example ( init / start / update, OnGui, OnRender,.... )
isnt it better/much more flexible to create .net/mono class(es) providing the view (and functionality) of ur engine,
which then is usable from out side?
if u too make it possible to create the gameloop outside your engine, then all is possible (be sure to provide a projectTemplate hihi)
BAM!! u support all mono compatible languages / editors / debuggers.... have a cool gui, networking,...... ah .net/mono so rich

of course this is much more platform depended but i think u wont need this sys for the phones its developement stage...

greets,

[SolarPortal]

umm, i feel this would be heading away from what we are producing as a game engine. we can implement c# into the engine which could work along side lua or use c# entirely instead, but making the engine into a render surface would feel counter intuititve when you have the Ogre SDK which you could use Mogre as it is the c# counterpart to ogre. But this means you would have to create all the features which would take years, create the shaders and obviously build a game framework as it is only a renderer.

I dont think we would have the time or warrant the time to do such a task that likely no-one apart from yourself would use as our main target is the hobbyist/indie user.

We do have plans on exposing the entire QT library to the end game and allowing the viewport to be embeddable so a user could create modding for their game if they are exporting on a Windows platform(pointless on mobile lol ), but this is all still running within skyline. Not skyline running within another app. Plus with other powerful engines, they might be better for that purpose.

At the moment, we already have a custom editor plugins system which allows you to create a Qt ui and load it into skyline and program it using lua to do certain features into the engine similar to what you were mentioning but it still needs a few features and hooks into the main renderer for mouse clicks, returning events etc..., if we end up with c# then it will also be programmable in that language too instead of Lua alone.

We plan on expanding this to include rendering viewports to create your own skyline features like the mesh editor viewport.

Custom Editor plugins were only introduced in the V0.9.5: Have a look at the changelogs (. Your version is V0.9.2).

We will probably be using Mono for the c# interface because of its cross compatibility and the fact that we can use it in realtime rather than compiling it down

Someday, Skyline will be turned into a DLL for better project management and for the use of a c++ SDK. Perhaps one day when this is made, you may be able to do what you need with it.

Its a nice idea what you have mentioned, but is not in our general direction.

[CharlesWoodhill]

[SolarPortal]

[CharlesWoodhill]

[StarFire]

Thank you for taking time to share all of your suggestions

We do care and fully listen to our users and try to provide as many features requests as possible. All requests are discussed and as development time is precious we have to plan what can be done in an effective time frame.

We are looking at adding a JIT mono implementation to provide a full C# development toolset and when this is in place we may provide lower level access to certain features as long as they do not interfere with the core system and resource management as we don't want our users to crash the engine as stability is very important. Access to RTT and in certain circumstances nodes, vertex buffer arrays for procedural poly generation and of course the current set of deep commands converted from the Lua implementation. Low level terrain access, shader const params for dynamic shader development to supplement the RTT. This would provide you with the tools to be able to code much of what you mentioned this combined with the current feature set and any requests would provide a rich development environment without the need to be a pro coder.

I hope this helps.

[CharlesWoodhill]

\o/