Quote: "Except for hiding the implementation of EXECUTE FINITE STATE "all" and ability to set multiple states for objects, what you have can be done fairly easily with some functions and a select...endselect which calls each function depending on state."
I'm not the best at explaining some of my thought processes when creating some of the stuff I do, but I'll try. The spontanious idea I had at the moment of creation was to cut down the coding need for the users program loop. Different parts of the game would be written in managable chunks (dbpro user functions) that could update global variables and the finite state machine so that on the next loop cycle the proper functions would be ran. Here's a pseudo-ish idea of it:
` global variables defined and pre setup completed here
make finite state 1,"enemy_fight",1
make finite state 2,"enemy_evade",0
make finite state 3,"enemy_find_health",0
do
execute finite state "all"
sync
loop
` This is dbpro user function: 1
function enemy_fight(indentifier$ as string)
` The code here for example would attack the player if
` in sight, and if the player knocked down the health
` of this bot too far, commands like this could be used:
` set finite state "enemy_fight", 0
` set finite state "enemy_evade", 1
` set finite state "enemy_find_health", 1
endfunction
` This is dbpro user function: 2
function enemy_evade(indentifier$ as string)
` Here is code to check the enemies vitals as it evades
` updating various variables as needed.
endfunction
` This is dbpro user function: 3
function enemy_find_health(indentifier$ as string)
` The code here could have the enemy bot looking for a
` health pack, and if found issue off commands like:
` set finite state "enemy_fight", 1
` set finite state "enemy_evade", 0
` set finite state "enemy_find_health", 0
endfunction
I guess you could say it almost turns your application or game into a object oriented setup. Maybe it's just me, but it seems really easy to maintain this way, and appears more organized.
Quote: "I'm also not sure about having numbered functions. I understand the technical reason why you have to have it... just that I don't want to worry about what order my functions are in the code."
Take a look at the code in this posting. Your functions can really be in any order, but since I'm basically cracking your game in memory while it's running it reads the functions as they appear in memory. I use function numbers because it's the easiest way to reference user functions.
Quote: "Wouldn't really like using a string for an identifier... since array storage in DBPro is by integer/dword mostly, I'd have to convert back and forth between the identifier and a number when doing game-specific actions and that might get cumbersome. Are you using this with Lua tables or something?"
I could change this indentifier really easy to be a integer or dword. At the time I was developing it my mind was thinking people would refer to different game objects like "bigboss1_attack", "spotlight_on", etc. Something simple and organized. There are no Lua tables in my dll, I created my own data structures. In fact it may not be surprising to anyone, I don't like Lua (GameMonkey all the way!!).
Quote: "Oh by the way... how is that Game AI by Example book? Is it really good? Helpful for non-OOP, procedural languages like DBPro? I've been thinking about getting it."
"Programming Game AI by Example" is an excellent book to learn from. The author takes things step by step and shows example source code (C++). So with a little C++ knowledge you'd be able to port the example code to nearly any other programming language you know.
