PathBuilder part 1

Today I have made sure that my PathBuilder(as I would like to call it) application actually generates the necessary sectors (axis aligned boxes) and portals (clip planes that connect sectors together). See the two previous posts for more info about what this app does.

Now the user can click on a position with the mouse where the path-data generation should start scanning from:


As you can see that the sectors are displayed with some alpha and portals displayed with full alpha and red color(some flickering appears but this is only due to the fact that the portals are placed at perfect alignment to the "sector walls", hence they are called clip planes). The app still doesn't perform accurate collision tests though, so there are still some errors left.



It also saves the generated information to a XML structured file. You can view a full copy of the generated file for the above sample here.

Also, today I've started reading some articles about state of the art AI and found a really interesting article based on the game Fear. Here's the link to it http://aigamedev.com/open/reviews/fear-ai/, this is probably what I will be spending my time on for the rest of this week and I really recommend you to read it if you are interested in advanced AI programming, for games of course.

Follow up

This post is a follow up of the previous post I made.

As I mentioned, there is a new [sub] project on the rise but as of now I can't really tell you much about it other than it will be a RTS styled game.
What I can show you is a few screen shots from a demo that show unit selection:



The demo performs box and single-click selections like in any standard RTS game.
Although currently it doesn't work on the per polygon level, it checks against the objects bounding boxes.
About 30-40 % of the visual aspects and mechanics of this demo is scripted. And don't mind the visuals, they are of course place holders!

Stay tuned for more!

So little time to blog...

I haven't had much time to update my blog the last weeks, the good news is that the reason for that is because I have been completely working my ass of.
I'll try to sum up the progress I made since the last post and show a few screenys while I'm at it.

This is it in a nutshell:
* Solved linker errors (Obviously ^^)
* Helper application for creating binding code to Lua
* Continued expanding framework
* Framework almost completely bound to Lua scripting language, (and most of the core functionality of Ogre and PhysX)
* Ability to run scripts and script code from console
* Added simplified game objects(Scenery, Bodies, Models, and more) , all scriptable.
* Added ObjectFactory for straightforward game object creation
* Simple GUI objects (mouse cursor and images)
* Implemented very easy way of performing ray-scans and per-object selections
* Learned how Ogre compositor(post-process shaders) works and got a Bloom shader working (next will be HDR =) )
* Nailed all memory leaks down (there are a few left that comes from third party libs and will be fixed by their founders)

There is probably loads of stuff that I simply forgot to mention now but all that will hopefully be appear in later posts.


Here's how bloom looks like:



The wipeout-styled ship in the screenshots where made by a fellow student of mine (Gunnar Fors)
Many thanks goes to him for lending me his model and textures!


Last week I also made a application that will help me in a new sub project (more info about this project coming up).
Following this article http://www.gamasutra.com/features/20020405/smith_01.htm, the application steps through a scene of any complexity and returns a set of path-finding information that could later be used to navigate a AI character through a game world.
Here are some screen shots:




The green space are the scanned area and the red boxes is optimized axis aligned bounding boxes (called sectors in the article).
At the moment it doesn't actually perform collision test on the scenery (only simple ray-scans), the small box in the middle will be used for that, and it only operates on the xz plane. Luckily these problems are not that trivial to fix(and will be in the future).

I'll have to continue this post with a follow up, otherwise I'll hit the image limit.

Minor progress

Finally I got a console working, and got rid of most memory leaks when shuting down the application. It wasn't easy though, due to some difficulties with the so called "Overlay" class in Ogre, as discussed in this thread. When manually creating nested OverlayElements in Ogre and adding them to the SceneManager through a SceneNode, the destruction of the elements later can produce hard to find bugs, and (in my case) crashing when destroying Ogre Root. It took a while to figure out, but now I got a simple yet functional console:



And everything written in the console gets outputted to a log file in the .exe directory.
I also added some other stuff but it's nothing visible on screen, so I'll post about those later.

Got the basics running

New update!

This time I've actually got something to render in my application, and also added input system (handles keyboard, mouse and joystick input).
Bellow is a screen shot showing the application running with active physics and some simple camera controls. using W, A, S, D, left control, space and left shift (for speed boost) to move around and standard first person mouse look.



Next step is solving a few memory leaks and continue adding stuff to the framework.

Project startup

It's been a busy ~24 hours, I've just started a new big C++ project using the open source 3d engine Ogre. Ogre is completely new to me and a fresh start to my game development goals. Earlier I was using a low cost middleware engine called 3impact, but since a few days ago the developers stated that future development for the public version had been suspended (link). At the same time as I felt very disappointed it was also the kick I needed to move on to something more suitable. Not to say that it was a bad engine in any way, it did very good on the features it provided but it just wasn't suited to make AAA games.

Now I'm really confident that Ogre will fill in the gaps that 3impact was unable to handle, this is what I have accomplished in the last couple of days:

Setting up Ogre rendering together with PhysX® (Nvidia®) for physics, integrated my own framework that I will continue to expand and add features to while I develop games!


Currently I also have a test-application that uses my framework, but does nothing but initializes a empty rendering window. So the next thing to do is to importing a few models and make them interact with each other.

Blog is up!

This is perfect timing as I'm just about to start up a new project (more info coming soon)