|
Posted By
|
Message
|
![]()
eyeangle
Registered
12/06/2003
Points
1683
|
2nd March, 2008 at 05:24:33 -
Are there any such things as A.I. Librarys in the world of Klik.
They would come in so handy for myself and I'm sure alot of other people too.
Basically the way I imagine it would be to open a page and under different types of enemies it explains how to do it. Whether it be platform of RPG, etc.
I'm making a platform game and would love to do something like this one day to help out noobs (or people like myself who have been clicking for years and still don't know how to do it), but I'm don't have the maths brain. I find myself posting too many questions about how to do this or that and AI.
So if this kind of thing exits, give me the link... But I reckon it'd be a really handy tool for klikers in the years to come.
theonecardgame.com
|
DeadmanDines
Best Article Writer
Registered
27/04/2006
Points
4758
|
2nd March, 2008 at 14:17:36 -
In the meantime, searching DC and asking here and at the CTForums is your best bet.
But I can share a few words of 'wisdom' that have helped me - maybe they'll help you 
Divide your AI into two sections:
- State Checking
- Behaviour
"State Checking" involves finding out anything important about where the AI is, and what he's doing. These are his 'senses'. So this is where we code things like:
'is he standing on the ground?'
'is he falling?'
'can he see the player?'
'is he next to a wall?'
That kinda stuff. I keep them in separate groups. So, like for a fish enemy I'm working on, he has the following groups:
FISH
- STATES
-- Is onscreen?
-- Distance
-- Is player in visible range?
-- Line of Sight Test
- RESPONSES
-- Idle
-- Attack
-- Swim in a shoal
In this case, I want to know if the fish is onscreen, how far he is from the player, and (if he's near enough and facing the right direction), whether obstacles block his view of the player. These are stored in alterable values and strings, like this:
is Onscreen (YES or NO)
Player is in focal range (YES or NO)
Player is visible (YES or NO)
Distance to player (a number, in pixels)
If you code your 'senses' or 'tests' FIRST, storing them in alt. strings and vals, you enable the rest of your code to run LATER, based on the WHOLE picture.
In the case of a Platformer AI, you can make him act a certain way if he's standing on the ground AND near a ledge, but NOT too close to the ceiling... and the ledge has to be high enough to cause him damage.
See how defining states first lets you control his behaviours with far more precision later?
191 / 9999 * 7 + 191 * 7
|
|
|
|
Advertisement
Post Reply