Manipulators, Scripting and Picking.

So tonight I begin working on my gizmo code. I recently found a lost thumb drive that had an old version that I had been working on. Should be nice to use to plug in some of that code into the new version. I will be using and modifying the code from Mindshifter to include the ability to manipulate all objects when in edit mode. Also since the new version of SunBurn should be coming soon I would like to make my editor work only when SunBurn's editor is active. So when you go to edit mode SunBurn's editor pops up and you can manipulate objects. Currently Mindshifter's version uses a pick buffer to choose objects. This requires re-rendering the entire scene using key colors and then testing against the mouse position to see which object is chosen. I think I am going to change this to use ray testing to find the object instead.

Normally, the game will start into editor mode while in development. Then you can switch to play mode with the console when your ready. When in edit mode the physics are frozen and all objects are static, except non-physically animated stuff like models with scripted animation.

I just saw Blit Scripting Engine on Codeplex and it looks very close to what I am wanting to do with my game engine. It is a little to general for my taste, but I would like to have the ability to attach scripts to actors and have the script automatically run every frame. I also want to allow real-time scripting modifications. This could be accomplished by allowing the user to choose to modify the actors script through the console or context menu and that would open the script in a small built in Windows Forms editor. Then when you close the window the script would rebuild and let you view your changes instantly. Right now this is only a goal not a necessity, however scripting is a necessity.

I also need to implement an IPickable interface or something like that to allow for object picking. It won't need to be performance based, but shouldn't cause the editor to slow to a crawl. Once again the whole reason for using interfaces so much is so when version 2 of the editor is in the works I can simply take the code that was good from version 1 and just reuse it. Also that way anyone can take any part of my code and reuse it in there own program.

Interfaces...

A few of the current interfaces being developed in my engine.

In my previous post I stated that my engine would maintain abstractness from the physics engine. Well that was mostly true. I want almost total abstraction from everything but SunBurn (it's quite abstract to start out with). So I started to plan how all the objects would interact in the engine and how to make code that is reusable. Actually all code is reusable, just copy and paste and modify to work. Problem is if you use that method of code reuse you end up changing your original design and have to go scan through all the times you pasted that code to make the change and then figure out why it doesn't work everywhere. Good programmers use Object-Oriented design techniques to isolate code into reusable chunks. C# is no exception to OO design, in fact C# highlights this feature with the introduction of Interfaces. Because C# only allows one base class to be inherited (I know, that sucks), interfaces became a necessary item.
Anyway, I won't go into crazy detail, but lets just say I am using interfaces for as much as possible in my engine. This will allow any class in the engine to potentially perform any action. For example I have decided to include the editor in the game engine. This led me to decide to include an IEditable interface that defines everything an object must implement to be editable. Then when I create my scene object class I can simply implement the IEditable interface and then that object will become editable in the game engine. Then later when I add a light object to make that editable all I need to do is implement IEditable for it as well.

Start your engines...

So I have written a prototype of my basic engine design and now I am ready to start on a full engine this iteration. Above is where I am right now. Below is where I want to be.

A few key features I am shooting for are:

• In game editing - switch to editing mode by using the console.
• Abstract physics engine interface - based on BEPU Physics mostly (see note 1 below)
• In game collision mesh editing and creation - easily add, move, rotate collision shapes.
• SunBurn properties editing in game, including textures.
• Deferred rendering using SunBurn - not going to bother with forward support.
• Neoforce Controls UI - because I don't like WinForms.
• .NET Compact only - Windows and Xbox support.
• Animated textures - (see note 2 below)

And a few items that are on the list, but not currently high on the priority list.

• Skinned models with rag doll physics.
• Partial rag doll physics for skinned models. For example entire model is animated normally except the left arm is actively a rag doll.

 Notes:

1. The reason for abstracting the physics engine is for portability. I want to be able to write a single Save/Load method and have it work without modification even if I switch engines. The reason I am basing my interface on BEPU Physics is because it seems to be the best at the moment.
2. Not sure if I will use movies or sprite sheets, but this is a must.

So my goal is to have a complete engine with a complete game finished by the end of the year. Wish me luck.