Star Ruler out Saturday

This is starting to excite my lower cockal regions. Looks great, sounds pretty interesting.

Behave your trees

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.

Unity3D vs. UDK

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!

Sideways Movement

We’re taking a break from VoidEngine development to explore the features and possibilities of the recently released Unreal Development Kit by Epic Games.

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.

Standard material done

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.

BrainHex!

Stumbled on a neat survey by way of RPS.

My results:

BrainHex Class is Conqueror.
BrainHex Sub-Class is Conqueror-Socialiser.

“You like defeating impossibly difficult foes, struggling until you eventually achieve victory, and beating other players as well as hanging around with people you trust and helping people.”

This hits the mark for me pretty well. My favorite game moments all involve defeating the super-hard endgame bosses in Everquest back in the day. Every single MMO I’ve played after that has failed to induce the brainpounding pleasure of those successes.

“Each BrainHex Class also has an Exception, which describes what you dislike about playing games. Your Exceptions are:

» No Commitment: You dislike being asked to complete everything, preferring to pick and choose which tasks you will attempt, or simply messing around with a game.”

This does not ring true at all. I felt I responded truthfully to all questions but the point was that I immensely enjoy doing this for other people but I don’t really enjoy doing it for my own parts, preferring just a patchwork of drops that I’ve gotten incidentally here and there…

Otherwise an enjoyable diversion

Ogre3D and ShaderFX… Living in (almost) perfect harmony

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.

Planet in Max with SFX Panel

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.

Planet in OgreMax Viewport

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.

Diffuse shader settings

Ambient shader settings

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

When will I get old?

I’m 34 today (yay), but as usual it doesn’t seem to confer any kind of new respectability or greater wisdom, despite my graying hair and deteriorating memory. Lets see if it comes along later on in the day.

Ogre3D and ShaderFX

I’ve been using Lumonix’ excellent ShaderFX plugin for 3ds max to generate shaders, and then altering the generated shaders to comply with the Ogre3D  material framework. To say the least this has not been without problems. The main problem is that Ogre3D is designed to be very open as far as the content pipeline is concerned. The material structure is very flexible, but at the same time suffers for it in its inability to use techniques native to shader programs.

A shader program usually follows a set pattern. At the top are definitions of constants and “tweakables”. These are the inputs to the shader program, such as colours, values for specular and gloss levels, texture samplers and more. After these follow definitions of the matrix structures the shader requires to work properly, such as the world matrix, world view projection, view matrix and many many others. Thereafter come definitions for input and output structs for the vertex and fragment shaders. Then comes the real meat, the vertex and fragment shader entry points themselves and their internals. Last come the technique definitions, where everything is woven together.

Most 3d engines read the techniques and apply materials to the objects in the 3d representation. Ogre goes about this circuitously at best. It does not read the techniques at all, but leaves it to the programmer to know the entry point names and then declare shader definitions that are in turn used in material scripts. To add to this, most shaders exported from any shader authoring software do not compile properly with Ogre without alteration. For example matrix multiplication is reversed when multiplying multi column matrices with single column (vectors). The shader declarations need to include the entry point name, the target (vs_2_0, ps_3_0, etc) and the source file for the shader proper. Then you define the bindings for the world matrices to the shader inputs, e.g. wvp -> world view projection matrix. These, in turn, are read by entirely different files, called material files, where you point to the declarations you made in the previous files, called program files.

This process is labourious to say the least. So, I’ve been trying to find ways to automate some of the steps. The biggest hurdle at first was editing the shader files to conform to Ogre’s format. If you’ve ever seen the contents of a shader file, you know what I mean when I say that it is not pretty. Second was writing the shader definition files (.program) and thirdly including it in the materials. I wrote a short python script that cleaned up the shader file for comsumption by ogre, but it seemed a cumbersome way to do things, parsing the code of the shader and then outputting it to a new file. After trying this with a few different shaders, I decided to trash the project and try something else.

I started looking into how ShaderFX is constructed. Without going into too much detail (proprietary software etc), I managed to build a half assed export extension that exports Ogre compatible shaders. Now I just need to get some support from Lumonix to extend the extension so that it generates the necessary material and program files. So far Lumonix have responded well to this project, so I hope they will be able to answer the questions I have raised with them.

Hopefully to be continued.

Need for Speed is back… well, sideways at least

I’ve spent a bit of time lately playing NFS:SHIFT (Shift from now on) and I’ve gone from a stand of “neat” to “yikes”. This game is in fact awfully good.

Before playing it the first time I had seen a few gameplay videos and trailers and was somewhat put off by all the goings on in the interface while driving. Thankfully you can turn all of this off, which I did. There is nothing on my screen but the 3d representation of the interior of the car I am driving. And it looks fantastic. The feeling of driving very fast, braking hard and turning comes back to you in a great way, better than any game I have experienced so far. GTR and GRID do this well too, but this takes the immersion to a new level. I’m playing with a MOMO wheel controller with gas and brake pedals and I feel that this is as close as I am likely to come to real racing in the current technological paradigm.

The graphics are outstanding. The cars look damn near photo-realistic, and yes, I hate using that phrase. You’re aware you are looking at a computer generated 3d representation of the objects in the game, but they look so good and the lighting is of such quality, you just forget from time to time. I was readily  Some tracks look better than others. The real tracks, i.e. those that represent real tracks that are raced upon in the real world, look distinctly better. Spa GP and Nordschliefe (Nurburgring) look fabulous in particular. The conceptual tracks look worse but not so as to put you off in any way. I’ve never personally been to these tracks myself, but from image and footage I have seen of their real world counterparts, they seem to be faithful renditions.

The drawbacks of the game are the gameplay elements that cater to the consoles. These are achievements, stars, points and announcements thereof in the middle of races. Thankfully these can all be turned off, and then ignored when they are presented as part of the career mode, the heart of the gameplay dynamic, but where you cannot actually turn them off. I would have been well off just getting the money and doing the races.

I thouroughly recommend this title to any who are hungry for some simarcade racing. Some say that games like Forza Motorsport and Gran Tourismo are better games, but I’d rather play yatzee on facebook than play a racer on consoles. And I hate facebook. Not yatzee though, that’s cool.

Need for Speed is indeed back with Shift, but not in the way of the last 4 or 5 iterations. It’s back to pure racing, doing away with the pomp and circumstance of open world mucking about and storylines, leaving you with unadulterated joy.