Free Roam World/No Load Time
by Michael Welch · in Game Design and Creative Issues · 03/29/2007 (5:02 pm) · 8 replies
I am trying to do some research before starting my first project. I am starting to design a platformer type game that is simpler, in theory, to some of the newer ones, but better than the originals.
I was wondering if Torque is able to supprt an imerssive world like the one found in Jak & Daxter, where there are no load times between areas.
I love the idea of free roam while still keeping that action packed platformer formula. I would like to atempt this in my game unless it is not going to be possible. I realize that it requires a lot of work on the art side but that seems to be my current strong suit.
If anyone has any comments or suggestions that my help in any way, please post.
Looking forward to hearing from all.
Mike
I was wondering if Torque is able to supprt an imerssive world like the one found in Jak & Daxter, where there are no load times between areas.
I love the idea of free roam while still keeping that action packed platformer formula. I would like to atempt this in my game unless it is not going to be possible. I realize that it requires a lot of work on the art side but that seems to be my current strong suit.
If anyone has any comments or suggestions that my help in any way, please post.
Looking forward to hearing from all.
Mike
About the author
#2
First off, I'm circumventing the normal datablock transmission mechanisms. Strictly speaking, datablocks do not have to be re-transmitted to the clients each and every time a mission is loaded. Skipping the deletion and re-transmisison of the datablocks removes an entire stage of the loading (at least after the first load).
If your game is single player (or if you just want a nice little reduction to loading times when hosting locally) you can also use a simple network-bypassing mechanism to greatly speed up the initial send of the datablocks. Basically, for the local client it just skips routing the datablock data through the network and uses a dummy stream to pack and unpack it locally. Net result is that it essentially makes the datablock send stage very, very short. On my system, the load screen is displayed at the datablock stage for a few frames at most.
The scoping and ghosting of objects are handled by the engine as is, but Torque's not going to like you loading up a massive amount of static scopealways objects (like trees and interiors and so on). I've rigged up a system of "zones", which are dynamically added to and removed from the mission based on where the player is and what he is doing (most likely you'd want this streaming in dynamically, to prevent briefs stalls when entering a new area, but I haven't gotten around to it yet).
Each of these zones is connected by a small transitional area -- to limit visibility and action-packed gameplay and allow objects in the next zone to load and be ghosted to the client. For example, I might use a narrow winding canyon that connects a beach and a hilltop area. There'd be relatively few objects in this area and no enemies. It's sole point would be to provide "cover" for the loading of a new zone behind the scenes.
Ideally, you'd want to bypass ghosting of static objects such as trees, rocks, and interiors and so on entirely. One method I've been experimenting with to do that is by using a local, cut-down copy of the mission file which contains only static objects that don't need to be networked in any way. When the mission loads, a quick CRC is used to determine if it's valid and then executes it -- immediately populating the client with the prerequisite scenery without having all the overhead of having to send the data over the network. (Oh, and it's easy enough to send the file across the network if the client doesn't have it...)
Of course, lighting's always going to be a problem -- especially with the lighting kit that was unfortunately added as stock to TGE 1.5. Even loading precached lighting results in a very noticeable stall in gameplay. At the moment I'm still working on a method to circumvent the issue, but until then all my levels just aren't using the lighting system (which makes them look a little uglier without the shadows and whatnot, but at least there's not a two or three second stall on entering a new area).
Anyway...
03/30/2007 (1:45 am)
I've been doing some similar stuff of late and I'm handling the problem in a number of ways.First off, I'm circumventing the normal datablock transmission mechanisms. Strictly speaking, datablocks do not have to be re-transmitted to the clients each and every time a mission is loaded. Skipping the deletion and re-transmisison of the datablocks removes an entire stage of the loading (at least after the first load).
If your game is single player (or if you just want a nice little reduction to loading times when hosting locally) you can also use a simple network-bypassing mechanism to greatly speed up the initial send of the datablocks. Basically, for the local client it just skips routing the datablock data through the network and uses a dummy stream to pack and unpack it locally. Net result is that it essentially makes the datablock send stage very, very short. On my system, the load screen is displayed at the datablock stage for a few frames at most.
The scoping and ghosting of objects are handled by the engine as is, but Torque's not going to like you loading up a massive amount of static scopealways objects (like trees and interiors and so on). I've rigged up a system of "zones", which are dynamically added to and removed from the mission based on where the player is and what he is doing (most likely you'd want this streaming in dynamically, to prevent briefs stalls when entering a new area, but I haven't gotten around to it yet).
Each of these zones is connected by a small transitional area -- to limit visibility and action-packed gameplay and allow objects in the next zone to load and be ghosted to the client. For example, I might use a narrow winding canyon that connects a beach and a hilltop area. There'd be relatively few objects in this area and no enemies. It's sole point would be to provide "cover" for the loading of a new zone behind the scenes.
Ideally, you'd want to bypass ghosting of static objects such as trees, rocks, and interiors and so on entirely. One method I've been experimenting with to do that is by using a local, cut-down copy of the mission file which contains only static objects that don't need to be networked in any way. When the mission loads, a quick CRC is used to determine if it's valid and then executes it -- immediately populating the client with the prerequisite scenery without having all the overhead of having to send the data over the network. (Oh, and it's easy enough to send the file across the network if the client doesn't have it...)
Of course, lighting's always going to be a problem -- especially with the lighting kit that was unfortunately added as stock to TGE 1.5. Even loading precached lighting results in a very noticeable stall in gameplay. At the moment I'm still working on a method to circumvent the issue, but until then all my levels just aren't using the lighting system (which makes them look a little uglier without the shadows and whatnot, but at least there's not a two or three second stall on entering a new area).
Anyway...
#3
03/30/2007 (5:17 am)
Daniel, I don't suppose you have some code snippets or links to resources involving that network bypassing mechanism? It would be great for my sp-RPG. :D
#4
03/30/2007 (6:30 am)
Gareth, there are a few ways to do this. However, this thread has some great code snippets.
#5
03/30/2007 (6:36 am)
Thanks Matt ;)
#6
Thanks again,
Mike
03/30/2007 (5:30 pm)
@Daniel -- Excellent information, thanks. This gives me a very good starting point to working things out. If you come up with fixes to those other problems and feel like sharing, please do.Thanks again,
Mike
#7
Load the new lightmap texture in a non-blocking thread before the user hits the border, and swap em.
03/30/2007 (5:44 pm)
Quote:
Of course, lighting's always going to be a problem -- especially with the lighting kit that was unfortunately added as stock to TGE 1.5. Even loading precached lighting results in a very noticeable stall in gameplay. At the moment I'm still working on a method to circumvent the issue, but until then all my levels just aren't using the lighting system (which makes them look a little uglier without the shadows and whatnot, but at least there's not a two or three second stall on entering a new area).
Load the new lightmap texture in a non-blocking thread before the user hits the border, and swap em.
#8
03/30/2007 (7:36 pm)
Hmmm.... That might work. I guess if the old lighting data and the new lighting data overlap and both cover the transitional area, you might even be able to head off any artifacts caused by the swap. I'll have a look into it after I finish this stupid trigger/spawn/callback system I'm writing... 
Torque Owner Matt Vitelli