This is starting to excite my lower cockal regions. Looks great, sounds pretty interesting.
I had already started using the good ol’ switch/case statement method to start implementing the AI for spacewars, when I bumped into Behave for Unity3D. This library implements Behavior tree logic in Unity with a nice visual editor. After a few minor niggles, finding workarounds for a couple of bugs and a lot of wrapping my head around how B-Trees really work, I love it.
The concept is so simple and intuitive, once you get past the initial (low) barrier you can be pushing out complex algorithms in no time. When you have your logic mapped out, all you have to do is implement the individual action and decorator code snippets. This fits so well into the Unity style scripting – where there are lots of short scripts – the workflow does just that.
Behaviour trees also integrate fairly well with FSMs, so you don’t have to instantly throw them out. You can have the tree actions change states or alter parameters if needed, maintaining interoperability.
There are other tools out there to create B-trees, but this one for Unity is very much sufficient.
We tried to use UDK.
The GUI editor is pretty good. Graphics are nice. The material editor is great. Asset browser, definate plus.
Scripting engine. Bad. Really outdated bad. Script prefab instantiation non-existent. Bye bye.
We are now using Unity3D
Asset browser is primitive but usable.
Low level integration with asset tools. Native 3dmax conversions. Very nice! Assets even open directly from the asset browser in the art tools or visual studio (for scripts).
Game object component stack. Fucking brilliant. Dragging scripts onto a game object and setting its properties directly. So god damn good.
Shame there is no node based material editor or GUI editor. There is an excellent 3rd party GUI editor available though, so that’s not a problem.
UDK hereby kicked to the curb. Welcome Unity!
The UDK offers a great number of features and advantages of our own engine. Even when we were first exploring into the territory of game development, on of the possibilities we entertained as an engine was UE3, the engine that drives quite a few engines out there. We did not quite discard it, but decided not to use it on the basis of license expense. My desire to write my own also played a part of course.
Now that the UDK has been released for public use, the deal is too sweet to ignore. The editor is fantastic, the content toolchain is well refined and the engine offers possibilities of extension that are very tempting to utilize. Features such as the lightmass lightmap renderer and the Content Browser are welcome tools in game design and development.
The major downside of the engine is UnrealScript, the integrated scripting language. It bears some resemblance to Java and C in it’s syntax, but has some faults as I perceive them. It’s object instantiation and reference system is obtuse. A lot of functionality is reserved to native classes, i.e. classes written in C++ and hidden within the engine.
My major issue with it though, is the difficulty of implementing procedural streaming levels. The engine supports streaming levels out of the box, but access to the functions that deal with setting up the streaming functionality is wrapped in native code, and does not seem to be accessible in script. If this turns out to be the case, the engine does not support the one inaliable feature that we base our entire idea on. Procedural gameplay generation. This includes the placing of rooms and static content, dynamic spawning of monsters, loot and other dynamic actors.
I’ll continue to dig around in the (not so well documented) API, but it’s not looking good so far.
For all practical purposes I consider the work I’ve done on exporting the standard material type from ShaderFX to Ogre3D readable format, complete.
It now exports correctly all the subnodes and lights and the calculations all appear correct now, including advanced functions like projection mapping based on vertex positions, alphas based on vertex colors, ambient occlusion, diffuse, normal and more.
I’m now going to proceed to create an exporter for the Glow and Subsurface scattering materials, as those are the ones I see us needing in the near future.
Even though this has taken a lot of time to implement I think it will save us untold hours of work in the future. This applies even if I leave it standing at only the standard material.
Unfortunately I’ve not gotten any further response from Luminox on this matter, so I don’t know if this work will ever reach the public. I can’t release it on my own as it is proprietary software that I’ve made extensions on…
I’ll update on this status when I can.
There is some progress on the exporter for Ogre in ShaderFX. I’ve almost finished the StandardMat support. There are still some niggles, like light projection not rotating with the object, but I think I can figure that out.
This is the material as displayed in Max in mode CGFX. The normal is scaled and UV Rotated with time input and the diffuse texture is plugged into the ambient socket with a modulator as well as the diffuse socket.
This is the same object in the OgreMax viewport in max. Looks pretty neat. I also tested it in the OgreMax viewer to test the UV rotation and it works like a charm with the time input. Below are the shader settings in the OgreMax material editor panes.
I’m quite happy with it so far. I’m hoping to do the Glow material next, not because it’s next in order of general importance, but because I need it