I was getting somewhat familiar with it and then, you know, life happened and I haven’t used it for a month. And now it is completely alien again. Argh. What a bizarre interface

1) Build my own level editor, build an importer, generate the levels

2) Use Blender to build the scene, export all the meshes, export the scene to dotscene format and bring it in that way, using the generic Ogre scene manager

3) Use Blender to build the scene, export all the meshes, export the scene to dotscene format, then import it to octree and bring it in using the Ogre octree scene manager

My understanding is that 3 has speed advantages. Don’t really understand it all yet. More research needed. Probably NOT going to do 1, though - It’d be doable, particularly if I limited myself to rectangular, perpendicular rooms, but it’d be nice to be able to NOT limit myself that way.

More reading, more research.

Things went pretty much bang on to plan - I abstracted out game objects in a class called devilItem, created a manager class called devilItemManager and let that track the movement of the player. When a collision happens, the collision listener sends a message to the devilItemManager which sends the appropriate message to the devilItem, which then reverses the last movement. Since the movements are so small and the updates so often and the boundary boxes (which trigger the detection) are ahead of the camera, the player camera never runs into the wall.

In the pic, you can see the new textures, which need work - their scale isn’t right. The white box is the boundary box for the player - I have it on during testing, but in the game it’ll be invisible.

Next up, I need to be able to generate rooms from a definition file. That way I can build some places to walk around - this particular room really only has the two visible sides - that’s probably not a great idea in space A four walled square room is fairly trivial, but adding portholes, doors, openings and non-rectangular rooms will be necessary.

After that, clickable objects.

However, I’ve got a solution. I have to abstract out movable objects and push their movements (and pan, tilt, etc) into it. And then those movable objects can remember their last move and be sent a ‘bounce’ message to undo it. Should work great, actually - in the case of the player, the collision box is ahead of the camera, so THAT shouldn’t clip. And in the case of NPCs, well, their steering behaviour will use raycasting in front of them, so they should never bump into anything anyways and the bounce is just a ‘just in case’ thing for them.

Still… progress!

I did adjust the starscape jpg so it works better - no artifacting now. A tiny bit of productivity - but there’s lots of non-programming stuff that’s sucking attention right now

-RG

And then, using the combination of the new buffered input and the camera nodes, I got the camera to pitch and yaw based on mouse position - mouselook! Next is movement based on the mouselook, but the tricky bit there is that I have to ignore up/down pitch - player is a human and thus can’t fly. Gets into vectors and quats and it is too late in the evening for that headache.

No screenshot tonight - no visual difference from last night.

Doing some research today, I think I’ve come up with a scene load system that will also help with collision detection, etc. I’m trying to avoid a real physics system - or even a fake one - since the movement in the game takes place in 2d, effectively (no up/down movement), I can store a list of rectangles that players / objects / npcs cannot pass through (including themselves) and use that for local steering and collision behaviour. That’s the plan for npc movement within rooms - I’ll use A* to let them plan how to get from room to room.

Jay from Rampant Games gave me some tips for some 3d model sites. Found a good combo pack that I’ll probably pick up - a good ship model for the freighter Kyle comes in on, a couple of good planets that I’ll need, lots of good textures and computers and such for interiors. Plus a good industrial - pipes, etc - set that I’ll pick up first. In fact, that’s what I’ll do now, go pick up that pipes set to see how it works in Blender

Speaking of Blender - books coming. Coming tomorrow, I hope - package tracking wasn’t that specific, but they are less than an hour’s drive from me at this point.

And now - it launches.  The development effort for “Deal with the Devil” - details on the game coming soon, along with a new look to the site.  Development time will be split between creating the game and learning Blender so I can make some models FOR the game.  I’ll bounce from one to the other to keep myself fresh.

Last night, I did more Blender-learning - working through the N00b to Pro wikibook.  I put a hat on a man, then I put the man on a mountain.  Excitement.  Ordered some physical books, too.

Tonight, though it was all about getting the game programming started.   I’ve settled on Ogre3d as my platform, using the Python-Ogre wrapper.  That’s right - this badboy will be in Python, too.  Tonight started late - I was helping alpha test Frayed Knights - but I got the base directory set up, with the media and plug in components, I built my first material (a night sky for a skydome) and got the Ogre engine initialized.  I based the first go-round on the Python-Ogre tutorial - the macho one, though, the one that doesn’t use the sample framework.  Then I added a plane with a simple stone texture (just a placeholder) and the nightsky above.  Put in a camera and a bit of light and ran it.

No controls yet - the only button that does anything is Escape and that just quits.  There’s some artifacting in the nightsky - I need a bigger picture (though it probably won’t matter in the game itself, as it will only be visible through windows).  It is a bare beginning, but it is a beginning.

And now… to bed