Scenes and movement

[Louisiana Night]

I was just wondering, is it extremely hard to make the characters move? Also roughly how many pages of programming are used for just one scene?

[Grundy]

For someone like myself or Allert... character movement is a breeze.

For someone with no 3d experience, they would need a few months of hard work to even get the basics worked out!

[Yonkey]

For someone like myself or Allert... character movement is a breeze.

Exporting that movement to Torque format on the other hand...  

Anyway, the animations are done beforehand in a 3D program such as Maya and exported to .dsq format.  Main characters has several .dsq files (i.e. walk, run, swim, etc.) which contain their animations.  As for NPC's, I'm not sure if they use .dsq's as well but they have far less work involved.  

Stepping outside of animation, there is a lot more involved in a scene, but again, for the most part, most of the visual work is done by the 3D Artists and just dragged-and-dropped into Torque.  Programming comes in by defining what happens when the characters interact with things (i.e. objects, other characters or other parts of the background).  It's hard to say in terms of pages how much code this is, since a lot of it is reused.  

[Allert van der Leij]

For someone like myself or Allert... character movement is a breeze.

Yeah, it's not to much work to set a couple of basic keyframes to make a decent walkcycle. But...

On the other hand, there is a reason they're called CHARACTERS. Basically what this means is, you can't just make a 'general' walkcycle for every character, since every character has a different background.

Look at people around you, none of them will walk the same, act the same etc... This has to do with age, emotions etc... So you see, there's a lot more at stake than just setting keyframes. But luckily there's enough reallife reference material around

[Allert van der Leij]

Exporting that movement to Torque format on the other hand...  

LOL  

[EDI]

We use a similar system in our game( at least as to what was hinted to).

However we've always found it hardest to actually choreagraph(sp?) the scenes, and to keep track of all the possible orders that scenes could happen, given the non-linear nature to certain puzzles or events, we handle that by scripting.

It is a very fun part of game development  

[Grundy]

Yes! Extremely fun!        

[Petter Holmberg]

Programming-wise, movement has proven a little challenging.

The animation is one thing, but once that's imported into Torque, you'd think it was easy to get the character to walk between point A and B.

However, this task is not at all trivial. The first problem is that Torque is designed with a keyboard interface in mind, and we're using a mouse interface. This means that walking needs to be based on where you click on the screen, and not what keys you press.

Torque can detect collisions between objects, so the character won't just move through a wall or something if you set it up correctly. But this also means that if you walk from point A to B you may not be able to walk in a straight line to get there, because there might be obstacles in the way. We don't want our heroes to look stupid by walking into stuff and getting stuck all the time just because the player clicks on destinations that are tricky to reach, so there has to be some intelligent pathfinding implemented that ensures that whoever you control on screen finds his/her way around obstacles. A lot of things are directly available to the programmer through Torque, which has allowed us to speed up the development process a lot, but this is an example of a situation where there were no off-the-shelf solutions available. At such times, it's up to us in the programming team to spit in our hands and get them dirty by adding functionality to Torque.

[mark_the_merry]

I'm in my trial period for joining the programming team and I think using torque has made me more confused in some ways (less confused in other ways though ) as to how you're (hopefully we're) going to get a king's quest style adventure game out of it.

My perception is that you would use the scripting to do most of the scene-type things like

if cmd == "use bucket of water on dragon" then animateGraham()?

And use the c++ code for modifying the fps style game into the point and click style implementing features such as handling mouse clicks, path determination, etc

posX += sin(y*z - 0.5)

??

[Yonkey]

You're pretty close.  It's more like:

Code Select Expand

switch (%cursor)
{
   ...
   case "Inventory":
   {
      if (%objectClickedOn == "dragon" && %cursorItem == "water")
      {

      //play sequence

      }
   }
}

Of course, this is just a simplified version of the code.  The actual code is way more modular.  It has object detection in one function, cursor detection in another, and scene-specific scripting in another, and sequence handling in another.

Petter made the path finding, but it's basically a walk graph with special target nodes.  Graham walks to the closest node that the user clicks on, by travelling the shortest path along this graph.

[GunHoMac]

I worked on the latest Tiger Woods 2005 implementing a best-path finder technique using a ray-trace arch.  Basically, you send out 2 ray traces to create a wedge of x-degrees, if the line-of-site is within the wedge then you proceed.

If not, then you expand or rotate the wedge and try again.  The line-of-site is not directly to the point of where the user clicked, but to a milestone/landmark point in the scene.  The point the user clicked is a dynamic landmark (volatile variable), so the path finder will continue tracing to the next landmark unless the destination point is closer.

Obstacle collision adds some difficulty, and you can either trace a path around the obstacle (if small enough), or setup an obstacle-ray-trace path similar to the main path finder above.

I'm sure they've managed to use the tools of Torque to simplify this for a point-and-click adventure, such as the walking map.

[mark_the_merry]

i've done a bit with 2d path finding and i imagine it's similar but more extensive in a 3d environment. I found that there was a lot of information available on different algorithms for 2d.

[Petter Holmberg]

Since we are dealing with fixed scenes here, where the user movement is limited by design (e.g. you can't walk around freely with the keyboard, hitting obstacles) and we also have full control of where potentially interfering objects, such as non-playable characters, in a scene can be located at any time, the pathfinding does not have to take into consideration the actual 3D geometry of the scenes. This is good news for us, because this would otherwise have been a very difficult problem to solve.

The walking implementation I devised has its strengths and weaknesses. It's limited in some situations but powerful in others. Basically, you define a directed graph, and you can walk along edges between the vertices in this graph. The vertices, which I call "walking nodes", are placed in the scene with 3D coordinates matching interesting locations for the player. Paths are calculated using Dijkstra's algorithm. A* would be applicable here, since there is always one target, but the graphs are usually very simple anyway.

Another potential solution would have been to define walkable areas by polygons, and allowing the player to move around freely inside them. This would be a bit more complicated to implement though, and have some disadvantages when we do walking in scripts, but it would allow more freedom of movement.

Our scene script system is still in development, and it's a lot of work. However, it allows for scenes to be scripted in an easy way. As previously explained, it's based on defining what will happen when the user interacts with the scene. For instance, you detect that the user clicks the look cursor on a door. Then you'd like to trigger a line of narrator speech. If the mouse cursor was instead the hand, you'd start a sequence of walking to the door, playing an opening animation and switching to another scene. Just as an example...

[GunHoMac]

I figured from your description earlier that Dijkstra's algorithm would probably be your design decision tool, and naturally it is.  Obviously, KQ9 is dealing with designers who have a well-configured implementation plan, and it's good to see someone actually putting to use all those damn algorithms we've been taught.  I'll get to work on using double integrals about the y=x axis for your next algorithm.