Page 9 of 22

Posted: Sun Feb 10, 2008 10:33 pm
by MasterGod
JP wrote:One thing i'm going to look into is multi-threading to speed things up, this means that the AI can be calculated while the rendering is being done and then the results can be used in the next frame, just like physics engines work. That should improve the performance quite a lot i should think.
Great Idea, it should really effect the performance greatly!

About the exe file, my bad.. (again and again and again, do I never learn!?:lol: )

P.S
I guess you're right with what you said regarding Christan and The First King project, hope things will work alright with it..

Posted: Sun Feb 10, 2008 11:17 pm
by Halifax
What library are you intending on using for the multithreading JP? If I may recommend one, I would say GLFW although you may be looking for a library specifically built for multithreading, I don't know. But I have had good experiences with GLFW's implementation, and it is cross-platform, and open-source.

Posted: Mon Feb 11, 2008 9:31 am
by JP
I hadn't really considered using a library for multi-threading... i didn't realise there were libraries available.. what do they offer? Things like mutual exclusion and everything?

Posted: Mon Feb 11, 2008 12:26 pm
by MasterGod
[offtopic]Cool update on your sig JP, just what is written there in white?[/offtopic]

Posted: Mon Feb 11, 2008 12:30 pm
by JP
The Curse of Captain Morgan. It's the title of Alestorm's debut album which has just been released to the world, the game being based on the band, who used to be called Battleheart... now that they're Alestorm i've decided to update the name of the game!

If you're a metal fan you should check out their incredible brand of Scottish Pirate Metal. If you're not a metal fan you should check it out anyway as it's fairly hilarious! :D

Posted: Mon Feb 11, 2008 2:29 pm
by MasterGod
JP wrote:The Curse of Captain Morgan. It's the title of Alestorm's debut album which has just been released to the world, the game being based on the band, who used to be called Battleheart... now that they're Alestorm i've decided to update the name of the game!

If you're a metal fan you should check out their incredible brand of Scottish Pirate Metal. If you're not a metal fan you should check it out anyway as it's fairly hilarious! :D
"Alestorm - Wenches And Mead" LOL!!!

P.S
You should update on "JP's Place" - "Battleheart (In development) ".

Posted: Mon Feb 11, 2008 2:32 pm
by JP
Indeed i should, will do when i get a chance!

Posted: Tue Feb 12, 2008 2:34 am
by Halifax
Well basically it only offers like thread synchronization, mutexes, etc. All the standard threading things that are needed. Although if you only want if to be Win32 and PS3 multithreading, then you could check out bullet's source code.

Posted: Tue Feb 12, 2008 9:09 am
by hybrid
you might also check the boost implementation of multithreading support, because it is already promoted to official c++0x standard.

Posted: Tue Feb 12, 2008 9:34 am
by JP
Cheers for the suggestions guys, i'll check them out when i get round to looking at the multi-threading. Hopefully it will be possible, i guess it should be as irrlicht is only really not-thread-safe on the graphics side of things and irrAI won't be touching any graphics itself.

IrrAI

Posted: Sat Feb 16, 2008 10:52 pm
by Kaeles
Hey!

I was thinking about doing something along these lines awhile back. (A generic AI type engine for irrlicht).

Anyways, I'm gonna try and read over the source code today or tomorrow, and see if there is anything I can add.

I will look into trying to make an algorithmic pathnode creator (i.e. you pass in a quake level to the function and it returns a waypoint map.)
Also, I have looked over opensteer and some other basic steering behavior stuff and I will see if I can implement these behaviors somehow into the IrrAI.

Another thing that might be useful is to have a sort of entity interface wrapper.
I.E.
Where the user must implement the movement functions themselves (forward, back, etc) but the AI engine calls them, so that the AI engine has no need to know of the internals of the game engine or whatnot.

Another thing that this allows, is that if the AI engine has a copy of the level mesh, along with the waypoint / visibility map, you can have the IrrAIEntity wrapper register itself with the AI engine, so that you could put tags on the entities, so that the AI would be able to recognize them, like health powerups, squadmates or whatnot.

I also plan on useing it somewhat for a project I'm working on :)
Anyways, hop on the IRC sometime JP.

Posted: Sun Feb 17, 2008 5:28 pm
by JP
hey Kaeles, that sounds pretty cool, some good suggestions in there. I tried to make a algorithm to generate a waypoint map automatically, using irrlicht's collision detection with rays but i couldn't get the rays working for some reason... they weren't doing what they should have been doing for some reason!

I would hop on IRC but i never have any time to i'm afraid! Feel free to PM me, i'm always checking on the forum during work hours so can usually reply pretty quickly.

Posted: Tue Mar 04, 2008 5:00 pm
by Boca
Thanks and congratulations, JP. This is a great program and a incredible work (job). Now, we can add others personages (actors, enemys, allies...)

Posted: Tue Mar 04, 2008 8:28 pm
by JP
Thanks Boca.

I've said this to MasterGod in another thread but i'll say it again here.

Currently i'm working on chasing & fleeing behaviour. I've got the basics down, it's not very clever chasing or fleeing but it's certainly a start. I've also got support for attacking an enemy when they come into view (if they're in range of your weapon). I'm also sorting out the way that enemies and friendlies can be defined.

Hopefully it won't be too long before i can get this demo up.

Posted: Wed Mar 05, 2008 5:23 pm
by JP
Ok, well the new demo and source is up (check the first post for downloads and screenies).

The chasing and fleeing behaviour is very basic, but it's good to have the basics of it implemented and they can be improved upon in due course!

One good thing ive done is recode the way the NPCs move. They used to use fly straight animators to get between waypoints but that kinda limited them from stopping part way between 2 waypoints and taking a different path.. well i guess it didn't it could have been handled in a way to make it work.. but anyway, now i just move the NPCs with setPosition a bit each frame (will make it framerate independent eventually!) which actually works a lot better i think.

One of the next things i'm going to do is have some way of an NPC knowing that they're under attack. At the moment the black chap can be shooting Johnny 5 from behind and he's none the wiser (though there's no collision detection at the moment anyway so the shots go straight through him). I guess what i'll have to do is have the application send an event to the library that the NPC is under attack so it can react in some way.