Högni and Amy's game project

Thought in deed

Posts Tagged ‘Game Design

Behave your trees

leave a comment »

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.

Written by Högni Gylfason

20.07.10 at 19:16

Ogre3D and ShaderFX… Living in (almost) perfect harmony

leave a comment »

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

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

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

Diffuse shader settings

Ambient 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 🙂

Written by Högni Gylfason

26.09.09 at 13:21

What is the best way to run physics on a client server architecture….

leave a comment »

Do I run updates from the server into keyframed objects on the client?

Do I run updates from the client into keyframed objects on the server… The problem as far as I can tell with keyframed objects is that they have infinite mass when other things collide with them, and thus when client actors run into them on the client side they would have no effect on them, while the client actor would stop dead and/or be moved by them..

The solution thus seems to be that the client actor only creates local copies of static objects, e.g. terrain and static containers etc, that are keyframed during animations… That seems somewhat limiting though, as keyframed animated containers would need keyframe definition files… that might be possible without too much problems perhaps… So the sequence might go like, client has static geometry and a character controller. The character controller is replicated to the server as a keyframed mesh and thereby affect the environment with infinite force, but the client only receives position updates for world objects for use in graphical form with no physical manifestation.

It’s obvious from experimentation that the character controllers can’t reside on the server, the jerkiness would drive local server players nuts in short order, but they have to affect the environment in some way…. I should continue that way, basically having the client take care of the movement of the character, and sending position updates to the server each frame, keeping the server completely and absolutely separate even when running as a separate thread in the same application instance.

Blocking calls from the client stopping the server is not acceptable. I guess I could let the server run and wait for each frame to finish, locking the client meanwhile, but no, that’s not acceptable really… Should it send velocity updates? Good question, I might as well, an additional vector is not really a great deal of extra bandwidth but I don’t see what the server is gonna do with it really.. It doesn’t seem to make sense really, as the server will check each update the last position of the character and calculate velocity from that. It might prevent the shit from flying around if the character misses a few frames and suddenly updates and gets a huge velocity, but that should be solved from timestamps on the last updated time thing I’ll have put on the server side character tracking information struct in any case.

I guess I’ll go whatever way I go.

Written by Högni Gylfason

17.07.09 at 18:54