Large worlds?

#61 The questions I have asked evolve around TGE mainly the mission, the terrain and operations on these two. What I would like and what I may have or not is not the issue. All I want to know is this - what is the capability of TGE in building a vast terrain as it exist in TGE v1.4.0!?

FACT One (from the official documentation):
Loading A Bitmap
I have purposely deferred a discussion of loading your own bitmaps till the end. Of all the questions I see asked over and over in the forums, one of the most repeated is, How do I load a bitmap as my terrain?. As you would imagine, doing this is relatively simple. Unfortunately, as checked in, the HEAD (and 1_2) versions of Torque are not set up to do this. You need to make the following change:
Locate the directory: example\common\editor
create a new sub-directory named: heightScripts (may be all lowercase for Unix)
From now on, if you want to use a bitmap for your terrain, just copy it to example\common\editor\ heightScripts before starting the SDK and it will be available. I say before because the SDK builds a list of the files in this directory when it loads, so adds that happen subsequently to starting the SDK will not be seen.
Please note, although loading a bitmap seems to imply a BMP you can only use PNG files.

Fact Two (does not exist)...

Thus am lacking general discussion in this area.

You mentioned:
"Having trigger points and pre-calculated lighting between missions would already go a long way. Adding the advanced camera resource for the Godview/Orbit Cam will up the viewpoint. And if you make your mission sizes smaller they will load faster, perhaps masking the trigger loading scheme based on how you work it. For example, if your trigger is well before the edge of the map, you can load the next map (they must be designed with this overlap in mind) and transfer your player to the new map and then delete the previous map. I doubt that this is stock, though, in terms of a mission base. I am just thinking of ways to un/load mission maps quickly and easily. Note that enemies will not cross the mission line in this simple scenario unless you specifically keep track of enemies that also activate triggers. But that's an even stickier topic."

Thank you for the information. If I infer you correctly, then yes, I can use multible missions to create my sub-maps that represent a world map. Also, at the same time, it seems that you are not sure of the capabilities of TGE. There must be more official information from GG to convey to us the capabilities and limitations.

The programmers of the terrain headers (8) and c++ sources (12) must know these answers. I cannot believe that this is inside information for the privilege.

Some of these questions are only general in nature.

I am not familiar with the games you have mentioned but I'll try to download some demos to see what you are talking about.

Many Thanks Jesse.

#62 The TGE terrain is a 256x256 heightfield (and slightly larger lightmap) tiled infinitely, with blended textures.

If you want larger terrains, Atlas in TSE is your best bet. We are not anticipating doing more than maintenance work/minor upgrades on the TGE terrain system at this point in time.

#63 I think we're getting lost in the word capabilities since I tend not to look at TGE (or any engine with complete source code) as an all-in-one out-of-the-box solution. I tend to base capability on the engine itself and the developers using it. If someone is learning C++ and trying to manage a huge codebase at the same time, they are lower on the capability scale when it comes to making the engine do what their specific needs are. If you want stock out-of-box capabilities, then the advanced camera resource does not come into play at all. You can used pathed cameras and triggers to shift your viewpoint (I believe the TLK demo did this as well as the feature demo included with the engine). Out of the box you can script the un/loading of levels via triggers.

You could link three maps together this way as a test. That way the "middle" map will allow you movement between two different maps (and presumably those two maps would allow movement back). This way you can prototype mission switching. Adding things like paths and signposts and such will help give the player a heads up that they are about to see a loading screen. If you make sure that your scene has been lit once, it will load much faster in the future as well since it will not have to recalculate lighting.

But if you are talking about one large, continuous world, then you will have to either do some heavy coding or work with TSE as Ben suggests.

#64 The problem with large worlds is also that you have to populate it or produce content.

Let's face it, you're an indie. It's both expensive and time consuming to produce content.

Remember: When a player joins your game, he won't be seeing alot of players, if any at all. If you spread out players even further with a huge world, multiplayer will suffer.

#65 @Ben and David

Chapter 4. Mission "Area" Editor Introduction

What is the purpose for the Mission Area? The documentation is not clear on this.

Jesse.

#66 @Stefan

"Let's face it, you're an indie." What does this mean?

I am evaluating....

Jesse.

#67 Indie

Quote:
Indie gaming refers to playing games, of any sort, that are created independently (hence "Indie") of the financial backing of a publishing company. These games generally have a small, or non-existent budget.

#68 @Stefan:

You're a funny person....

What does it mean in reference in asking questions?

Under the Indie Game License Agreement from GG, it Grants me to create a game, sell it and make a lot of money like you and we can be buddies because we make a lot of stinking money.

Jesse.

#69 The mission area is basically the boundary of the mission. There are a number of topic on turning off repeating terrain. To get an idea of the area bounds, turning off the repeatition might give you a good idea of the mission size. Then you can set your skybox to look like the various areas that you are moving to/from as well (which would mean a skybox for each area...but still, it could be nice).

#70 @Jesse:

I'm not trying to be funny. If you want to know the meaning of a statement, then don't quote it out of context. I honestly got the impression you didn't know the term indie so I looked up the Wikipedia article for you.

I'm afraid I can't make out the rest of your post. It doesn't seem like you're talking about the same thing I did.

#71 Stefan - Though there is a middle ground between Indie and Big Boy. What would you call that? Because my classic understanding of Indie is "self-published." What about self-published but having a budget to do a big world?

(Please note - not trying to be a smart ass here, genuinely curious because the lines are getting awful blurry these days)

#72 In the licensing sense, the indie and commercial Torque licenses are there so if you want to do certain things or if you make more than a certain amount of money you have to upgrade. The goal is to level the playing field for those with smaller budgets.

In the broader sense, there are plenty of studios that probably aren't "indie" that use Torque, and they're welcome to it.

I think what Stefan is trying to say is that if you don't have the backing of a major publisher, it's very very hard to produce a large, high quality, immersive world.

#73 Yeah, but I think my point is still valid... with the introduction of low cost solutions like Torque, Multiverse and so on, the line between indie and "not indie" is blurring significantly. Just because you don't have a major publisher doesn't mean it HAS to be very very hard to produce a large, high quality, immersive world. It still frequently will, but is not necessarily a guarantee.

#74 So far exactly one guy in the community has done it that we know of, despite lots and lots and lots of people coming through and stating it as their goal... so people here tend to assume things about how hard it is. ;)

#75 Fair enough....

#76 Terrain Plan for TGE:

I want to create a map using a large greyscale bitmap at approximately 700 pixels (height) by 1024 pixels (width). Then divide this large bitmap into 256 by 256 pixels with some overlaping (64 pixels). If I understand the Mission Area, the Player can be transferred from one mission to another by a callback to player::onLeaveMissionArea (Coding it so it would happen). The onLeaveMissionArea will be set within the 64 pixels overlap beyond the halfway mark of maybe 35 pixels so he would have to back up 6 pixels inorder to return to the same mission.

I will experiment with this idea. Any comments solely on the IDEA are welcomed.

Carpenter Software

#77 @David

You Had quoted:
"The mission area is basically the boundary of the mission." What does that mean?

There are two bounderies: The one set at squareSize and the MissionArea. The "mission" is set to the squareSize and the missionArea is set somewhere within the squareSize. I am NOT sure of these two and I need claification.

Thank you Jesse

#78 The mission area is a game specific feature that we got as legacy from Tribes 2, which is what TGE (back then V12) got started as : a code dump from Tribes 2 at release, minus the code that relied on third party licensed software, etc.
IIRC, upon leaving the mission area in T2, you would lose health (and energy ?) until you got back into the mission area.
Btw, the mission area can be set to an arbitrary size in the in-engine editors (F11 then F5, then click the Edit Area checkbox). Not sure if the necessay code is still in for you to use out of mission area conditions, as I've never had a need to use it on the projects I worked on using TGE
Hope ths helps,
Cheers, keep on torquin' !!!

#79 @Nicolas

I'm evaluating the terrain engine to find the best mechanism to switch among missions for a SinglePlayer Game. One experiment was moving the player in and out of the missionArea. The console only shows a player::onLeaveMissionArea callback. So this is workable for me.

For a multimission (large terrain via missions) I came up with this idea so I do not have to spend a lot of time creating terrian heightfields. Create a map using a large greyscale bitmap at approximately 700 pixels (height) by 1024 pixels (width). Then divide this large bitmap into 256 by 256 pixels with some overlaping (64 pixels). If I understand the Mission Area, the Player can be transferred from one mission to another by a callback to player::onLeaveMissionArea (Coding it so it would happen). The onLeaveMissionArea will be set within the 64 pixels overlap beyond the halfway mark of maybe 35 pixels so he would have to back up 6 pixels inorder to return to the same mission.

I have been asking questions so to find an automated way of switching missions (even hard coding the terrain sources) but no luck. The first thing I wanted is a continuous world...with paging similar to ROAM). I was impressed with the Game "Dungean Seige" and their terrain. There is a certain topic about how "Gas Powered Games" accomplished it -(http://www.drizzle.com/~scottb/gdc/continuous-world.htm). But TGE has a limitation in the terrain size so I am evaluating how the missions may be used in a SinglePlayer Game. If you may know by chance of such a mechanism, any advice would be appreciative.

Jesse.

#80 If you read that article carefully you'll realize that they wrote a completely custom method of streaming "nodes" based on character movement around the world, and this is not something that is coded in Torque.

You will not get seamlessly loading (otherwise known as paged) terrain movement in stock Torque Game Engine (note that Torque Shader Engine utilizes a completely different terrain system called Altas that allows for very very large worlds) without quite a bit of work.

You can setup triggers that will either have the player connect to a different server instance that is running one world, or in a single player game as you mention trigger the load of a new mission (look at cycleMission in the script files, and/or onMissionEnd() ), but this will not be "seamless" as you need to actually load the new mission.

In short, TGE is not setup by default to do what you want.