Ideas.. hmm:

As for editor improvements, you can gain some ideas from: http://www.youtube.com/watch?v=fNvtiKNQm6c e.g. after 50 seconds.

- for people who don't like remembering hotkeys, buttons at the top (like in the databrowser) are faster for switching modes etc than drop-down menus.
- a new GuiObj "Ribbon" (similar, but not as cluttered/confusing) as Office 2007+ which selects different modes, and sub modes.
- ribbon means you only need 1 click, and it stays open (unlike drop-down menus) on the relevant grouping of items. I know that overlay windows do this as well, but they're not centrally contained, and thus messy/unnaturally mapped.
- in the Ribbon stuff like "Add Object" "Add Mesh" "Edit Object" "Save Object", with highlights showing what hotkey it is (the insert key, to add objects? o.O).
- migrate everything to the ribbon (no more window pop-ups to change settings).
- Please improve the cameras, the current controls work - but they're very unintuitive, something like 3dMax (not zBrush, or Maya) - don't waste right click on inverse left click - use ctrl/alt/shift for that - right click can give you more control of the camera.
- a new theme, professionally made, with default animations/transitions + icons on the ribbon.
- more feedback drawn to renderer, e.g. WriteMessage(Str msg, UInt displayTime = 1000); WriteMessage("Could not load mesh, file not found!");
- custom realtime profiler (drawable in-game - with graph GuiObj also accessable to use in games) - WorldSize/AreaSize/MemUsage/DiskAccess
- right click sub-menu "Add Object" "Edit Object" etc. - or an icon-based ring menu instead of traditional pop-up rectangular-menu (better for speed). - e.g. typically it rotates the camera, but shows ring menu dependant - e.g. if you right click sky, you get "Add Sun" "Edit Sun" "Edit Clouds" etc.

Is there any chance that the terrain painter etc could be modularised into EE::Edit such that we could just call it and edit terrain in our own game? Would be fun to have stuff like writing on the wall, or have more in-game editing functionality/tutorials which explain such accessible. If the ribbon (above) was used - having access to this in our games would be awesome. "Programmable World Editor" could still exist - you could just give them source access to the ribbon, and others not.

+ many many more...
Hope it goes well

Those are some very good ideas Chris, I think its a good idea to bounce ideas off other engines to improve make essenthel better. Not trying to change the topic, but does any one use modo or tried the latest version modo 501?

http://www.benzinga.com/press-releases/1...e-modo-501

Heard its easier than Maya & the newer version has better tools for game development.

---

Apparently Modo 501 was just released today, so I doubt anyone has tried the latest version. The article mentions SDK support;

"Software Developer Kit (SDK): Improvements to the modo SDK enable third party developers to introduce new items and tools into the modo workspace. Luxology is working with leading developers to create a new generation of plug-ins that will extend modo even further."

I think it would be cool to see some plug ins/compatibility with esenthel. (If possible)

Would anyone else like to see this on the roadmap?

(12-16-2010 12:09 PM)Esenthel Wrote:  And after that, adding the visual scripts support with some new game object classes - my goal is to make more things controllable/programmable from the editor itself, so you can make simple stuff without using the c++.

The Visual Scripting and GUI Editor integration looks a really good addition to the editor, but are you thinking about removing funcionallity from the C++ coding and adding some funcionality exclusive for Scripting coding? Or all funcionality implemented with Visual Scripting could also be done with the normal C++ coding?

I don't know yet how I'll do this because I still haven't brainstormed about it much.

There are few ideas:

1. keep codes only in c++
but in the editor allow to visually specify to "call x c++ function on y event"

2. enable some form of scripting of available solutions, like LUA, or something else

3. write custom script interpreter

4. other..

for the moment I think the most sensible is approach #1
or #3 as long as it will have only simple commands.

Esenthel, here's my proposal.

We definitely need approach #1 to be available, in my opinion. The game demo I created used this approach in a custom editor I developed solely for this very purpose alone. Without it, it would have been next to impossible to have any of the gameplay that I did have in the game. At the very least, it would have been much, much harder to accomplish.

The downside of approach #1, however, is that it requires you to rebuild the game every time you add, edit, or remove a function. This is where approach #3 (or perhaps even #2) would come in handy. With this approach, you can have real-time results, meaning that if you edit a function, no rebuilding is required and you instantly see the result. This is very handy for when you need to simply tweak a variable, such as the friction of an object when sliding over ice compared to concrete. It saves you from having to rebuild and restart the game completely over and then having to run back to where you previously where (which could take a while), only to find out that the friction still isn't set quite right, forcing you to redo the entire process all over again. It adds up to a lot of wasted time.

I say we need a mix between the two. Maybe not a full-blown scripting system, but at least a way to visually specify to "call x c++ function on y event" as you so put and a way to see real-time changes of custom parameters (something similar to saving/loading a game but after loading, the new values of custom parameters are automatically applied).

Here's a step-by-step process of how it could work:

1. Create a struct using C++ like normal that assigns custom parameters to variables (like in the Custom Parameters tutorial) that will later be used inside of your custom function
2. Assign that custom function to run when a certain event occurs on any object in the editor - the custom parameters used in that function are automatically detected, added to the object if not already present, and assigned default values
3. Play the game using the editor
4. Get to the point where you are going to test the custom function (perhaps you could also start directly at a certain spot on the map instead of having to start where you're player is at)
5. Save the current state of the game
6. Continue on so that the custom function executes
7. Tweak any of the custom parameters if need be
8. Reset the state of the game to the state where you saved it in step 5, with any tweaked parameters being applied
9. Redo steps 5-8 until the parameters are set the way you want them
10. Rebuild the world to save changes
    

This will probably need some refining, but the underlying basis is there. It needs to be so that custom functions (or scripts) can be applied to any class with a base class of Obj. Also would be useful to be able to have the editor differentiate between the custom functions so that only the functions that work for a certain ObjType will be assignable to an object of that type (so any functions related to the player can only be assigned to objects of OBJ_PLAYER, for instance).

Obviously this is not much in terms of a full-blown scripting system, but overall is still very useful. Perhaps this could just be used as a starting point and then expanded upon until it is a full-blown scripting system in the future.

I agree that #1 is a good choice. I have no problems editing C++ and recompiling. Code written for EE tends to compile very fast. I think I would get more use from this option than the others. Mind you I'm not trying to build a MMORPG like everyone else wants to...

I think #2 would be very powerful, but would add some bloat to EE. i.e. another compiled library added to the engine.

#3 would probably take the longest to develop as you have to write your only (simple) language. The advantage would be that you (i.e. Esenthel) would have complete control over its direction. The scripts internally could also run as fast as native C++ if it was essentially just using C++ functions under the bonnet. As opposed to a slower interpreted script like Lua.

Nice video.

Just noticed that the information in the devmasters about Esenthel Engine is outdated. Probably you you should update with the last greatest features added

From the perspective of a C++ coder working on a few small projects...

I strongly believe that the engine should remain C++ focussed as in option #1 above. One of the most attractive things for me about Esenthel is that it is totally general purpose and the logical control remains in one place - the C++ source which is easy to debug and manage.

I have been put off several of its competitors because they have become overly script focussed which for me presents the following problems...

1) It becomes necessary to include a shed load of infrastructure scripts with your project that came with the engine that it now depends on to work regardless of if you use them or not. This is a huge pain for small projects. I am not trying to make the next Crysis-a-like or WOW so this is more of a pain for me that it would be for others.

2) Your logical control over entities now lies in a potentially unlimited number of places. Logic is now split between C++ (or whatever the main implementation language is) and the scripting system. This has the potential to create a debugging nightmare.

3) You have effectively just transferred control of a large portion of potentially critical code away from the coders and into the hands of non-coders. This is very helpful for level designers and artists that want to quickly get their weapon pick-up rotating or whatever but what if an inexperienced scripter introduces a script that creates performance issues or crashes?

I accept that somebody that doesn’t know what they are doing can do far greater damage in C++ than they generally can through script but I am working on the assumption that each game project has dedicated and experienced coders on board specifically for this reason.

4) The more engines get script based the more I see them become overly focussed on particular game types limiting the core flexibility of the engine. "Yes you can do anything but you have to reimplement all our <insert scripting implementation> scripts first..."

With regard to option #1

I really like the idea of exposing C++ implementation to the world editor on a simple event base system.

How about something along the lines of built in Game object classes like "Trigger" and "EventDispatcher" where "Trigger" represents the capability to activate an "EventDispatcher" on certain conditions and "EventDispatcher" contains a list of the c++ functions to be called on particular objects when activated along with a reference to the activating trigger.

That would make rigging switches etc really easy but keep control in the C++ domain. For example..

I could implement a class "RayTrigger" that extends "Trigger" and activates upon being hit by a raycast. It would link via an object property set up in the world editor to one or more "EventDisplatcher" objects that are linked to one or more "SwitchableLight" objects that get their "switch()" member function (or whatever else I have chosen to expose) called. This would provide an "implement once use everywhere" functionality for key game components.

One of the nice things for me about Esenthel is it is extremely flexible and I can see how I could implement the above functionality as it stands now. Sure it would be good to have it built in but right now I can do it how I want it. I really hope that whatever functionality is included for scripting - visual or otherwise - in future versions has the ability to be switched off and that the C++ side of the engine doesn’t get put on the back burner as I have seen elsewhere.

EvilNoodle

If you're thinking about LUA, you might want to look at pike (http://pike.ida.liu.se). I've used it for a few project and it's really neat. The syntax is very c++ like. Contrary to LUA is it is also object-oriented.

One disadvantage to me was that I could not get it custom-compiled on windows. There is a binary with headers, but i had written my own MIDI library for it on Linux and would have liked to be able to use it on Windows too. But then again, Esenthel is a much better programmer than I am, so perhaps that wouldn't be a problem for him.

The community is also very responsive, and a Swedish university is backing the development.

I agree with EvilNoodle. The Engine should remain C++ focused and thus I side with idea 1 for now.

The triggers are a good idea as well.

Nice UI improvements in the recent release! I hope it continues to improve like this

Thanks!

Some ideas were inspired by prototype made by user Auruk, as seen below:

WOW that looks awesome!

That is really pretty!

I wish you didnt remove the gui Changed() function though.

(12-20-2010 06:14 PM)Zervox Wrote:  I wish you didnt remove the gui Changed() function though.

I removed it because it could cause problems when scanning for "changed" inside other Gui object update virtual methods, and there the order of objects update, could determine that changed would be sometimes detected, and sometimes not. Anyway, 'func' is much more safe.