Space - The untapped Torque realm.
by Kevin Summers · in Game Design and Creative Issues · 10/03/2007 (6:45 pm) · 15 replies
I'm interested in putting together a couple of space based games hopefully using TGE.
Here's what I've learned so far.
- Modify Skybox (simple enough)
- Remove Terrain from the mission file (simple enough)
- Make the Ship the Player model (not to hard I guess)
- Make it zero gravity
- Gravitational pull from planets and stars
- Largest possible level in TGE is 3072 x 3072
so size and speed of everything will have to be scaled down
so that at least a solar system will fit within those confines.
- Movement controls need to be modified to allow X, Y and Z axis
and engine throttle control
Anyone still working on a space game for TGE. All the resources and discussion I found
were a few years old and no real updates. It seems it would be entirely possible to do
with Torque.
Thoughts?
Comments?
Updated Resources?
Here's what I've learned so far.
- Modify Skybox (simple enough)
- Remove Terrain from the mission file (simple enough)
- Make the Ship the Player model (not to hard I guess)
- Make it zero gravity
- Gravitational pull from planets and stars
- Largest possible level in TGE is 3072 x 3072
so size and speed of everything will have to be scaled down
so that at least a solar system will fit within those confines.
- Movement controls need to be modified to allow X, Y and Z axis
and engine throttle control
Anyone still working on a space game for TGE. All the resources and discussion I found
were a few years old and no real updates. It seems it would be entirely possible to do
with Torque.
Thoughts?
Comments?
Updated Resources?
About the author
#2
10/03/2007 (9:28 pm)
I was unaware there were space limitations in TGE levels. I thought that was just terrain tiling. I really don't think there are limits to where objects can go. Please excuse me if I'm wrong.
#3
Checking................................................................
Right you are. The terrain simply wraps, but you can continue to place objects outside that area.
I'm heading off to the Flight Game Example thread to continue to explore this.
Thanks.
10/04/2007 (9:31 am)
Hmm... You might be right. It may be just the terrain.Checking................................................................
Right you are. The terrain simply wraps, but you can continue to place objects outside that area.
I'm heading off to the Flight Game Example thread to continue to explore this.
Thanks.
#5
You can,
- Remove the terrain
- Place objects outside the terrain bounds
- Use the Flying Vehicle as a base to start from
What I haven't found out yet is how far out you can place objects in a mission.
It's one thing to place them outside the bounds of the terrain size, but is there a
limit to how far out you can go? What type of variable is the position of an object
stored in? If it's an int() does the engine choke when you place something at
-32,769 1 1 ?
I suppose I could do some more digging into the source to find that much out
pretty easily. I suspect it wouldn't be hard to dig through all the code and make
sure all the variables that hold object positions are large enough that you could
create a HUGE (AND I MEAN REALLY REALLY HUGE) space to play in that is contained
in just one mission file.
Once I'm done exploring whether or not this or that is possible, maybe I'll create a
blog here on gg and keep everyone updated as to my progress.
So far though, for the things that I have in mind, this looks very exciting, and most
definitely possible with TGE.
10/08/2007 (11:12 am)
Space Game Progress.You can,
- Remove the terrain
- Place objects outside the terrain bounds
- Use the Flying Vehicle as a base to start from
What I haven't found out yet is how far out you can place objects in a mission.
It's one thing to place them outside the bounds of the terrain size, but is there a
limit to how far out you can go? What type of variable is the position of an object
stored in? If it's an int() does the engine choke when you place something at
-32,769 1 1 ?
I suppose I could do some more digging into the source to find that much out
pretty easily. I suspect it wouldn't be hard to dig through all the code and make
sure all the variables that hold object positions are large enough that you could
create a HUGE (AND I MEAN REALLY REALLY HUGE) space to play in that is contained
in just one mission file.
Once I'm done exploring whether or not this or that is possible, maybe I'll create a
blog here on gg and keep everyone updated as to my progress.
So far though, for the things that I have in mind, this looks very exciting, and most
definitely possible with TGE.
#6
Im not sure how much, or when this becomes a concern. Second hand info from someone way more knowledgable then me.
10/08/2007 (11:48 am)
Just from previous posts I have read what I do know is that the further from 0,0,0 you go the more the error correction can mess with object placement.Im not sure how much, or when this becomes a concern. Second hand info from someone way more knowledgable then me.
#7
I just finished testing with a tree. Moving it out, taking the camera to that location
to make sure it's actually there, then moving it out some more. I got up to 500,000
on the X axis and stopped. I figured thats as big or bigger than anything I'll need.
Then I took the player. In this case good ol' Kork. Up to this point I'd been moving
the camera out to take a look at the object. This time I dropped the player there too.
What I found is that anything beyond about 30,000 will cause a "jitter" in the player.
Not sure what might be causing it, but as you approach 0 along that axis it gets less.
It becomes tolerable (meaning barely noticable unless you know it's there) at around
10,000-15,000. That's still quite a bit of space, and should be sufficient for my needs.
Knowing that you can go further if you want is interesting, but object placement
beyond 10,000 might pose other problems that I haven't found yet. Especially when I'm
looking at running an AI script that will handle planet orbits.
It should make a nice place for those nasty rogue comets to travel in while they're making
their turns back towards the center of the galaxy/universe. :-)
10/08/2007 (12:49 pm)
That could pose an interesting problem...I just finished testing with a tree. Moving it out, taking the camera to that location
to make sure it's actually there, then moving it out some more. I got up to 500,000
on the X axis and stopped. I figured thats as big or bigger than anything I'll need.
Then I took the player. In this case good ol' Kork. Up to this point I'd been moving
the camera out to take a look at the object. This time I dropped the player there too.
What I found is that anything beyond about 30,000 will cause a "jitter" in the player.
Not sure what might be causing it, but as you approach 0 along that axis it gets less.
It becomes tolerable (meaning barely noticable unless you know it's there) at around
10,000-15,000. That's still quite a bit of space, and should be sufficient for my needs.
Knowing that you can go further if you want is interesting, but object placement
beyond 10,000 might pose other problems that I haven't found yet. Especially when I'm
looking at running an AI script that will handle planet orbits.
It should make a nice place for those nasty rogue comets to travel in while they're making
their turns back towards the center of the galaxy/universe. :-)
#8
10/08/2007 (1:07 pm)
This is a very interesting topic. One of the next games we plan on doing is a space based RTS, so I'll have to keep an eye on this one.
#9
But you could limit the space and have portals and load areas up.
10/08/2007 (1:19 pm)
There is a problem when you go up (vertical) for a long ways the object (the spaceship your in) .. you will start to see it act strangely, jittering. But you could limit the space and have portals and load areas up.
#10
X and Y axis. Probably around 10,000+ and you start to notice the
jitters. (maybe it's colder in that part of space..) :)
10/08/2007 (1:30 pm)
I'm guessing the vertical limitation is in about the same range as theX and Y axis. Probably around 10,000+ and you start to notice the
jitters. (maybe it's colder in that part of space..) :)
#11
10/08/2007 (3:03 pm)
The jitters are most probably from integer math rounding errors in the physics code - a common problem. Divide your space into sectors and "slide" the sectors along as the player moves thru space.
#12
of the level around him? That might work for a single player version, but I'm looking
at MMO for this.
With what I have in mind though, a combination of limiting the mission area to
20,000 x 20,000 x 20,000 and using some simple scaling, a sizable universe should
be available to explore. If I should run out of room for what I need, I'll just make
another one and fill it with more..
10/08/2007 (4:35 pm)
Do you mean have the player's ship basically stand still at 0,0,0 and move the restof the level around him? That might work for a single player version, but I'm looking
at MMO for this.
With what I have in mind though, a combination of limiting the mission area to
20,000 x 20,000 x 20,000 and using some simple scaling, a sizable universe should
be available to explore. If I should run out of room for what I need, I'll just make
another one and fill it with more..
#13
Player1.pos also has a sector modifier to it.
Moon position therefore =
So every sector a player moves into, objects are moved 500000 units, but it's instaneous and you'll never see the flick.
10/08/2007 (5:13 pm)
No I mean that everyone in the universe tracks their position within space and spatial bodies are places relative to their position. ( note the following is pseudocode and wont compile )Moon.pos = 10000, -15000, -175000 Player1.pos = 5000, 6000, 2000
Player1.pos also has a sector modifier to it.
Player1.sectorPos = sectorx * 500000, sectory * 500000, sectorz * 500000
Moon position therefore =
Moon.pos - (Player1.pos +/- Player1.sectorPos)
So every sector a player moves into, objects are moved 500000 units, but it's instaneous and you'll never see the flick.
#14
10/08/2007 (5:14 pm)
I really should do a resource for people to track space this way - the same issue has been presented many times now.
#15
What I'm picturing is 3D space set up in sectors in the shape of a Rubik's
Cube. Let's say the player is in the center cube/sector of space. Each cube
is (for the sake of simplicity) 100x100x100.
Now let's say the player moves from 50x50x50 to 100x50x50, you're saying
that when he hits 101, you would actually increment his Xsector by 1, and set
his location to 1x50,50 iwthin that sector, and remove all of the objects that
belong to the first sector out, and move those objects for this sector in.
Is that right? If so, it's not a bad idea. It would however take a fair amount of
work in the engine code to make it happen, and you still have the trouble with
the server having to be able to handle all of the sectors at once without moving
them around.
It would almost be better to have jump gates at the edges, and those take
the player on to load the next mission which contains the next star system in
that direction.
There's a game called Dark Space that caught my attention last week. It's got
some of the same feel to it that I would like to have. It's trouble was that it
looks 3D but you actually only travel in 2 axis. There is no Z axis movement.
That game however manages a large universe with several systems, and you
can either choose to use the jump gates, or you can burn up all your fuel and
use your FTL drive to get to the next system. (which also takes considerably
longer)
I'd rather the player basically have to use the jump gate. It
allows for the use of separate mission files for the next system.
It also keeps things a little simpler for me on the front end, which helps
to ensure that I might actually get a product out the door. :-)
The other advantage is that I can put each mission on a separate server
if needed to handle a larger number of users. (Let's hope I have to..)
10/08/2007 (6:30 pm)
Hmm.. I guess I'm not quite wrapping my head around how that works.What I'm picturing is 3D space set up in sectors in the shape of a Rubik's
Cube. Let's say the player is in the center cube/sector of space. Each cube
is (for the sake of simplicity) 100x100x100.
Now let's say the player moves from 50x50x50 to 100x50x50, you're saying
that when he hits 101, you would actually increment his Xsector by 1, and set
his location to 1x50,50 iwthin that sector, and remove all of the objects that
belong to the first sector out, and move those objects for this sector in.
Is that right? If so, it's not a bad idea. It would however take a fair amount of
work in the engine code to make it happen, and you still have the trouble with
the server having to be able to handle all of the sectors at once without moving
them around.
It would almost be better to have jump gates at the edges, and those take
the player on to load the next mission which contains the next star system in
that direction.
There's a game called Dark Space that caught my attention last week. It's got
some of the same feel to it that I would like to have. It's trouble was that it
looks 3D but you actually only travel in 2 axis. There is no Z axis movement.
That game however manages a large universe with several systems, and you
can either choose to use the jump gates, or you can burn up all your fuel and
use your FTL drive to get to the next system. (which also takes considerably
longer)
I'd rather the player basically have to use the jump gate. It
allows for the use of separate mission files for the next system.
It also keeps things a little simpler for me on the front end, which helps
to ensure that I might actually get a product out the door. :-)
The other advantage is that I can put each mission on a separate server
if needed to handle a larger number of users. (Let's hope I have to..)
Torque Owner Steven S