Castle Paradox Forum Index Castle Paradox

 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
 Gamelist   Review List   Song List   All Journals   Site Stats   Search Gamelist   IRC Chat Room

A.I please

 
Post new topic   Reply to topic    Castle Paradox Forum Index -> The Arcade
View previous topic :: View next topic  
Author Message
Battleblaze
Warrior Thread Monk




Joined: 19 Dec 2003
Posts: 782
Location: IndY OHR

PostPosted: Tue Jun 13, 2006 6:29 pm    Post subject: A.I please Reply with quote

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
View user's profile Send private message Visit poster's website AIM Address
TMC
On the Verge of Insanity




Joined: 05 Apr 2003
Posts: 3240
Location: Matakana

PostPosted: Wed Jun 14, 2006 4:38 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
Ysoft_Entertainment
VB Programmer




Joined: 23 Sep 2003
Posts: 810
Location: Wherever There is a good game.

PostPosted: Wed Jun 14, 2006 4:49 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
Camdog




Joined: 08 Aug 2003
Posts: 606

PostPosted: Wed Jun 14, 2006 6:22 am    Post subject: Reply with quote

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
View user's profile Send private message
Moogle1
Scourge of the Seas
Halloween 2006 Creativity Winner
Halloween 2006 Creativity Winner



Joined: 15 Jul 2004
Posts: 3377
Location: Seattle, WA

PostPosted: Wed Jun 14, 2006 8:06 am    Post subject: Reply with quote

"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
View user's profile Send private message Visit poster's website AIM Address
Bob the Hamster
OHRRPGCE Developer




Joined: 22 Feb 2003
Posts: 2526
Location: Hamster Republic (Southern California Enclave)

PostPosted: Wed Jun 14, 2006 12:47 pm    Post subject: NPC AI scripts Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
Mike Caron
Technomancer




Joined: 26 Jul 2003
Posts: 889
Location: Why do you keep asking?

PostPosted: Wed Jun 14, 2006 3:29 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
Battleblaze
Warrior Thread Monk




Joined: 19 Dec 2003
Posts: 782
Location: IndY OHR

PostPosted: Thu Jun 15, 2006 6:56 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website AIM Address
TMC
On the Verge of Insanity




Joined: 05 Apr 2003
Posts: 3240
Location: Matakana

PostPosted: Sat Jun 17, 2006 5:52 pm    Post subject: Reply with quote

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 Raspberry!
_________________
"It is so great it is insanely great."
Back to top
View user's profile Send private message Send e-mail
Mike Caron
Technomancer




Joined: 26 Jul 2003
Posts: 889
Location: Why do you keep asking?

PostPosted: Sun Jun 18, 2006 11:57 am    Post subject: Reply with quote

The Mad Cacti wrote:
Mike Caron wrote:
*snip*


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 Raspberry!


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
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
Display posts from previous:   
Post new topic   Reply to topic    Castle Paradox Forum Index -> The Arcade All times are GMT - 8 Hours
Page 1 of 1

 
Jump to:  
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