Enemy A.I & DirectPlay SDK

[T¹]

Okay, I've been working on a 3D shooter for a little while now and have hit an assortment of problems, ever since i've started. I've now managed to sort out collision, terrain height problems, speed increases (31-35fps) but i seem to have hit a dead end at enemy intelligence. After i succeeded in adding enemy ships without slowing the game down, i've become kinda stumped with enemy A.I. Does ANYONE know of any docs, tutorials or ideas on how to approach this? I know it might seem kinda lame to certain high-profile coders, but remember that i've been out of coding for nearly 2 years, and i don't remember doing any clever a.i before that, anyway. I'm trying to make stealth an integral part of the gameplay (sneak into hq, retrieve x, get x to base, etc) but most of my attempts seem to backfire or become expensive. I really would appreciate any help.

If all else fails and i don't manage to add decent intelligence, i intend to turn it into a deathmatch-style shooter for 2 players, hopefully using the directplay sdk. Has anyone had any experience with this? If i do this 'deathmatch' alternative, i would like for it to be more than a simple 'shoot & hide' type game, and it would be passing more than a couple variables between the 2 devices. However, assuming the limits of IrDA (primary method of connection), has anyone experienced any 'lag' when using the sdk?

I know that i could probably answer my own questions simply by writing test code myself, but due to the nature of my work, i don't get a lot of time to code, but i do manage to do a fair bit of reading while on the road. I would greatly appreciate input or even assumptions from anyone with some knowledge.

Bugger it, if neither plan works out to my satisfaction, i'm just gonna give the current source to someone and let them turn it into something special...

[refractor]

Hello.

Steven Woodcock's (stop giggling at the back) AI page is the best AI page (for games) that I know of:



(You want to look in the pathfinding section of the "Resources Quick Jump" frame).

When I was at Uni, I implemented an A* & D* algorithm (badly) to produce a (bad) "pursuit and evasion over a 3d terrain" system, with predators chasing prey all over the place. (Sounds good, but it wasn't).

For the type of game you describe, I'd use an A* or D* system. An A* system is essentially a heuristic based path-finding system that presumes that the terrain and "goal" are static. Given the correct heuristic, IIRC, it produces an optimal path from the start to the goal. I used a weighted grid (weighted on terrain type and on the height delta) to store the "cost" for the terrain.. but all of my animals were land-based... but that's probably overkill for you (my animals had energies, so they died when they starved and could only reproduce if they had enough energy, etc). Depending on what you want to do, a simple flag for each "unit" in the terrain (height-field in your case I think) could be enough to implement a path-finding system. Marking the walls as an infinite cost and everything else as 1 should work fine.

The dynamic A* algorithm (D*) is what you want, I think.. but it may be overkill, too. For a stealth game with a few "enemies" it probably is what you want.. if you're doing a "wave-based" shoot-em-up.. it probably isn't. The D* is essentially a more dynamic A* algorithm - the destination can change and the algorithm can be run in steps, so it's much "nicer" game-wise.

I implemented a rudimentary eye-sight system too:

true line-of-sight over the 3d terrain
eyesight range (angular and distance)

..it worked quite nicely sometimes (if only I'd put a learning system onto the animals and had them learn that they could sneak up on the stupid prey from behind).

The A*, D* algorithms can take up a lot of space for the tree if you're moving over long ranges. To combat that, I simply said that the animals could only move somewhere they could see and made the visual ranges small. It meant that the animals stopped chasing each other when they lost sight of each other, but that wasn't really a bad thing.

Hope that helps, let me know if you need any more info., cheers,

Refractor.

[T¹]

[Johan]

Hi T1,

If you want to build network games, I have a serious alternative coming up: OpenTrek!

<begin announcement babble>

This weekend I will release the free multiplayer networking platform OpenTrek. It contains all the features from DirectPlay (safe and unsafe UDP messages, layered multicast groups etc), but has a different focus.

With DirectPlay, you have to create your own "lobby", waiting for players to join etc. OpenTrek can more be seen as an ICQ client without a GUI or any messaging services. Add a custom full screen "awareness" plugin and you have a complete game lobby! Add a chat and you have a messaging service! The cool thing is that the user can choose views on the fly, all of which can be used to start your game! Also, YOU don't have to create lobby applications to get your game working. Just add support for OpenTrek, recompile and begin send network packages (in 5 minutes)!

OpenTrek comes for both Pocket PCs and Windows 2000/XP. You can use it with GAPI or whatever. You can fully "brand" the client for the end user. Adding support for OpenTrek to your game usual takes around 5-10 minutes (to get the single player working). OpenTrek is a project with nearly 2 years in the making, and is based on my previous work as a middleware consultant for Ericsson, Saab and Volvo.

OpenTrek is layered slightly above DirectPlay, and has an open source messaging protocol. It supports development of games using both C, C++ and C++ with MFC.

Be sure to checkout on Sunday.

<end announcement babble>

Best regards,
Johan

[T¹]

Sounds juicy . I'll definitely take a look.

[RICoder]

[T¹]

When you say "in print", do you have the names of any decent books on the subject? I have a strong feeling that i would like to further my knowledge in this area, more complex ai being something that i'm sure i'll implement more in the future.


BTW If anyone's interested, i've updated the left screenshot below to a more current one. I plan to add particle handling soon...

[RICoder]

[Conan]

[T¹]

Ah, collision detection! For me, that was definitely the most time-consuming and hardest thing to implement. I also had problems with fluctuating frame rates due to the ineffeciency of my original code. There are some good docs on GameDev (), and there are also some good references for ai & other stuff that i only noticed recently. I would also recommend that you think about collision while in the planning stages of your game: In my experience, trying to add it after I already coded some stuff made it particularly tricky to implement. I used the bounding-box method initially which was fast but inaccurate for irregular-shaped objects. It all depends on the type of your game, the type of collision to implement.

I also have a very useful Word document on collision which helped answer some of my basic questions. Let me know if you'd like a copy of it. Good luck!