I'm working in my spare time on a Pengo clone, and the a.i. of the enemies is a big downer for me. For example, if an enemy goes for the hero (who is right and above), moves right, and hits a brick to his right, if the hero is above him he must move up, and then at certain intervals test if there is still a brick at the right and if not, proceed to the right. But what if there is a brick Above him... see? he will have to make a huge route tto the left and even down, avoiding bricks, to get to the hero. Still he must remember his goal. So I created 'memory banks' of his coords and direction so he can get back when things fail. The main problem is that there are a huge number of logic tests to be made- and my code is getting unreadable. How can I optimize such logical tests- or make my code more readable? Any tips? Thanks.

Someone else doing a port! :D

I'm in the process of porting the arcade game Rampart; I have a demo up on my website if you care.

Sometimes code is messy. I've always found that scanline rendering of a polygon is ugly code, no matter how it's done.

Maybe the answer your looking for is not cleaner code, but a different way of getting the enemy to the player.

Pengo is an old game, and ran on slower hardware. I doubt it had any form of sophisticated player hunting.

The first thing you should do, if you haven't already, is go play Pengo and watch how the enemies behave. Run some tests; you might be surprised at how simple they really are.

The next thing you could do is look for an alternative method of hunting: Instead of using crazy logic to find the player, just have the enemy follow these simple rules:

1. Move towards the player at all times, if possible.
2. If cannot move towards the player, move in whichever direction is possible, but do not move in to the last square we just occupied. (so no back-tracking)
3. If we have to move in to the last square we just occupied (like if you're at a dead end), move towards some random map location for a 'n' number of turns.


OR

Follow the left or right hand wall... :) Pengo levels are of the type which each square is always accessible from every other square...

Good luck,
Will

Quote:
Pengo is an old game, and ran on slower hardware. I doubt it had any form of sophisticated player hunting.

Indeed! But.. my clone will be , if it's ever finished, muchmore sophisticated than the original Pengo. Enemies who learn, have memories, etc.

Quote:
The first thing you should do, if you haven't already, is go play Pengo and watch how the enemies behave. Run some tests; you might be surprised at how simple they really are.

I studied the game to great extent. The enemies move in great random way, but they seem to have some kind of memory/pathfinding, or mutual coorperation. Of course, the sno-bees (enemies) can crush the blocks, so that is easier to find the way to te player. But I have also enemies who cannot crush, and move very fast and have to find a way along the blocks.

Quote:
The next thing you could do is look for an alternative method of hunting: Instead of using crazy logic to find the player, just have the enemy follow these simple rules:

1. Move towards the player at all times, if possible.
2. If cannot move towards the player, move in whichever direction is possible, but do not move in to the last square we just occupied. (so no back-tracking)
3. If we have to move in to the last square we just occupied (like if you're at a dead end), move towards some random map location for a 'n' number of turns.

Maybe i indeed need to take a step down, and make the moves more random. That would take a lot of burden away, as it's much easier to find a clean way to the player.

Thanks.

1) You can read about pathfinding algorithms such as BFS, hill-climbing, A-star and they may give you insights on how to write such logic in an elegant manner.


2) Sometimes a great way to organize your thoughts and your program logic is a state machine. I am not sure if its a good solution for your path finding logic, but give it a thought.
If you dont know what state machines are take a few minutes and read a tutorial on them (its a pretty simple concept).

Design a state machine for the AI logic. You can design it on paper (with circles and arrows) before you write the code. You can have hierarchal state machines for better organization.

for example:
have these top level states: chasing, running, hiding, crazy-walk

now the "chasing" state can be made from an inner state machine, having states such as "right-blocked", "left-blocked", "right-and-left-blocked", etc...

Im not sure this will make the code easier to write, but it will certainly make the code easier to read, I mean when you read a few lines you know exactly what state the AI is in and when you encounter a state change (either by recieving event from outer framework or from deciding logic in the state code) its very readable to know what state to move to.

Iftah.

Yes, interesting, the 'state machine' idea- i think I can use that into the game. thanks!

I thought you were working on a clone of the game, not a super version.

Pengo baddies that act like a pack of wolves... that should be fun. :)

Will



[Edited by - RPGeezus on April 4, 2006 2:57:12 PM]

Hehe... quite a few years ago I designed a reverse-Pengo game... a team of penguins trying to squish a bee with iceblocks (the player was the bee). The players aim was to sting the penguins before they squished him. The penguin team AI was built around a heirarchical communication system: a lead penguin looking at global constraints, communicating orders to worker penguins that tried to enact the orders as best they could, but just following local optimisation principles.

Unfortunately for me the AI lead me down other tracks and I never got around to finishing the game... although there was for some time a basic working version (thats long since disappeared though).

The point of this is that I did have some success with a heirarchical AI approach, so you could try breaking down your AI in that fashion. It may require some redesign on your part, but what have you got to lose (other than time and sanity)! ;)

Cheers,

Timkin