🔒 Locked

Script Engine vs Quick Loops

Started by Spacecat May 14, 2003 at 9:54 AM 7 replies 1.3k views

Original Post

May 14, 2003 at 9:54 AM

Okay guys, this is a design question. Premise #1: We have a game engine that repeatedly calls a quick-exit loop. Said loop does one general Update() call and one general Render() call. Nothing new so far. We''d like to keep it in this format as the core has proven pretty tough and alt-tab friendly. Premise #2: We''re about to integrate a script engine, as the game will pretty much be an adventure game. Our problem: Since the main call of the game is a must-be-quick-exit function, we can''t use the usual method with script engines which is to have the script engine control the loop and occasionally call ''CheckWinMessages'' or whatnot. I''d like to hear from everyone who''ve used script engines, or made adventure games. Are there solutions out there for this particular problem? We''re thinking we could use tons of messages and turn the script engine into more of a ''Message handler'' for our situations. Are there any other ideas out there? =^.^= Leaders and teachers should remember: It is best to offer others what they Need, not what they Want.

Endurion

May 14, 2003 at 10:08 AM

You could look into Lua (5.0) and use its coroutine concept. It will allow you to have scripts stopping and being resumed (from the script side). It just needs a good design from the start then it''s a piece of cake.

Ready4Dis

May 14, 2003 at 10:21 AM

You could always create a second thread, and do the scripting stuff in there. Or, just call UpdateScript(); in your main loop and have it do what it needs to in there.

Spacecat

May 14, 2003 at 10:53 AM

Before I go and have to read a whole documentation about Lua, can you -explain- to me the concept of this CoRoutine thing?
You see, we''re a little late in the schedule, so we''re not going to explore multithreading (sorry about that, but the idea had potential, I suppose) and it''d be tricky to take the time to evaluate Lua or Python. So I''m looking for ''concepts'' rather than implemented solutions.

I''m trying to think up of an example problem... Let''s say we got Animation A (character picking up object), which is supposed to be followed by Animation B (Character looking around for owner) and a condition that if he clicks on area C, something happens.

In a script it might look like this:
Character.DoAnim("A")
Character.TakeObject("Object")
Character.DoAnim("B")
if Click("C") (SomethingHappens())

This obviously wouldn''t work in quick-exit mode. If we turn the script engine into a ''Message Handler'' it''d look like this I assume:

  
On_Animation_End(){
   if Character.LastAnim="A" {
      Character.StartAnim("B")
      Character.TakeObject("Object")
   } elseif Character.LastAnime="B"{
      ReadyForSomething=true;
   }
}
On_Click(){
   If LastClick="C" AND ReadyForSomething=true SomethingHappens()
}

That''s why I figure the ''message handler'' method could work. But any other ideas out there?

=^.^= Leaders and teachers should remember: It is best to offer others what they Need, not what they Want.

xEricx

May 14, 2003 at 3:05 PM

Hi!

You might want to take a look at the Virtools Engine.

We have 3 profesionnal adventure games developped with this engine (Road to India, Syberia and Post-Mortem) and we''re currently developping Syberia 2 with it.

Each call, like play animation, would be represented as a building block. A block can be active for 1 or more frames, executing chunks of it''s whole process, and output once its done. I think that''s one of the easiest script engine to use and it definitely fits adventure games needs.

If you have any question, feel free to mail me.

Eric

Endurion

May 15, 2003 at 7:57 AM

AP explained it very good already.

Basically you''ll need scripting blocks, not a complete script.
Coroutines enable you to "cut" the script at certain places and be able to resume at the exact position later on.

Spacecat

May 15, 2003 at 8:41 AM

Got the concept of the Coroutine method.

Thanks all. It does seem that it enables a script engine to be a little more ''quick exit'' without having to move to a full-scale split-up finite state machine.

...Now if we can just get our artistic VP to stamp our minigames as ''approved'' *muttergrumblewalksoff* (J/K)...

=^.^= Leaders and teachers should remember: It is best to offer others what they Need, not what they Want.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.