Back to the Korax Forum Archives


Forum

AI

Wed, 20 Sep 2006 08:54:13

Crimson Wizard

Firebrand, I wish to ask two questions about botAI you were making. First is, are they able to seek route to some random point of map, not only to enemy. Second is, how do you use Nodes to define bot's route? Is there Node Graph build?
Wed, 20 Sep 2006 13:46:42

Firebrand

Bots have two basic actions that they do for tracking enemies, items, obstacles, etc. The first thing a bot will do for tracking things is to look around himself in 180 degrees and locate any objects, then he'll determine the route to follow (a vector traced from it's current Origin to the thing's Origin it has located), then he determines if there are solid lines or objects in that route, if there are any solid obstacles, he'll discard the object and follow something else he can see and it's not blocked from it's current position, if he moves and tracks the same object again, but it's not blocked he'll surely go to get it (whatever it is). To determine which kind of object the bot is tracking (items, path nodes, etc.) he'll just evaluate some flags I've added for different objects, if there's any more questions, just ask, I would like to improve the bots AI in any possible way <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->.
Wed, 20 Sep 2006 13:52:05

Crimson Wizard

Gee, does this means that if bot does not see anything of importance he will not move at all?? Actually I would suggest making Node Graph.
Wed, 20 Sep 2006 13:54:59

Firebrand

He'll continue moving in circles until he spots something again, that's why bots get stuck so easily in maps without path nodes, how you suggest to implement the node graph? A sequential series of path nodes ordered by number or something?
Wed, 20 Sep 2006 13:59:20

Crimson Wizard

Node graph is a system of connections between nodes. I never did this on my own, but may guess how it should be made. I suppose that each Node may have up to X connections with other nodes (4 maybe). When bot decides what he should do, he builds a path using that connections. To make this more effective nodes should be placed so that there's passable space between connected ones.
Wed, 20 Sep 2006 19:29:07

Firebrand

Sounds interesting, the bots already build a "previous" and "next" nodes system, I think this system could be adapted to they feel 2 or 3 different "next" nodes from their current "next" node (think of it like a list of possible movements), we could determine other nodes using the same algorithm bots use for looking nodes, but applying it to the node marked by the bot as "next", I hope my explanation is clear.
Sat, 23 Sep 2006 09:17:42

Crimson Wizard

Well, I was thinking about how to make those paths, I have some ideas, but I want to test them by writing small path-building program on pure C first. Then, I still wish to know two things: 1. Actually, you haven't answered clearly enouph, Firebrand, - how those bots use Nodes? Do they treat them as a sort of useful object and go for them in case they cannot see anything else of importance? 2. Secondly, imagine there's a path of nodes build somehow, for example an array of node references. May you make bot follow these nodes one by one? - and same task but with continious situation checking?
Sat, 23 Sep 2006 11:46:08

Firebrand

Bots detect nodes as any other object they would go for, think of it like a pickup (item, powerup, etc.), the bot sees the node and he detects the path to it, if that node is blocked, he'll look for a different node he can see and it's path is free, then he'll just walk to it's origin, mar the node as it's "next" node, but also mark the previous node he visited as "last", from there the bot will check for another node, bots "save" a reference to the next node they will go to and to the last node they have visited, we could add a reference to the "second next" node they'll get to (making the check as I explained in my last post), hope this clears up this stuff, if there's anything else, keep asking <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->.
Sat, 23 Sep 2006 11:52:25

Crimson Wizard

Well, it's rather clear now, except for the reason why remember previous node, how this reference is used then? As for path, I think it should be prepared already, bot should call some CalculatePath function which will setup a path for him, then he should simply go node by node; when he reach one node, he takes next reference from path array and continues his way. To increase the speed of calculationm it is good to have Node Graph build in the beginning of the game, or even saved as special lump, if it can be possible. But still, Node Graph is nearly senseless without dynamic memory allocation. I hope Janis will implement this eventually.
Sat, 23 Sep 2006 11:57:39

Firebrand

The bot saves his previous node reference in case he has to turn 180? for some reason (maybe a dead end or a heavy enemy chasing him <!-- s:lol: --><img src="{SMILIES_PATH}/icon_lol.gif" alt=":lol:" title="Laughing" /><!-- s:lol: --> ). Why do we need dynamic memory allocation for this? Yes, I think the path graphs could be done when beginning the level, to avoid more slow downs on the game (which already has a lot of them), I wanted to discuss with you the matter of development messages scattered all around the source, they cause the debug file to increase miserably when testing for much time, is there a chance that they could be turned off somehow Crimson Wizard? I think they are a nice addition from you, since they'll help to find problems when they occur, but they don't make much sense for a release, they still are printed when the game is runned without the "debug" parameter. And some of them are in places where they come strange (like those messages from "starting map list dm_") or something like that <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->.
Sat, 23 Sep 2006 12:05:20

Crimson Wizard

Dynamic memory is needed for Node Graph storage. We do not know how much objects it may store for each map, so it is rather inconvenient to use static arrays. About debug messages - it is strange they are shown even when debug is disabled; anyway, I will remove most of them, but I wish to leave some even in release - those that describe some weird errors (just in case).
Sat, 23 Sep 2006 12:10:07

Firebrand

It's ok, I'm just telling you that they show up without debug, I thought there could be some problem with those <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->.
Sat, 23 Sep 2006 15:24:56

dj_jl

It was a bug in the engine which printed all of the messages. It's fixed now.
Tue, 26 Sep 2006 20:00:20

Crimson Wizard

Firebrand, can you please check whether bots test bShootable flag when they seek for enemy? I was experimenting, trying to create spectator mode, set bShootable = false for player, but bots still were shooting at me.
Tue, 26 Sep 2006 20:35:49

Firebrand

Yes, if bots select one of the possible actors as enemy they recheck the bShootable flag, if it's not activated, then they discard the enemy, you can check it yourself in CheckStuff function in BotPlayer.vc. I don't think there's need for anymore checks for this flag, so the problem is somewhere, if you want, you can check the FindEnemy function to determine how bots select an actor as their enemy and how they look for it in SetEnemy, I don't know how you are doing this, maybe if you elaborate a bit on it we can find the problem <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->.
Sun, 14 Jan 2007 15:27:08

Crimson Wizard

I have some ideas about enhancing bots AI, I'll try them after I fix some known bugs for KA. Those ideas probably make it easier to define bot's actions in advanced modes like CTF, but also may increase bot's "smartness". Firt idea is to let bots define a combination of tasks for a period of time. For example, if a bot is out of ammo he should give "look for ammo" higher priority. In special cases, like bot have less than 1/4 health, he should forget about all other possible actions and run away seeking health items. And so on. Secondly I think I finally came to more convenient idea of using Paths without any need of graphs and dynamic arrays. I'll explain here in brief (if I will not be able to do this for some reason, I dunno, lack of time, perhaps someone may implement it, since I am sure it is a good thing <!-- s;) --><img src="{SMILIES_PATH}/icon_wink.gif" alt=";)" title="Wink" /><!-- s;) --> ). Imaging we build a number of node path, that is - large number of nodes, split to paths (we may use nodes' Args for defining path index an node index in path). Then, imaging a bot decides to SOMEWHERE - take specific weapon, go for an enemy flag, etc. What should he do? First, he checks, what NODES are positioned close to his target and choses one. Then, he checks what path does selected node belong to and seeks for the NEAREST node belonging the same path relative to himself (i.e. most close to him). Finally, all is left for him is to determine in which direction to follow the path of nodes (there are 2 directions - dir. of increasing node index and dir. of decreasing node index). The rest is up to map designers - to set node paths properly.
Sun, 14 Jan 2007 16:11:22

RambOrc

Priorities sound a good idea. Also, you could start thinking about how to use the bot AI elements and experiences in making monsters for the RPG more fun than they are now.
Sun, 14 Jan 2007 19:43:53

Crimson Wizard

Actually those ideas come from such thinking. I suppose we could finally have more generalised AI style both for bots and monsters (with specific differences ofcourse). But I have to explore Firebrand's work on bots in detail before I will try to implement something.
Fri, 19 Jan 2007 16:09:25

Firebrand

The idea for the path nodes sounds interesting, and implementing it doesn't requires extensive changes, as for bots priorities on tasks, if you check the bots code, there are some timer variables for many things, those would be used to give a specific time for bots to make certain things (chase after an item,roam for something, attack depending the weapon, decide what to do, etc.), if you have more specific questions you can try to contact me via e-mail, I'll try to read it frequently, if there's anything I can answer to you I'll try it <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->. As for things to add for making monsters more fun, I was thinking that we could extend the leveling system for monsters too, making them have certain experience points, or defining exp levels for them separately, giving them special attacks or abilities depending their level and affecting their basic attributes, health, speed, pain chance, etc. just an idea.
Fri, 19 Jan 2007 17:07:29

RambOrc

It's a definite no to the second paragraph, sorry. <!-- s;) --><img src="{SMILIES_PATH}/icon_wink.gif" alt=";)" title="Wink" /><!-- s;) -->
Fri, 19 Jan 2007 22:02:10

Firebrand

May I ask why it's a definite no? Vavoom engine allows this modifications without much problem because of how progs work, but maybe I'm missing something else, maybe it's too complicated for the RPG system? I remember than in a previous discussion you mentioned you wanted to keep things simple IIRC.
Sat, 20 Jan 2007 09:44:55

RambOrc

Point is, this is not an RPG but an RPG-FPS, meaning the player has to be able to determine the depth of the RPG. And that means he has to be able to kill the endgame monsters with early-game weapons and with very few exp and stuff (i.e. cutting straight through the game, not doing any quests etc).
Sat, 20 Jan 2007 14:32:46

The 4th Class

[quote="RambOrc":2vfqjx47]Point is, this is not an RPG but an RPG-FPS, meaning the player has to be able to determine the depth of the RPG. And that means he has to be able to kill the endgame monsters with early-game weapons and with very few exp and stuff (i.e. cutting straight through the game, not doing any quests etc). There is, of course, no stopping us from making multiple versions of the same monster. Say, in the regions where the game is still relatively new and the player with low EXP, we could use only the "stripped-down" version of, say, the ettin, with only 50HP or so. But once the player is all maxxed up in EXP, this lower-EXP ettin will still exist, but say in dangerous region only for masters, there will exist an even tougher ettin with an HP of, well, anything above 50. <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) --> Another thing we could do is manipulate enemy HP/stuff according to the skill level the player chooses to play on.
Sat, 20 Jan 2007 20:09:58

RambOrc

LOL a definite no again, read the concept document people. <!-- s;) --><img src="{SMILIES_PATH}/icon_wink.gif" alt=";)" title="Wink" /><!-- s;) --> The very point of this game is to be able to fight a thousand monsters at once, and you can't do it if they keep leveling up with you.
Sat, 20 Jan 2007 21:43:17

Firebrand

No problem at all, I just wanted to have some reasons before letting my idea be discarded. It was really more an idea than something else <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->.
Sat, 27 Jan 2007 21:31:11

Crimson Wizard

Got first results here. <!-- s8) --><img src="{SMILIES_PATH}/icon_cool.gif" alt="8)" title="Cool" /><!-- s8) --> In fact making Paths from nodes appeared to be much easier than I thought... seems I was a fool again. Linked list was a solution! Ah... <!-- s:roll: --><img src="{SMILIES_PATH}/icon_rolleyes.gif" alt=":roll:" title="Rolling Eyes" /><!-- s:roll: --> Currently the mod I managed to make supports only 1 path (of up to 256 nodes). When a monster is alerted by attack, shooting, whatever, he - a) checks what is the node closest to him b) checks what's node is the closest to enemy. c) builds a route setting up nodes he must pass; this however looks primitive for now since there's only one path. d) Follows path of nodes from starting node to ending one. (Those are not necessarily first and last nodes of the path). e) More than that, monster makes periodical rebuild of the route (not to often ofcourse) to be up to date for player's position. As soon as monster sees enemy, he forgets about paths and nodes and just attacks as always. If monster cannot find any path nodes he acts in usual way. Primitive yet, but it works nice for simple levels. And I can really see the difference! I will work to enhance all the system. Probably I will be able to upload a couple of demo maps in several days for you to see my progress.
Sat, 27 Jan 2007 23:51:00

Firebrand

It's nice to hear that <!-- s:D --><img src="{SMILIES_PATH}/icon_biggrin.gif" alt=":D" title="Very Happy" /><!-- s:D --> I've got some links I wanted to share with the team, they've some information on path nodes AI (not exactly path nodes, but it could be used for that), I'll post the links here, if you are interested you can check them out, maybe they'll help you improve the current system or create a new idea for a simpler implementation <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->, hope they are useful, I was going to start my implementation from there. [url:3in15z46]http://ai-depot.com/Tutorial/PathFinding.html [url:3in15z46]http://ai-depot.com/BotNavigation/Path.html [url:3in15z46]http://minion.planetquake.gamespy.com//tutorial/main.htm [url:3in15z46]http://webdiee.cem.itesm.mx/web/servicios/archivo/tutoriales/protoboard/sld001.htm
Sun, 28 Jan 2007 13:39:13

Crimson Wizard

Great, I am going to read these just now!
Sun, 28 Jan 2007 21:06:58

Firebrand

[quote="Crimson Wizard":74qa0mku]Great, I am going to read these just now! Sounds cool! <!-- s8) --><img src="{SMILIES_PATH}/icon_cool.gif" alt="8)" title="Cool" /><!-- s8) --> I'm glad you found these useful <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->.
Mon, 29 Jan 2007 08:10:50

Crimson Wizard

Well, first two links can be very helpful, 3rd is for QuakeC and many things that are desribed in that tutorial are either already implemented in KA or could be implemented with ease using our own wits <!-- s;) --><img src="{SMILIES_PATH}/icon_wink.gif" alt=";)" title="Wink" /><!-- s;) --> The 4th link was surprising for me because it is on spanish (?) and it seemed to me that it is not about pathfinding, but electroniks <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) --> .
Mon, 29 Jan 2007 14:17:50

Firebrand

Haha! I did copied them from a TXT file I made at the office some time ago, it surely had a link to my homework about electronic circuits, hahaha! <!-- s:lol: --><img src="{SMILIES_PATH}/icon_lol.gif" alt=":lol:" title="Laughing" /><!-- s:lol: -->
Mon, 29 Jan 2007 15:12:37

doomjedi

Donnow about enemy AI, but bot AI in Arena is awful, they get stuck. Also they get stuck at respawn spots (like in the Docks), don't know why, maybe because of low ceiling. The same with the Maulotaur.
Mon, 29 Jan 2007 15:32:34

Crimson Wizard

I haven't explored bot AI code much earlier, I generally worked on interface and game mode logic, but now I'm going to study this area and fix & enhance what I can.
Mon, 29 Jan 2007 16:06:26

Firebrand

[quote="doomjedi":snt0bi0r]Donnow about enemy AI, but bot AI in Arena is awful, they get stuck. Also they get stuck at respawn spots (like in the Docks), don't know why, maybe because of low ceiling. The same with the Maulotaur. That's why we are planning some work on improving it, it's not very easy to create AI from scratch, fortunately, there's some information on what we want to do in the links I posted before (except the electronics one <!-- s:P --><img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz" /><!-- s:P -->).
Thu, 22 Feb 2007 08:11:05

Crimson Wizard

I have completed node graph building long ago, and I almost implemented path computations alhgorythm, but.. argggghhhh... no free time at all <!-- s:( --><img src="{SMILIES_PATH}/icon_sad.gif" alt=":(" title="Sad" /><!-- s:( -->. I can only hope I will be able to return to the work on this weekends.
Thu, 22 Feb 2007 19:16:23

Firebrand

No problem, I'm researching different path searching algorithms myself, I didn't know there were so many of them, they all suit for different things, the one I found that seems the best for KA is the A* algorithm (A Star path finding algorithm). I'll think about how to implement it for the bots, I'm sure the graph building stuff you did will be useful for this task <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->.
Mon, 26 Feb 2007 11:47:40

Crimson Wizard

I am going to get back to this in following days. In fact, A* algorythm is exactly what I was working on - <!-- m --><a class="postlink" href="http://ai-depot.com/Tutorial/PathFinding-Optimal.html">http://ai-depot.com/Tutorial/PathFinding-Optimal.html</a><!-- m --> since it is called "Optimal Search Method" there <!-- s;) --><img src="{SMILIES_PATH}/icon_wink.gif" alt=";)" title="Wink" /><!-- s;) --> Don't you know if Janis is going to add dynamic arrays to Vavoom? Currently there are two ways - 1) to use static array large enouph to give a space for a good-length path, 2) to use strings, since they are only dynamic array in VavoomC for now. I've chosen second. I think it is not that bad to put indices of nodes as string's chars, at least this should work for the first time. Then, what is important, I am putting pathfinding AI into Pawn class, not Bot class, since this technique should be the same for all the creatures in game. Secondly I added new struct to Pawn class, called it Behavior. It can be used to define creature's... behavior <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) --> Currently I used it to store some parameters for path calculations like frequency of recalculation, how much time monster will wait until using pathfinding when he've lost an enemy etc. We may add many more additional parameters there if needed.
Mon, 26 Feb 2007 12:59:02

RambOrc

Sounds good. Whatever you do on AI, always think on how it could be used in the RPG.
Mon, 26 Feb 2007 14:55:20

Firebrand

You can ask him about adding dynamic arrays yourself in the features forum of the Vavoom engine, AFAIK, he was working on fixing how global ACS variables are stored in memory and savegames, I'm not very sure how much he had finished, anyway, what you've done so far sounds cool, I don't see any problems with making nodes to use strings for what we want to do neither, I think we can use this to make all kind of tests for monster AI, I remember Ramborc said some time ago that certain monster behaviors needed some changes <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->, I already have some ideas myself, like making monsters know when other monsters are attacking, so they get out of the way instead of blocking the attack and going back to hit their allies <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->. I also had some questions regarding the football gameplay mode and bots, but I'll ask this later, right now I should get to start studying for my today's exam <!-- s:( --><img src="{SMILIES_PATH}/icon_sad.gif" alt=":(" title="Sad" /><!-- s:( -->.
Mon, 26 Feb 2007 15:11:16

Crimson Wizard

[quote="Firebrand":k0bzlkec]I already have some ideas myself, like making monsters know when other monsters are attacking, so they get out of the way instead of blocking the attack and going back to hit their allies <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->. ...heh, sounds crazy, but this may be interesting <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) --> But what about make them not shoot in case their ally stands on the line of fire? I suppose that can be easy to do.
Mon, 26 Feb 2007 20:13:35

Firebrand

Yes, it's another way of doing the same thing, but it would be better to combine both of the techniques and see what happens, heh! <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->.
Sun, 04 Mar 2007 08:27:30

doomjedi

Sounds like better AI has a hope
Tue, 13 Mar 2007 10:23:33

Crimson Wizard

Hey!! I got this working! <!-- s:P --><img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz" /><!-- s:P --> Has some glitches though, looks like I messed up with the strings which I use to store node indices and path lengths as formatted string ... I also need to test this on medium sized map to know how it slows down the game. Then I'll be implementing this straight into Arena.
Tue, 13 Mar 2007 16:26:55

Firebrand

Sounds cool! <!-- s8) --><img src="{SMILIES_PATH}/icon_cool.gif" alt="8)" title="Cool" /><!-- s8) -->
Sun, 18 Mar 2007 20:45:17

Crimson Wizard

Dammit, it works, but too slow. <!-- s:-( --><img src="{SMILIES_PATH}/icon_sad.gif" alt=":-(" title="Sad" /><!-- s:-( --> I think that because I use strings as arrays. I'll try to make dynamic list class instead, but for now I am quite pessimistic about the whole thing.
Wed, 21 Mar 2007 11:58:35

Crimson Wizard

Well, huh, nothing helps to removes its slowness completely. I can only guess that main reason is what Janis had mentioned once - that vavoomC is an interpreted language. Probably if this method was be implemented in engine it would work faster. Perhaps for now I'll make pawns simply USE nodes without pre-calculating complete route, a bit like bots do in KA, but with some enhancements. Plus there's still an idea of node paths - groups of nodes linked in long pathways, those may greatly decrease time of route calculating, although they are not so universal as a node graph.
Wed, 21 Mar 2007 16:28:26

Firebrand

The complexity of the path building algorithms is much, so I'm not very surprised that it's slow, I also think it's because of the very same reason you mention here, I don't know if implementing the methods directly on the engine would help much (Janis would have to see the code and give a word about it).
Wed, 21 Mar 2007 17:15:17

RambOrc

Once again the same as for dynamic lights, anything that needs to be pre-rendered any time a level is loaded is pretty much out for the Korax RPG as very fast map load times are an absolute must (games like Hexen II or Postal 2 have been screwed big way by too long load times between maps in a game where you hop between maps all the time).
Thu, 22 Mar 2007 09:34:20

Crimson Wizard

No, RambOrc, node graphs are built rather fast, plus I am sure they will be stored in memory as all the dynamic level data in the bounds of one hub. What is the problem is calculating routes for monsters to reach their target.
Thu, 22 Mar 2007 14:19:23

Firebrand

Path building is a slow process by definition, because it requires a lot of calculations, it's not very easy to notice what to modify in the code to make it faster <!-- s:? --><img src="{SMILIES_PATH}/icon_confused.gif" alt=":?" title="Confused" /><!-- s:? --> , and again, I'm not sure if implementing this directly on the engine would help anyhow.
Thu, 22 Mar 2007 16:35:58

Crimson Wizard

Ok, I'll try different approaches then.
Fri, 24 Aug 2007 00:02:39

Crimson Wizard

Well, I should be careful in prognosis here (professional pessimism), but it seems i have some good news. I just finished rewriting node graphs building and route calculation for latest progs (based on doom2 once again) and tested them for a while. There appeared some minor glitches, that I thought I fixed long ago in previous version, but that's not important; what's important is that I experience almost no slowdowns on the test maps I used for previous version. Since I am using same machine, that means that Janis really improved engine speed; and this fact gives some real hope. <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->
Fri, 24 Aug 2007 14:49:48

Firebrand

Yes, I've been testing KA on my slow laptop and I must say I'm impressed by the results, I can at least play the smaller maps without any real problems <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->, which talks about the stability of the engine and the speed improvements. I'm in the process of finishing configurations for a second desktop machine, I was doing cleaning on my old hardware stuff and found a Celeron processor that didn't had any motherboard, so I made a few phone calls and got a motherboard for it <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->, my brother bought a new monitor too, so now we are completing this new machine, once that's done I'll be able to play LAN games and test a few other things I want before the final release <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->. Now, returning to the topic, I think that if we make this work properly we'll have one of the limits gone for Korax RPG <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->, keep up the great work Crimson Wizard! <!-- s8) --><img src="{SMILIES_PATH}/icon_cool.gif" alt="8)" title="Cool" /><!-- s8) -->
Sat, 25 Aug 2007 14:40:03

Crimson Wizard

Here's archive with my mod and a test maps: <!-- m --><a class="postlink" href="http://downloads.orcishweb.com/koraxdev/koraxrpg/aiExperiment.zip">http://downloads.orcishweb.com/koraxdev ... riment.zip</a><!-- m --> I need someone to test this on slow machine.
Sat, 25 Aug 2007 18:12:29

Firebrand

I'll test it out on my slow laptop and give you feedback on it <!-- s;) --><img src="{SMILIES_PATH}/icon_wink.gif" alt=";)" title="Wink" /><!-- s;) -->.
Thu, 30 Aug 2007 10:10:50

Crimson Wizard

So, Alex_bomberman tested this at last, and said it was good <!-- s;) --><img src="{SMILIES_PATH}/icon_wink.gif" alt=";)" title="Wink" /><!-- s;) --> Anybodu else?
Thu, 30 Aug 2007 14:49:47

Firebrand

I've made some tests in both of my computers, I can notice a small slowdown on my laptop, but it's nothing of importance really, you can still play properly, which is IMO more than enough <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->, I think it's a great addition for AI of the engine, nice work! <!-- s8) --><img src="{SMILIES_PATH}/icon_cool.gif" alt="8)" title="Cool" /><!-- s8) -->
Thu, 30 Aug 2007 14:55:57

Crimson Wizard

Heh, good to hear that. I set pathfinding aside (there could be some improvements done, but it's already good enouph for now) and work on Actor Tasks. Currently I managed to implement two basic tasks - 'stand still' and 'attack all'. 'Stand still' makes monster to stop and stand in idle state for some time, even if he sees enemy. 'Attack all' is really brutal, it makes monsters attack nearest living entities continiously. I had some fun, starting different Doom2 levels and sending this command to everyone on map at once. Soon after level becomes one bloody battlefield <!-- s:P --><img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz" /><!-- s:P -->
Thu, 30 Aug 2007 23:24:24

Firebrand

Sounds good <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->, I think it will make things like helping NPC's a reality for Korax RPG, I think it's a nice feature too.

Back to the Korax Forum Archives