what I've been up to

[keless]

You may have noticed the ICE and Tetris project threads seem dead.

This isnt because Im not programming! I've been busy testing out some more game engine and 3D stuff in IrrLicht. Im not posting this in the Projects thread because its not quite ready to be called a project yet, but when I do, it will be called IrrLichtRPG. When I get to actual content creation based on this engine, I will be calling it the "Erring Light Saga". Im original with names, arent I?

Currenly I have a room with two faerie models running around in it. (You may have seen the binary demo I posted with the floating camera.) Thats about as far as its gotten functionally, but whats important is more whats under the hood.

Currenly things have been abstracted to a high-level message passing system. Instead of directly manipulating an object's position or animation based on key input-- now a key creates a message "creature 0 move forward" which is sent to the level manager and then to the appropriate model controller. This scheme will make adding scripting and networking easy later on.

Currently you can add and remove entities from the level manager, and all entity's collision animators will add or remove the new entitiy's collision information, and it will add all of theirs.

I found the collision detection interface to be clunky in this aspect, as to add a new CD-enabled object to an environment, you have to add its BB-TS to all other entity's collision animators, as well as create a new MetaTriangleSelector to add the level and all other entity's BB-TSs to be used as the new entity's collision animator's TS. Plus, when you need to remove an entity, you must go thru all other entities and have them remove the BB-TS belonging to the entity to be removed.

Clunky, but it works. On my computer at work, running OGL in software, I am able to add and remove objects to the room.3ds + faerie.md2 scene with about 2 faeries in it without visual lag, and I havent stress tested it yet, but I assume I could get up to about 500 entities before it became visual (since its just adding and removing pointers from IMetaTriangleSelectors).

Another interface I found to be clunky is the IAnimatedMeshSceneNode. Creating them is very easy. Animations are so-so, and removing the actual mesh seems impossible?

First of all: removal. I cant seem to find anyway to specifically make IrrLicht remove a mesh. I cant drop() it because its not a create call-- I hope that while it is sitting in memory with no references, that if that memory is needed, it will be removed. But that would only work if its needed by other IrrLicht memory-managed objects. And I really want to be able to control the unloading of all resources myself.

Animations: I can easily tell it to start an animation. However, I cant tell how long the animation is, so if some event wants to start a new one, I cant tell if I've finished the current one. In the very least, I'd like a boolean setting for "uninterruptable" so that starting a new animation while the current one is running will return false. Also, I'd like to be able to tell it to play an animation only once, and then give it an animation name to return to after its done. Something like:
setMD2AnimOnce(EMAT_ATTACK, EMAT_STAND);
where Attack is uninterruptable, though Stand probably wouldnt be.

The next thing I'll be doing is implementing 'weapon collision'. IE: when someone attacks, I'll generate a bounding box or sphere, and asking the scene manager what nodes it hits, then determining if those are entities which could take damage, and then generating an event to "damage creature x"

After that, I'll be adding support for 'timed-live-span' or 'temporary' entities. So when you cast fire, a fire particle system will be created as a 'temporary' entity which will remove itself after its life-span. These will be kept in a separate array from the regular entities because they dont need to worry about collision detection.

Eventually when thats done, I'll actually declare this a new IrrLicht Project, and announce it, as well as release the commented source code. I'll be adding a scripting system using CaLUA, creating an RPG stats system, and probably use SQLlite for stats storage/retrieval. Networking is an option, though not likely unless someone else wants to co-author this project with me when its started.

[DarkWhoppy]

Sounds sweet , an RPG-System for Irrlicht. Hopefully i'll have documentation like Irrlicht

[Byron]

Documentation! You ask way too much.
j/k, sounds cool keless

[keless]

@DarkWhoppy: "an RPG system for IrrLicht"
technically it wont just be RPG. It will partain to anything with 3d world and 3d avatars roaming around in it. So if you wanted to create crash-bandicoot or something. However, its being designed with RPG in mind, so it wont be the best for FPS (though you can easily throw in an FPS camera, it wont be making optimizations/features with FPS in mind, such as body-part hit-detection)

playin around a little bit more..

apparently temporary items are going to be really easy because of the createDeleteAnimator() functionality. so they wont need their own list. If only there was a fade out affector for models and not just particle systems, I would be pretty much set for special effects for now.

I got the 'attack' message to delete and add the NPC fairy to the scene, and Im even shooting a temporary particle system from the Hero fairy's hand when she does this. (it doesnt look that great, but thats just a matter of tweaking)

next is to do a ray cast (instead of a sphere/bb test, because there is no functionality for that in irrlicht right now) to see if I hit an enemy fairy, before 'deleting' it from the scene.

now that this testing code is satisfactory, i will be moving it all to more robust structures. For instance, the particle system is currently hardcoded. I will be moving the creation of all temporary entities to a factory class. When I add scripting, scripts will have access to this.

If you want to get your hands dirty on the latest source, you can get it here for now: http://www.skyesurfer.net/keless/IrrLicht/RPG/ (this will change later, when I make a website for it)

the latest .zips dont have the /data subfolder in them, because it was redundant data, but you can get it from one of the earlier (larger) zips.

[powerpop]

great work keless!!!

these kinds of frameworks will help a lot of people get started and contribute

[niko]

Wow, nice, complete list. Some of the problems you've listed have been mentioned before, and you are right in all cases, I think. Irrlicht seems to be not very mature yet. The deleteAnimator is available for example to create temporary particle systems, but you've figured that out, too.

Eventually when thats done, I'll actually declare this a new IrrLicht Project, and announce it, as well as release the commented source code.

Nice, lookinf forward to see it. If it's going to get very useful like it sounds to be, maye you could consider to create an own sourceforge project for this. Cool work!

[powerpop]

keless - what you want to do with animations is a directed graph (do you know about these?) - basically its a chart of what states can go to which other states for a character

walk
| \
stand--run
| /
jump

this is a simple one - in this graph you cant go from jumping to walking

if irrlicht lets you get the number of frames per animation you could calculate how long each animation loop will take - it would be better though, as you state for the code that plays the animation to notify you when they are done - a callback works well

in code you make a directed graph by having a list of states and the followon states that can happen - and you usually need some decision code that quickly decides what to do next of the list of possibilities

is there a directed graph structure in the STL lib ?? there has to be code out there on the net for this - its used so often

[keless]

powerpop: yah im familiar with DSG. its basically the same as Finite State Machine, etc. I havent programmed one, tho I did see one used in the GTEngine ( http://gtengine.sourceforge.net/ )

What I'd really like to see is this sort of thing encapsulated in the model format. I think it'd be great if the modeller could hand me an avatar with a high-level command interface. (ie: you can tell this model to jump, but not fly. or, you can tell this model to shoot an arrow, but not cast a spell) I think I'll end up putting this sort of information (ie: the DSG) in an XML file that will stay next to the actual model file.

niko: currently I have a Sf.net project, but its empty. was going to put tutorials in there, but I already have a site for that, so I think I'll put this project there, and just link to tutorials. now, if only I could figure out how to set up the CVS and website

Update: I moved the temporary entity creation into a Factory class. I also added a function to get an entity ID from a ray cast on attack, and its hard-coded to remove the 2nd faery if hit. If not, it tries to re-create the faerie.

for some reason, lighting looks awful on my two computers (its an option you can turn on or off, and its off by default, just go to options and turn it on)

here is a link to a playable binary: http://www.skyesurfer.net/keless/IrrLic ... _0.1.8.zip

[niko]

niko: currently I have a Sf.net project, but its empty. was going to put tutorials in there, but I already have a site for that, so I think I'll put this project there, and just link to tutorials. now, if only I could figure out how to set up the CVS and website

Ah, good idea. I don't know how to set up cvs in sf because I didn't try it yet (see the new FAQ item ) but for the website simply log in per ssh or sftp and upload your files. There are lots of nice free sftp interfaces available, for example I currently use the one by ssh.com.

[keless]

two things:

1) 'visibility' shouldnt be tied to animators and children
currently I have a scene node that represents the player's avatar. I have a 3rd person camera which keeps this node as its center.

I want to be able to switch into 1rst person perspective-- but I need to have the same collision data and other settings. Optimally, I would like to have my first person camera be located at the ISceneNode and simply turn that scene node invisible. However, this will stop the animators of that node, and effectively make it a 'ghost'. While I am pleased with the logic of "player becomes invisible, player is a ghost" , this is not the functionality I seek.

I'd like to be able to turn off a scene mesh's visibility without turning off its animators. I'd also like control over whether this affects childrens' visibility and animators.

Perhaps you could add a parameter to setVisiblity: a bit-flag. It could contain values such as "MODEL | ANIMATORS | CHILDREN | ALL" etc, with a default value of ALL (so old implementations work the same-- its backwards compatible )

2) um.. forgot the 2nd thing. lol

[niko]

Perhaps you could add a parameter to setVisiblity: a bit-flag. It could contain values such as "MODEL | ANIMATORS | CHILDREN | ALL" etc, with a default value of ALL (so old implementations work the same-- its backwards compatible )

AH, very good idea! Nice solution for this problem, never thought of this. I think I'll add this.

[buhatkj]

i like that, i knew i was going to have to do that for fmorg, but i haven't gotten there yet. i have been sort of avoiding the player inteface because i was waiting for 0.5 to see what i could do with the .X loader. i had been thinking about formatting the network messages in XML and passing strings of them to tinyXML to parse into the various commands, the trouble with this is XML is not a very efficient language. also i have to come up with a way to uniquely identify each object (player, item, monster, etc...) that exists in the game, and for that i have already made a simple objID field in each kind of object that i would need to track. it's just a long int that is based on a global counter that would run on the server, so those objectID's are only valid for that "session". the idea is to say "37|m|20|0|20" and have it mean ocject with id 37, move 20 x, 0 y, and 20 z. nice brief messages, which would be good to minimize the traffic it generates.

i will definitely have to check out how you did it, cool beans dude
-Ted

[saigumi]

Well, before programming games, I did some protocol reverse engineering.

This is the packet structure for Asheron's Call. I believe this is the active home of all of our combined research. It moved around a few times since I quit plugin development.

http://decal.insanity-inc.org/protocol/

This is the "receive" side of the protocol. (Server Sends->Client Receives)

One guy has posted what he found on the flop of this (Client Sends->Server Receives) while making a 2D version of the client.

http://vnboards.ign.com/AC_Utilities/b5432/62825408/?19

Decal (the program that uses the protocol) uses the XML file to parse the packet for an easy to read programmatically structure. The protocol itself is NOT sent in XML. That would be highly wasteful of bandwidth.

If you look at RakNet (a networking library - link in 3rd Party Helper Libraries Post), you define a C++ struct that the data will be sent in. This is the equivalent of what AC does.