LE C# Scripting Project

[Rick]

This will be the main thread where I update the status of scripting with C# in LE. I was able to the basic idea working without any LE code. My goal is to make a very basic editor that allows C# scripting where the C# script is compiled and ran in the editor live when the file is saved. I plan on having some kind of mechanism to allow for running the script live in the editor and/or both in editor and when running the game.

 

Don't turn that dial!

[Rick]

I'm going to call this editor/engine 'Lee'. Which stands for Leadwerks Editor/Engine. I'm going with the spelling of Lee because that happens to be my middle name. Spooky huh

 

So anyway, this is going to be a little like how Unity works. Some things will be slightly different, but the general idea is the same. Note that this is a game structure system. It will not give you access to any sort of int main() and will have objects with a predefined structure for people to use. It should however not be restrictive in anyway. You will be able to do full object oriented programming. Anything C# can do, this will allow.

 

A little about how this will work:

 

1. The scripting language will be C#.

2. A script is compiled every time it's saved and will give real-time script error feedback for easy debugging.

3. Everything will start from a base game object, which will basically be a pivot. You will build on this object to make what you want. Add any number of scripts or models or sounds to build a game object.

4. Prefabs will be supported (it has to since building objects from scratch all the time would be annoying)

5. You attach scripts to objects. In the script you will define a class that derives from the LEScript object. This provides many virtual methods that the engine/editor will call automatically and where your logic for that object will go. You can also create scripts that are just normal classes that you can use in other scripts.

7. One of the virtual methods will be UpdateInEditor() which will simply return true or false. By default this returns false if you don't override the method. This determines if the script methods are ran in the editor and game mode or just in game mode. This gives the scripters the ability to make real-time objects in the editor or objects that only run when in game mode.

6. The editor will come with pre-built prefabs. The first of these will be a Cube & SpotLight, and we'll build from there. Once the core structure is in place it's just a matter of adding LE objects as prefabs.

 

Here is an example of how the SpotLight prefab will work. The SpotLight will basically be an empty game object with 1 script attached. The empty game object gives the spotlight position, rotation, & scale. The script that'll be attached to it will define the UpdateInEditor() and return true. In the Initialize() method is where it'll use LE code to create a spotlight object. It'll attach the LE light object to the game object. This basically sets the position, rotation, & scale to the game objects & makes the game object the LE lights parent so the light moves with the game object. The Initialize() method is only called game objects in a scene that have an LEScript object attached to it. All the prefab setup is done on the project view and not the scene view. This SpotLight object however will be already setup on disk and just read into the editor.

 

This leads me to the directory structure. I'm thinking of the following structure to store prefabs.

 

Any folder under Assets will be automatically added to the editor on startup. So if someone creates a cool pathfinding library, they can follow this structure and people can place their folders under Assets and it'll get loaded on each project. If a person didn't want it to load automatically on every project, they can just add a library asset folder into individual projects they have.

 

Lee Directory Structure
Lee
	Assets
		Leadwerks Assets
			Prefabs
				Lights
					SpotLight
			Scripts
				Lights
					SpotLight
			Objects
				Lights
					SpotLight

 

 

A good portion of this design is already working in test projects I have. I just need to get the embedded LE control working the way I need it.

 

Once this is in, it lays a foundation for getting flowgraphs going.

[ZioRed]

This would be interesting if the standard Editor doesn't like. For the embedded control I tried to load a simple scene and some meshes and it seems to work when Framework is not used. The reason it fails seems to be the LUA object initialization in the method Framework.Initialize (if I pass FALSE to not enable LUA then the scene and the model are shown when calling Framework.Update + Framework.Render).

[Rick]

That's perfect as I won't be using LUA for this anyway. If you passed false did you try the stats to see if they work?

[ZioRed]

No success with any debug information (Debug.Entities, Debug.Physics, Framework.StatisticMode), unfortunately the control seems to lack of many useful things (see the other post, I reported also a problem with physics in a scene).

[Rick]

That's not good. This has been an issue for such a long time. What are the issues around getting LE to draw on a .NET control?

 

I'm almost getting to a point where it's probably easier to just make 2 programs. One for the LE viewing and another for the editing tools, and just use local networking between the 2 to communicate. This would probably be easier than trying to get LE into a control. I might play around with that some.

 

That actually might not be a bad idea anyway, since the LE window part could act as the actual game without the other tool windows.

 

Or I might actually be able to plug into the other programs domain and just make calls back and forth that way.

[Rick]

Documenting a design for holding assets.

 

LeadwerksAssets.assets (sqlite db)

=================

LEElements - Table

ID = int (the id of the element)

type = int (script, model, sound, etc)

name = string (the name of the asset)

location = string (where the asset is located)

 

LEObjects - Table

name = string (the name of the asset)

elementID = FK to the LEElements table

 

 

Project.assets (each project gets it's own sqlite db)

===========

LEProject - Table (describes this project)

LEElements - Table (any elements specific to this project)

LEObjects - Table (any objects made specific to ths project)

LEScenes - Table

 

 

Lee.exe - This is the editor and when working with projects you use this. Lee

automatically opens Engine.exe and talks to it to put it into editor

mode.

Engine.exe - This is the game engine. Lee.exe opens this and works with it when

editing. If you just pass the .assets to it, that's how you get

your game to run. Without Lee talking to this it'll start in

game mode.

[Pixel Perfect]

Haha.. good on you Rick. Nice to see you yet again have the courage of your convictions and work on bringing something you're sold on to fruition. Good luck mate!

[ZioRed]

I'd work with XML file to store rather than force the user to install any database engine (MS SQL Server, MySQL or SQLite), since it works good with serialization/deserialization.

 

If you go on the way of network communication I suggest the library Lidgren Network for fast UDP implementation, but the best for usability would be the all in one program of course.

[Rick]

Thanks Pixel. If anything it'll be interesting to see if I can get this structure down and working. I'm going to take a different approach at how the editor will work. Instead of embedding LE inside a control I'm going to have that part as a separate .NET project where it just makes the window. Then I'll have another separate .NET project as the project tool. Using .NET I can communicate between both programs using .NET Remoting. So when I add something to the scene in the project program it can communicate to the LE window program and actually add it. If anything this will be a good learning experience on .NET Remoting

 

I'd work with XML file to store rather than force the user to install any database engine (MS SQL Server, MySQL or SQLite), since it works good with serialization/deserialization.

 

If you go on the way of network communication I suggest the library Lidgren Network for fast UDP implementation.

 

A SQLite DB is just 1 regular file. To use the library is just a dll. There would be no install for the user. It's all self contained. I just prefer working with databases and I find it easier to just write a query to get information.

 

As far as the communication between the 2 programs I plan on using .NET remoting to talk between the 2. They say it's faster than local networking. Plus it's something new I get to learn in the .NET world.

[VeTaL]

My goal is to make a very basic editor that allows C# scripting where the C# script is compiled and ran in the editor live when the file is saved.

Very-very interesting stuff, good luck.