 |
Castle Paradox
|
View previous topic :: View next topic |
Author |
Message |
Battleblaze Warrior Thread Monk

Joined: 19 Dec 2003 Posts: 782 Location: IndY OHR
|
Posted: Tue Jun 13, 2006 6:29 pm Post subject: A.I please |
|
|
Well before I woulden't have considered asking. But now since were in the new age of windows where anything is possible. Could we get scripted NPC movements seperate from other scripts.
For Example
In Adventures Of BattleBlaze* where I had a zelda type battle system.I found myself wishing that my enimies could do more than simply "chase player" and run a simple "touch" script. I just wish that I could be running the attacking script while seperate miniscripts can direct how the enimies move. What would be prime is NPC's responding to things like how close the player is or what script he just activated.
You could attempt this with the current system. But with the 1 script at a time limit it'd be buggy as heyell
*Was destroyed by hardrive wipe of 05 _________________ Indy OHR! and National OHR Month Contest going on now!
"Aeth calls PHC an anti-semite; PHC blames anti-semitism"
-squall |
|
Back to top |
|
 |
TMC On the Verge of Insanity
Joined: 05 Apr 2003 Posts: 3240 Location: Matakana
|
Posted: Wed Jun 14, 2006 4:38 am Post subject: |
|
|
Hey, that sounds like a neat idea indeed. An "each tick" script available on NPCs would have many uses besides just movement. That is the way things are done in GM, and it also is a way to get around the "only one script at once" problem.
However, there might be problems to sort out, such as what happens when one of those scrpts waits? Depending on the answer, it might only become possible after a restructure of scripts. _________________ "It is so great it is insanely great." |
|
Back to top |
|
 |
Ysoft_Entertainment VB Programmer

Joined: 23 Sep 2003 Posts: 810 Location: Wherever There is a good game.
|
Posted: Wed Jun 14, 2006 4:49 am Post subject: |
|
|
Why stop at npcs? why not implement it in maps as well? _________________ Try my OHR exporter/importer.
OHRGFX
Striving to become better pixel artist then Fenrir Lunaris. Unfortunately the laziness gets in the way of my goals. |
|
Back to top |
|
 |
Camdog
Joined: 08 Aug 2003 Posts: 606
|
Posted: Wed Jun 14, 2006 6:22 am Post subject: |
|
|
Can't this already be done with a looping on map load script that just runs through all the npcs? I don't see why that would be buggy. |
|
Back to top |
|
 |
Moogle1 Scourge of the Seas Halloween 2006 Creativity Winner


Joined: 15 Jul 2004 Posts: 3377 Location: Seattle, WA
|
Posted: Wed Jun 14, 2006 8:06 am Post subject: |
|
|
"each tick" per NPC is a very good idea. You can set it up so that scripts with wait commands are not allowed, since by definition these would crash the game. These should be able to pass in the NPC's reference.
"each tick" per map seems unnecessary, since background scripts already do this. _________________
|
|
Back to top |
|
 |
Bob the Hamster OHRRPGCE Developer

Joined: 22 Feb 2003 Posts: 2526 Location: Hamster Republic (Southern California Enclave)
|
Posted: Wed Jun 14, 2006 12:47 pm Post subject: NPC AI scripts |
|
|
The ability to have a separate NPC AI script that runs once each tick for each NPC instance would be pretty darn cool... although I suspect that the performance would be terrible.
It would actually not be very difficult to implement, so we can just try it out and see how it works. (if it turns out to suck, we just won't commit it) |
|
Back to top |
|
 |
Mike Caron Technomancer

Joined: 26 Jul 2003 Posts: 889 Location: Why do you keep asking?
|
Posted: Wed Jun 14, 2006 3:29 pm Post subject: |
|
|
You know what else we need, which is mostly related to this? Pseudo-threads (henceforth refered to as threads).
Threads in the style of Stackless Python (eh, James? Got your attention? Good.) where scheduling is as easy as "a thread runs until it terminates or goes into waiting, then the next thread is run". A thread would be defined as a script called from a distinct trigger.
For those not in the know of how the OHR deals with multiple scripts (say, double-triggering a script), it basically sticks everything onto a giant stack. If a new script is triggered while another is running (well, sleeping, anyway), it's stacked on top, and the first script has to wait until the second goes away before it can run again, kind of like a function call.
However, this way, each script can run "side-by-side". They still have to take turns (real threading would be a nightmare with too many pitfalls, and too little benefit), but instead of the first script sleeping until the second script is finished, it only sleeps until the second script is sleeping itself.
Naturally, this fits in with the NPC movement scripts in that each tick, a thread is spawned from an NPC.
I can't imagine this would be too difficult to do (main problem being dealing with the various buffers and stuff), and would have tremendous benefit.
=====
That said, this npc tick script would be a horrible way of dealing with custom movement. It would mean that you'd have to micromanage the movement, pixel-by-pixel, and use globals to keep track of NPC state. No, that blows. NPC Tick is a good idea, but for different reasons.
Instead, I'd like to see movement scripts built in, and created like this:
Code: |
#n is the npc
stop movement(n) #if the npc is moving, halt it
clear movement(n) #clear the movement script
queue movement(n, up, 2)
queue movement(n, left, 1)
queue movement(n, move:wait, 10) #ticks
queue movement(n, move:label, 1)
queue movement(n, move:hero, 2) #2nd hero
queue movement(n, move:jump while tag, 1, tag:chase) #to label, while the tag is on
queue movement(n, move:end) #stop moving
start movement(n) #run script
|
Or something. This script would cause the npc to move north 2 tiles, west 1 tile, wait for 10 ticks, and then chase the 2nd hero slot. The label and the jump make the npc chase the hero while the tag "tag:chase" is true. When the tag is false, it skips the jump, and hits the end command, which tells the npc to stop moving (instead of looping back to the beginning of the script)
(Aside: Yes, those are virtual op-codes for npc movement)
I imagine that the interpreter part of this would be easy (or, rather, not difficult), and the interface seems intuitive (well, for me, anyway). _________________ I stand corrected. No rivers ran blood today. At least, none that were caused by us.
Final Fantasy Q
OHR Developer BLOG
Official OHRRPGCE Wiki and FAQ |
|
Back to top |
|
 |
Battleblaze Warrior Thread Monk

Joined: 19 Dec 2003 Posts: 782 Location: IndY OHR
|
Posted: Thu Jun 15, 2006 6:56 am Post subject: |
|
|
I thought I'd be laughed out of town. Looks like I said something to get things moving *pats own back and gets back to work*
Now zelda style games will be 10x better with enimies that do...stuff. If used right this could change much of OHR forever. I presume a new wave of 'action' RPGs would be much easier to create. _________________ Indy OHR! and National OHR Month Contest going on now!
"Aeth calls PHC an anti-semite; PHC blames anti-semitism"
-squall |
|
Back to top |
|
 |
TMC On the Verge of Insanity
Joined: 05 Apr 2003 Posts: 3240 Location: Matakana
|
Posted: Sat Jun 17, 2006 5:52 pm Post subject: |
|
|
Mike Caron wrote: | You know what else we need, which is mostly related to this? Pseudo-threads (henceforth refered to as threads).
Threads in the style of Stackless Python (eh, James? Got your attention? Good.) where scheduling is as easy as "a thread runs until it terminates or goes into waiting, then the next thread is run". A thread would be defined as a script called from a distinct trigger.
For those not in the know of how the OHR deals with multiple scripts (say, double-triggering a script), it basically sticks everything onto a giant stack. If a new script is triggered while another is running (well, sleeping, anyway), it's stacked on top, and the first script has to wait until the second goes away before it can run again, kind of like a function call.
However, this way, each script can run "side-by-side". They still have to take turns (real threading would be a nightmare with too many pitfalls, and too little benefit), but instead of the first script sleeping until the second script is finished, it only sleeps until the second script is sleeping itself.
|
I like this idea of pseudo-threads alot. Of course, it would have to be off by default, and people might even need to relearn some scripting. On the other hand, in some case it would be more logical.
There will also be issues to work out, such as making the order in which different threads are executed each tick logical.
Mike Caron wrote: |
That said, this npc tick script would be a horrible way of dealing with custom movement. It would mean that you'd have to micromanage the movement, pixel-by-pixel, and use globals to keep track of NPC state. No, that blows. NPC Tick is a good idea, but for different reasons.
|
We could have an alternative trigger (use one or the other or none) then: an each step script for npcs.
Also, I suggest that if the each step/tick script waits, then next time it is triggered (from the same trigger), a new thread would not be spawned, instead the old one would be woken up. In addition, the waiting thread would not be run each step by default.
But.. what if people do want to wake one tick? Maybe they want to do a little animation. Ok, how about a new wait command instead, which waits until the next time that script is triggered.
Now you don't need to use global variables anymore.
Here's what I mean:
Code: |
script, sleepy wander, npc, begin
variable (sleepiness)
sleepiness := 400
while (sleepiness << 1000) do, begin
if (random (0, 1200) >> sleepiness) then (
walk npc (npc, random (0, 3), 1)
) else (if (random (0,30) == 0) then (#yawn))
sleepiness += 1
wait for trigger
end
#walk home, goto sleep
while (1) do (wait for trigger) #stop responding (alternatively, set trigger script id to 0)
end
|
Mike Caron wrote: |
Instead, I'd like to see movement scripts built in, and created like this...
|
That seems really out there. Maybe bring it up again in half a year  _________________ "It is so great it is insanely great." |
|
Back to top |
|
 |
Mike Caron Technomancer

Joined: 26 Jul 2003 Posts: 889 Location: Why do you keep asking?
|
Posted: Sun Jun 18, 2006 11:57 am Post subject: |
|
|
The Mad Cacti wrote: |
I like this idea of pseudo-threads alot. Of course, it would have to be off by default, and people might even need to relearn some scripting. On the other hand, in some case it would be more logical. |
Some cases? I can't think of any case where an on-step script halting an npc-trigger script is better.
The Mad Cacti wrote: | There will also be issues to work out, such as making the order in which different threads are executed each tick logical. |
Perhaps, but "in the order they were started" seems good to me.
The Mad Cacti wrote: | Mike Caron wrote: |
That said, this npc tick script would be a horrible way of dealing with custom movement. It would mean that you'd have to micromanage the movement, pixel-by-pixel, and use globals to keep track of NPC state. No, that blows. NPC Tick is a good idea, but for different reasons.
|
We could have an alternative trigger (use one or the other or none) then: an each step script for npcs. |
I don't follow.
The Mad Cacti wrote: | Also, I suggest that if the each step/tick script waits, then next time it is triggered (from the same trigger), a new thread would not be spawned, instead the old one would be woken up. In addition, the waiting thread would not be run each step by default.
But.. what if people do want to wake one tick? Maybe they want to do a little animation. Ok, how about a new wait command instead, which waits until the next time that script is triggered.
Now you don't need to use global variables anymore.
Here's what I mean:
Code: |
script, sleepy wander, npc, begin
variable (sleepiness)
sleepiness := 400
while (sleepiness << 1000) do, begin
if (random (0, 1200) >> sleepiness) then (
walk npc (npc, random (0, 3), 1)
) else (if (random (0,30) == 0) then (#yawn))
sleepiness += 1
wait for trigger
end
#walk home, goto sleep
while (1) do (wait for trigger) #stop responding (alternatively, set trigger script id to 0)
end
|
|
Mm, yes. Wait for trigger would be a nice way of dealing with this.
The Mad Cacti wrote: | Mike Caron wrote: |
Instead, I'd like to see movement scripts built in, and created like this...
|
That seems really out there. Maybe bring it up again in half a year  |
Perhaps, but what is innovation without being ahead of the game? _________________ I stand corrected. No rivers ran blood today. At least, none that were caused by us.
Final Fantasy Q
OHR Developer BLOG
Official OHRRPGCE Wiki and FAQ |
|
Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|