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 (http://home.aurasoft-skyline.co.uk/changelog-archive/. 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]

hmm i havent pointed this out that direction i wanted...
i thought it as a "quick" workaround till u have a full integration.
so i can start to play with it

doesnt a full integration, lets take monodev as example,require u to have to syncronise a mono project, provide update after compile of mono, syncronise the projects, provide paralell usage of ur editor, make your editor debuggable somehow (monodev debugger will debug the prosess of the engineEditor?)
this is how unity is handling this issue, its working more or less good...uve many monodev or unity crashes/problems ( i hope they sometimes fix em )...often uve to close open monodev cause breakpoints not working anymore..or mono simply ctd when hovering over a variable, you can open the taskmanager and kill the editor, when u run into an endless loop (because u debug the engineEditor running your code, which is now unresponsible)
in short: i fear this will take its time

wouldnt the other way be, much faster for a dirty start

wrap your features (u have to wrap anyway if u want to integrate c#).
supply some events like (OnInit, OnStart, OnUpdate,...) for the engine itself, and maybe the entity.
you still can use all features of the engine (if wrapped) like entities, meshes, camera, scene, terrain
but can do your own code with unittesting/debugging avalible.

i thought that doesnt require new shaders and other internals be done by myself.


example: (sorry i can talk best in code , and its very simplified )

Code: Select all

#include skyline;

// program MyFirst4ChunkedTerrain

// setup the engine and create custom message loop
void main()
{
   // some intits

   Engine.OnEngineStart = OnEngineStart;
   Engine.OnEngineUpdate = OnEngineUpdate;
   Engine.SetTarget(somepanel);
   Engine.RunAsync();
   while(false)  // some sort of custom message queue (i know this can be done better :) )
   {
      WaitUntilMessagesInQueue();
      // to make sure external changes are processed when the engine expects them (somewhere in the updateState)
      Engine.WaitUntilExternalCommandsPossible();
     
      // now let the external application process its message queue

      // tell the engine to resume its work
      Engine.ExternalCommandsDone();

      if(Engine.WantsToExit) break;
     }

}

void OnEngineStart()
{ 
   globalTerrainEntityVar1 = new Engine.Terrain(....);
   globalTerrainEntityVar2 = new Engine.Terrain(....);
   globalTerrainEntityVar3 = new Engine.Terrain(....);
   globalTerrainEntityVar4 = new Engine.Terrain(....);
   Engine.Scenes[0].Add( globalTerrainEntityVar1 );
   Engine.Scenes[0].Add( globalTerrainEntityVar2 );   
   Engine.Scenes[0].Add( globalTerrainEntityVar3 );   
   Engine.Scenes[0].Add( globalTerrainEntityVar4 );
}

void OnEngineUpdate()
{
  if(bla bla)
    globalTerrainVar3.SetHeight(...);
  if(engine.input.GetKeyPressed("Pause")
    engine.Pause();
  if(engine.input.GetKeyPressed("Escape")
    engine.Exit();
}

void OnButton1_Click() // should be fired at legal time, due to custom message queue
{
  globalTerrainVar1.SetHeight(textbox1.text.tostring(), textbox2.text.tostring()....);
}


edit:
oh sorry somehow didnt see this, maybe makes this post useless

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.

[SolarPortal]

Hi Charles, i have given it some thought and truthfully cannot give you a direct answer as we need to research the c# integration more ourself.

hmm i havent pointed this out that direction i wanted...
i thought it as a "quick" workaround till u have a full integration.
so i can start to play with it

its fine, we were not insinuating that you were changing direction, more that we have a firm understanding where we are taking the engine and what we want out of it to end up creating games far easier than other engine. But as we go we try to accomadate all our users wishes.

But from your code you posted, this will essentially be the same apart from the engine start and stop hooks as we manage our own as we do with Lua. We feed from c++ the onInit(), onUpdate(), onStop(), onKeyDown(), onMouseDown() and many more functions straight through as they are all our specific library commands in lua.

We have had to feed all the engine through and create a engine specific api for controlling it all and hooking in with the sceneEntity. At the moment, we plan on integrating c# the same way but as you say allowing certain classes and structures to be wrapped for ease of access in c#. If we come across other information that says this integration is not possible in the way we are doing it or we have to change the way we work it, then we will plan where to head next and we will inform all users of how we are going about it

also, we think the c++ SDK will be around a year or so before it is in.

All your points are taken onboard, and creating a dirty quick implementation usually leads to issues with buggy code and missing abilities. If we are going to implement something then we have to do it properly and cannot cut any corners. Lua for now is a very powerful language and we have created many powerful systems from characters to vehicles and AI. etc...

Hope this clears things up

Q) What specifically are you wanting to do in code? build terrains, move nodes etc... as it will help to understand what feature sets you are requiring for us to help integrate what you need and skyline may already be able to do what you want as we have covered a lot of areas as many of our users will tell There are always more things to cover though lol. Jobs never done hehe

[CharlesWoodhill]

Q) What specifically are you wanting to do in code? build terrains, move nodes etc... as it will help to understand what feature sets you are requiring for us to help integrate what you need and skyline may already be able to do what you want as we have covered a lot of areas as many of our users will tell There are always more things to cover though lol. Jobs never done hehe

To be honest, the main reason is for things i and the engine doesnt yet know or for things i wanna try
this of course doesnt help u

so i try to focus, maybe some issues from the one i made before current prj:
i now expect u know dungeon keeper :
o) UndergroundTerrain: (ala dungeonkeeper, already have done a paged one with pathfinding )
o) Room BuildingSystem: simply give a roomtile a meaning...but uve to parse the adjacent room tiles, what if u connect 2 rooms, what if u split a room(if u del a tile) (done too, needs similar funtionality as the pathfinder for tile detection)
o) AI, i want to run in seperate process, because i fear i need much of power/longrunners for it, and at some point i may need to move/clone it to the server without recoding all for whatever api ,
o) "selection system" (pagesystem needs to handle/support: mouseclicks, raycasts, rectSelects,....) (thats my current prj, but i drifted a bit, ending doing my own paged normalTerrain )
o) some kind of minimap or better a system (like SupremeCommander) that is able to zoom from firstperson to minimap, multipe scenes + "scene windows" are needed then.
o) CampainMap (vectorised provinces, pathfinder, ...) one cool example (europa unversalis 4)

talking about creating game components (minimap, campainmap, scene, scene display component, selector, paging system) not about how to stomp such things into an entity and attach 1000 luas or use other workarounds.

again some thoughts:
o) im not the one really intrested in how a game looks, im ok with basic lightning and boxes (during start and developement) the look can be made last, when uve done your game, or know u can do it) ( oh sh... im tellin this an artist )
o) i always get the feeling when i look at a new "GameEngine" oh the next level/scene editor.
o) i dont wanna make my game not tooo engine specific.. porting my cool class based system(s) to lua is a thing i never will do, maybe c++ but i dont think so
i always capsulate core features like terrain, mesh, model,... into a somwhat more high/general-level class with standard func like (create, update, addItem...) sometimes its simply wrap, most is a wrap+some additional features, some are done completely by myself, some i dont have wrapped because i was too lazy yet )
o) i stumbled upon this engine because i (again) was thinking about to switch to ogre/mogre
o) isnt a minimap just a minimap...no matter which engine?

the one thing i know, making the next fps/rts/platformer game nr. 10456 will not lead to anything, one needs something unique, will the engine support it? when? if supported...is it unique?

[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/