This discussion is archived
2 Replies Latest reply: Feb 23, 2013 7:35 AM by 668085 RSS

Faking threads (scripting)

668085 Newbie
Currently Being Moderated
I'm writing a game and trying to think of a good way to handle complex scripted animation.

Right now the main game loop looks like:
while (true)
{
     for (LevelObject obj: levelObjects)
     {
          obj.performGameLogic();
     }

     drawLevel();
}

Right now performGameLogic() is hard coded per object and does something simple like cause the game object to slowly walk back and forth while updating the sprite animation. However, I'd like to do something more complex. It would be nice if I could write something like:

class Monster extends GameObject
{
     public void performGameLogic()
     {
          takeStep(Direction.DOWN);
          takeStep(Direction.LEFT);
          if (chest5.isClosed())
          {
               chest5.openChest();
          }
          playAnimation("BeatChest");
     }
}

The trouble with this is that most of the above commands will require several hundred milliseconds to complete (and animate). They should also play sequentially - one after the other. However, the main thread needs to return almost immediately to perform the rest of the game logic and draw the level.

It would be better if I could somehow encapsulate this in a 'thread'. Each time performGameLogic() was called, it would advance this 'thread' as far as it could and then return. (Ie, the 'thread' would run until it blocks, waiting for time to have elapsed or some state to be set.) When performGameLogic() was called again, the 'thread' would pick up again from where it left off and run until it blocks again.

Using real threads to do this would be expensive. I was wondering if there might be some clever way to create this thread-like behavior with arbitrary code.

(At the moment, I have a solution where I create Animation objects and link them together. Each Animation has an advanceLogic() method that is called to advance its state and which will fire an event when it completes. A listener will then detect this event and schedule the next Animation object. While this works, it is tedious and unintuitive.)
  • 1. Re: Faking threads (scripting)
    gimbal2 Guru
    Currently Being Moderated
    You're creating a busy loop, that will make your CPU (or one of the cores) go to 100% usage which is a killer to power consumption and noise and heat production. I advise you to visit java-gaming.org and go through he different articles you can find there to learn all about how to do game loops with a steady tick rate (the commonly used term "FPS").
    The trouble with this is that most of the above commands will require several hundred milliseconds to complete (and animate).
    Well you'll have to fix that problem. A single frame of your game should be able to complete in around 20-25 milliseconds to get a smooth and steady update of 50-60 frames per second, if it takes so long to do stuff you have a serious performance issue that will kill any chance of you creating a game that moves fluently and has a decent response time to input actions. So you'll have to dig deep: WHY is it taking so long to do basic drawing stuff? I'm guessing it has something to do with improper use of transparency, but I can only guess when you don't share what technology you're using to do the actual drawing of graphics.
  • 2. Re: Faking threads (scripting)
    668085 Newbie
    Currently Being Moderated
    The problem isn't that the drawing code is too slow (I'm actually drawing about 1000 FPS and using mostly Graphics.drawImage()). The problem is that animations are time restricted. It is going to take several hundred milliseconds for my monster character to take a step because otherwise the player would not see it. So the game thread can at most update the monster to it's next frame, then exit and wait until the next call before continuing. I'm trying to think of an easy way to script a complex chain of these events.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points