Arcs & Circles & Kill Cubes

Level 4 came to me in a flash in the middle of an unrelated conversation with my friend who doesn't even play video games. 
Arcs will progress to circles to rotating elements.  Writing custom sceneNodeAnimators in C++ will be trivial at this point, but figuring out the pipelining of animations from 3ds through maxscript into XML and then kyuplex will be new territory, and bordering on the beginnings of scripting. 
I intend to look into using irr::scene::IAnimatedMeshSceneNode and company first, but I have a feeling that may not behave the way I want. 
Anyway, I feel confident about my ability to continue this "evolving gameplay" mechanic for quite some time, as the lessons progress ++  ; )

kxLight

I'm quite happy aesthetically with the way my newest class looks.  The new kxLight class is a composition of three elements, a dynamic irrlicht ILightSceneNode that actually lights the scene, an IBillboardSceneNode that renders the white circles, and a btRigidBody with a btSphereShape collision shape.  Thus the lights are highly dynamic and interactive.  The player can push them around and see how the scene's lighting will change dynamically.  I have a number of ideas for creative ways to use this dynamic in gameplay. 
Also the class design is a reversion to my original class design, in which they are separate from the irrlicht node hierarchy, i.e. the class does not inherit from an irr::scene::ISceneNode.  More like a wrapper.  But I'm not sure if this change is going to work out.  Feels better and simpler for a number of reasons, but it would mean another major class refactor.  Getting tired of doing that.  Although I am feeling the need to insert a kxEntity class above all my classes that holds the context reference.  All of my classes are calling the singleton kx::getInstance() method to get access to the context.  This is code duplication.  Wouldn't it be better just to inherit from the kxEntity base class which comes with the context? 

3ds MAX as level editor

So tired...  Long weekend of hard work.  I have vastly expanded my maxscript xml exporter for kyuplex.  3ds has become my level editor 100%.  I can design level geometry, lighting, collision objects, entities, and more and then run my script which generates an xml file for each progress stage of the current level.  Kyuplex can then load that file, parse it, and generate the scene, lighting, physics and load entities at run-time. 
The hardest part was getting the Render to Texture working to bake advanced lighting into the diffuse materials of the static geometry. It still needs a lot of polishing, but I finally got the baseline working prototype. 

level3 WIP in 3ds

interesting z-fighting artifact is inspiring; think I will recreate something similar +

lesson one first refactor

added lights to the 3ds - kxExport.ms - kyuplex lesson pipeline (as well as showLights debug bool)

definitely leaning towards 3ds as 100% lesson editor; discovered this handy util: the Container Explorer

MAXSCRIPT!

omg I love MaxScript.  I looked into it, and found a nice little XML wrapper of the DotNet interface written in ms here: simple-xml-library-for-3dsmax

It looked rather easy, and the more I thought about it the more I realized how useful and important it would be to know MaxScript.  Not only for kyuplex but just in general too.  I started learning it, and coming from such a strict language as C++ it is remarkably easy to use ! All those variables defined with no type feels loose, but I love it!
The more I learned the more I could see my level design pipeline from start to finish and so I decided to jump in.  The power and flexibility it will grant to kyuplex will open a lot of doors to some kool levels : )
I've had great success with my first script!  I was able to write an export function that parses all nodes in a 3ds scene and writes an XML file that irrlicht can parse and I can use to load entities directly into a level quickly and efficiently, with more data than just positions.  It can take into account a whole host of data as well as user defined data per node : )

my first maxscript, an XML entity exporter

the resulting xml file.  Parsing this file with irrlicht is trivial and fast : )

level 3!

I'm quite happy with the progress I've been making lately.  The first two levels are rather boring, just introducing the player to the feel of the controls, coplanar movement in level 1 and vertical movement is introduced in level 2.  Level 3 introduces rigid cubes. (At least that is what I'm calling them for now)  Simple, innocuous cubes that are rigid bodies and can be pushed around by the player.  They are just sort of a filler, were easy to implement, but I foresee imbuing them with various properties to add complexity to the gameplay.  It is still early in the gameplay progression and I want to keep the environments rather easy until the player somewhat gets used to the controls, and difficulty and complexity increase. 
The 3ds models are working well as conveyors of positions for entities and basic info.  I'm basically using the filename as a variable to transport entity info into kyuplex.  It is rather ad hoc but it is working for me for now.  It's simple.  Eventually I want to write a 3ds plugin in Maxscript that parses a scene and writes an XML file that kyuplex can parse in the LoadEntity method.  That would be the most efficient way and also I could convey more info.  But perhaps that will wait for version 2.0...
At this point I feel it's more important to keep it simple and continue moving forward >

preventing camera gimbal lock under multiple inheritance

 

Added inherited rotation from the rigid body to the player camera.  This way, if the player collides with level geometry at an angle, or receives impulses from enemy fire, it disrupts your aim and you must compensate in order to avoid disorientation. 
Will have to beta test those parameters to find a happy medium because I'm afraid it may be too disorienting for the casual player.  However this is core to the concept of kyuplex, and an important part of the core gameplay as well; movement in 3d space.  My roommate described it as four dimensional PacMan. 
Took me the better part of a session to figure out where and how to prevent gimbal locking the camera now that it is child to a two-parent hierarchy:

btRigidBody-->camPivot --> playerCam

Furthermore it is confusing because the playerCam inherits the camPivot's rotation through the irrlicht node but the camPivot inherits through the kxMotionState.  Once the rotation of the node is set (in the motionState) the playerCam immediately inherits that rotation, so gimbal lock must be checked just before that.  (in the motionState)