Using v12 fora space driven game?
by Adrian Wright · in Torque Game Engine · 03/16/2001 (12:21 pm) · 6 replies
A 2 part question:
#1 In the "out of the box" state, would v12 be able to handle the "never ending" void of space? I would assume probably not, but could you give us a idea on where v12 stands in this area.
#2 Also as developers give back to the engine, when they develop enhancements for the engine, how will GG deal with the code variations? will they be made available to all licensee's or stay with in the develoeprs project.
I only ask cause I assume we are going to have to make adaptions to the engine to handle the void of space, and am curious how engine enhancements will be handled.
#1 In the "out of the box" state, would v12 be able to handle the "never ending" void of space? I would assume probably not, but could you give us a idea on where v12 stands in this area.
#2 Also as developers give back to the engine, when they develop enhancements for the engine, how will GG deal with the code variations? will they be made available to all licensee's or stay with in the develoeprs project.
I only ask cause I assume we are going to have to make adaptions to the engine to handle the void of space, and am curious how engine enhancements will be handled.
#2
This is covered in the FAQ.
Jeff Tunnell GG
03/16/2001 (3:17 pm)
You don't have to return ANY of your code to the community. In some cases we will be willing to trade off additional backend royalty points for additions that are made available to the community.This is covered in the FAQ.
Jeff Tunnell GG
#3
03/16/2001 (4:00 pm)
Right I understood that, i quess I poorly worded my question. I meant as things are distributed how will tey be released, as modules? etc... Then I read the CVS discussion which I think is a great idea.
#4
We'll definitely look into the CVS option. Just haven't had time to figure out how the whole thing would be managed. CVS would be much cleaner than making patches, or sending out CD's every month.
03/16/2001 (8:22 pm)
All the V12 transform matrices uses the float type, so as Brian said, you would be limited by 32 bit floating point precision. This is a typical problem for large worlds environments and can be solved in a number of different ways. Beside removing the terrain and gravity (both simple tasks), you would have to tweak with the "sky" background renderer. It makes a few assumptions about the world, including the fact that it has a horizon.We'll definitely look into the CVS option. Just haven't had time to figure out how the whole thing would be managed. CVS would be much cleaner than making patches, or sending out CD's every month.
#5
Adrian S. Wright
MGO.NETwork
Max Gaming Technologies, LLC.
03/16/2001 (8:49 pm)
I use CVS with open source projects all the time if you need help let me know.Adrian S. Wright
MGO.NETwork
Max Gaming Technologies, LLC.
#6
I am interested in using the engine for an RPG, which would have a continuous world that is sliced up into sectors in a grid (ala the Asheron's Call map). As the player moves around the RPG world, sectors would be swapped in and out of memory. Seems to me that's quite similar to what you'd want to do in a space game, but in 3 dimensions. If possible, this would certainly get around the limitations of the data type being used.
Now depending on how the code's been designed, this might be possible, but I doubt the design the T2 team were going with would have needed to include anything like this...
I'd be interested to hear opinions from those who have seen the code about how feasible this slicing up would be. At any one time, given a large enough sector size, it could be necessary to render 4 different "worlds" (where a world is equivalent to a T2 map) - or 8 for a 3D space game - when the viewpoint is near the edge of a world.
Sounds conceptually quite easy, but experience tells me that it won't be anywhere near as simple as that :)
The other thing I was wondering about was how easy it would be to vary ambient lighting and sky textures within each map (eg day/night cycle) - is it possible to have a skybox within another skybox and vary the opacity of the enclosed skybox? At least with an engine like UT, it seems like it's not possible to do this.
Still, for $100 (well $200 now for us people down under in the banana republic of Australia with our brilliant dollar... ;) source to a well tested rendering framework with lots of cool features seems like a good deal to me :)
Cheers,
Mark
03/18/2001 (9:43 pm)
Hrm, with regard supporting "never-ending" voids of space and the like, I'm wondering about doing something similar... I am interested in using the engine for an RPG, which would have a continuous world that is sliced up into sectors in a grid (ala the Asheron's Call map). As the player moves around the RPG world, sectors would be swapped in and out of memory. Seems to me that's quite similar to what you'd want to do in a space game, but in 3 dimensions. If possible, this would certainly get around the limitations of the data type being used.
Now depending on how the code's been designed, this might be possible, but I doubt the design the T2 team were going with would have needed to include anything like this...
I'd be interested to hear opinions from those who have seen the code about how feasible this slicing up would be. At any one time, given a large enough sector size, it could be necessary to render 4 different "worlds" (where a world is equivalent to a T2 map) - or 8 for a 3D space game - when the viewpoint is near the edge of a world.
Sounds conceptually quite easy, but experience tells me that it won't be anywhere near as simple as that :)
The other thing I was wondering about was how easy it would be to vary ambient lighting and sky textures within each map (eg day/night cycle) - is it possible to have a skybox within another skybox and vary the opacity of the enclosed skybox? At least with an engine like UT, it seems like it's not possible to do this.
Still, for $100 (well $200 now for us people down under in the banana republic of Australia with our brilliant dollar... ;) source to a well tested rendering framework with lots of cool features seems like a good deal to me :)
Cheers,
Mark
Torque 3D Owner Brian Smith
Well, the effective cap on map size is limited to the datatype's size used to represent it (float or double, for instance). Also, calculations are dependant upon the datatype precision - especially when scaling maps up a bit.
Obviously I haven't seen the code, so any other unofficial statements would just be conjecture. =)
(Well, one bit of conjecture - the engine is no doubt implicitly able to handle "space"-type environments. This is ultimately just a map with no terrain. If the engine applies a constant gravity vector, this will obviously have to be removed.)
Will they be made available to all licensee's or stay with in the develoeprs project?
Well, "giving back to the engine" implies that the code is merged with the engine. In this case, it would obviously become available to other licensees. I haven't been able to find anything that requires a licensee to submit any changes to the engine unto GG (a la... LGPL I think), for possible inclusion in the standard codebase - this means, you would only submit your changes if you wished to. GG would obviously pick and choose what enhancements or modifications would be incorporated.
(Now playing: Hannibal - Original Score)