i implemented pathfinding into sodium engine for a project for class (had to apply something we learned in AI).

Download (987kb):
http://binarydemons.com/~strike/files/pathfind_test.zip

Note: If your JK directory does not match c:\Program Files\Lucasarts\Jedi Knight
then please modify script.ss. Otherwise, you should just be able to unzip and run.


Screenshot (with 200 pathfinding bots. The download has 5. You could modify the script though...)



Screenshot of the ai path nodes that are built using sector adjoins

your stuff looks awesome, but please please telll me what this stuff is actually for?

Can u improve the general engine for mods and levels, if so, hook me up my good man, and I will pay you handsomely*

*payment in the form of pictures of johnny Depp.

if(getThingFlags(source) & 0x8){
  do her}
elseif(getThingFlags(source) & 0x4){
  do other babe}
else{
  do a dude}

Currently you could consider it sort of a JK clone, in that it will load many of JK's resource files such as textures, models, levels, and others.

What I'd really like is to create a complete game with a small team of 2 or 3 people, and allow others to mod it or use the sodium engine to customize the game completely to their mods' needs.

If anyone is genuiously interested in any of the following, leave a post with your aim or msn:
- creating / maintaining a project page
- engine development / coding C++
- gameplay development / scripting (sodiumscript is very similar in syntax to COG)
- art / textures
- art / models
- art / levels

Sodium using custom textures and built-in skybox support
(Lighting is a bit screwed up, I've been messing with the vertex light calculation)

So wait, this is like a new engine using JK resources?

I don't quite fully grasp the concept, but that sure is pretty, what with all the colors and all.

So how many of JK's resources will work in this engine?

Right now yeah, more or less. Later I hope to create enough of my own custom tools that it is a complete package, but right now JK (more importantly: JK's fan-created editing tools) are going to guide the project along.



The solid green lines are the projected path for an AI object (the robots). A solid red line is the current 'path node' for the bot. The blurry color effects are just particle emitters that were easy to hook up and look cool lol.


As for the supported file formats:
- jk models .3do (with full support for model hierarchy)
- jk animations .key (not done yet, but it animates keyframes on models)
- jk levels .jkl (mostly done, still working on visibility determination. doesnt load things)
- jk colormaps .cmp (for converting 8-bit textures)
- jk materials .mat (8-bit, 16-bit both 565 RGB and 1555 ARGB. solid color textures, multi-cell textures, mipmapped textures, and transparent textures are all supported)
- jk container .gob (self explainatory.. can load files from within .gobs)
- sodiumscript .ss (proprietory scripting language, very similar to but more powerful than COG - includes full support for strings, user-defined functions, recursion, local variables, user-defined callback functions)

Using (or supporting) many of jk's file formats such as 3do, key, and mat should be pretty easily to maintain for the life of the engine. Levels, however, are a different story. There are a couple possibilities I have in mind:
- modify JED and customize for sodium's needs
- create a JED plugin that extends the capabilities of JED for sodium's needs
- create a custom level editor (not likely any time soon lol - I hope to later on..)

Sign me up.
AIM - DPatMassassi

Looks good, and I'd go with creating your own custom level editor, and I could help you with the layout, interworkings, tools, and coding. As you know, I have some C++ codin skills. I can help with engine development, and I like to think of myself (with my inflated ego n all, as Massassi knows me to be) as a master cogger, therefore I should be able to use Na script good. Plus I'm an okay modeler too. :p

Well, I'd help with coding, but I don't have much time availiable to me. I could possibly help with debugging or some coding areas as time permits.

I won't be signed into my aim for a bit, so I won't post it for now.

If in the event you want to help, aim me chickenshtstrike

Could you explain how you're doing that?

Here's a simplified, but complete, pseudo-code form of the pathfinding node generation code:



From here, the actual pathfinding code is pretty easy as long as you know which sectors the beginning and end points of the path are. This is a level-traversal stage of pathfinding. It can find a path from any position to another in a level, through doorways and windows. What I would really like to shoot for next or at some point later down the line is another layer of pathfinding that is planned for an object within a sector - taking into account things such as doors or barricade 3dos that may be there.

I've been thinking about creating a 3d collision map out of the current sector and its contents, like a 3d box just big enough to contain the sector but filled with packed spheres, each sphere can be 'collidable' or 'non-collidable'. One of these conceptual spheres would be flagged as collidable if it happens to collide with a surface of the sector or with a thing in the sector. A conventional pathfinding algorithm (such as A*) could then be performed using this 3d collision map, with each sphere flagged as non-collidable being a path node.

The result of this would give VERY high quality and sophisticated paths, and could potentially take into account factors such as the character's height, ability to traverse difficult terrain, ability to fly, ability to swim. The best part, as far as performance is concered, this type of method would be utterly scalable, as the collision map's sphere size and count would just have to be adjusted to generate either very general (but fast) or very sophisticated (but slow) paths.


As you might be able to tell, I'm pretty intruiged about this stuff, hehe. I'm really pleased with how well this 'prototype' pathfinding works.

Here's another download that the other screenshot I posted is from.

Download (1.46mb)
http://binarydemons.com/~strike/files/se_dist.zip

Little objects float around the level, heading towards a charging station. They get charged up, then head randomly to one of 3 different 'dropoff' points, where they lose their energy, head back to the charging station, then find another random dropoff point.

Since they all end up taking the same exact paths, it almost starts to look prescripted. Tap space bar and all the floating robot things will pathfind to your position. Press space bar again and they will return to transporting energy.

Press enter to cycle through path node display modes. The possible modes are:
First mode:
Nothing is displayed

Second mode:
Active AI paths are displayed. Green is the entire preplanned path, red is the path link the ai is currently on.

Third mode:
Same as second mode (active AI paths are displayed), plus all the pregenerated path nodes are displayed and linked together with thin blue lines.

And I'm still confused as to why you aren't working together with Jon`C for SITH2, since he has already done 90% of this work, in a higher-graphic quality engine. If you could assist him in the proper collision detection and physics of the game, he'd probably able to finish it.

What if he doesn't want to? It looks like he's enjoying himself. And besides, I remember he offered his help to Jon who turned it down.

Wow!

I considered doing something like this myself with JK, but using positions from adjoins to get path nodes wouldn't do what I wanted. For example, if you have a bot that can't fly, how is it going to get near a path node in the center of a large adjoin surface?

Create node paths only along all surfaces marked as floor?

That would be possible, after the level is loaded and the pathnodes are being generated, each pathnode could get a flag specifying it is a walkable path, if its adjoin shares verticies with a surface flagged as floor. That, however, wouldn't work for all cases. I'm probably better off not touching the AI stuff anymore for a while (because both sodium *and* I are really not ready for it, this was purely for a class project due in a couple days), and getting some of the more fundamental code nice and solid. Need to go through and clean everything up removing commented code, adding file and function comment headers to the .h's and redo some of the core structure, because frankly it sucks.

This was originally an OpenGL class project, with just a 3do loader that didn't support model hierarchy or even multiple meshes. Most of that code in the rendering subset is from that class project, lol. The compiler, particle emitter, world object (thing) class, resource manager, and all the jkl/model/key/mat/etc loaders are all solid though, and there's much much more sense in just fixing and rewiring together whats broken than starting over. I'm getting so sick of writing windowclass registrations and initializing opengl =P

But yes, I'm having lots of fun working on this, and even if the game we (meaning whoever else is interested) is warped and disturbing, which im sure it will be, it'll all be worth it

Keep us updated, this project definately has me interested!