Grid?

[Leviathan]

I just wondered if we are going to lose the idea of a grid because this is a 3d game?

1 unit on 1 square type thing, ive allways liked it. Makes for intresting tactical play.

Not having a grid changes it all.

[Stormy]

Yes, there will be a grid of some sort. If not, there will be a good method of units, so don't worry about that

[Hooman]

I've always found grids produced some odd behavior with units if it wasn't handled right. I see nothing wrong with a system like in StarCraft where all the units are pixel aligned. It certainly makes more sense for units that are of different sizes. I don't see how it really changes much though.
 

[HaXtOr]

i like grids

[Stormy]

I've always found grids produced some odd behavior with units if it wasn't handled right. I see nothing wrong with a system like in StarCraft where all the units are pixel aligned. It certainly makes more sense for units that are of different sizes. I don't see how it really changes much though.

The thing about that is, you will be able to zoom in, so the processor would be having to calculate where each unit is in the "universe" you're talking about, and in the view the player is in. That won't exactly work though... The grid system works best imo. Use some algorithim using the vertices on the map .

 

[leeor_net]

Clarifying this issue:

All structures/tubes and things of that nature which generally are not mobile will be aligned to what's called the Structure Grid and will 'snap' to the grids. Colony Gridlines is an option that can be turned on and off at any point by the user through the general UI.

Units, being that they are mobile, will not be aligned to a grid. This is a tricky method and, as Hooman stated, can be more trouble than it's worth. They will have world coordinates and will have what I call a 'proximity sphere' which is used to determine how close a unit is to another unit. Once these spheres interact the units will not get closer to eachother.

The geometry for the maps will use what is called a DotScene Matrix rendered through an OctTree Scene Optimizer. This will allow for extremely intricate detail for landscapes and allows for features not available to standard HeightField Terrain engines. For instance, using the DotScene Matrix will allow us to create terrains with the following intricasies:





As you can see this would allow us to create some particularly stunning landscapes for a game such as OUTPOST 3... I'm excited! I just need to finish designing the Map format before I can come up with an editor (stormy, ask me about this later).

Hopefully I've answered your question and I'm sure I threw in there a whole lot more than was necessary but it's still interesting to know what it is we're planning to do.

[Stormy]

They will have world coordinates and will have what I call a 'proximity sphere' which is used to determine how close a unit is to another unit. Once these spheres interact the units will not get closer to eachother.

 

That would be a pretty funny glitch if a vehicle blew up and landed ontop of another (but we'd fix it to where it would be realistic , and it wouldn't land on an invisible sphere )

And yes, I understand what you mean. It would only be for when units are moving right?  

[Hooman]

Wow, those are some stunning pics.

And actually, if you keep the coordinates in some uniform setting, it'll probably be easier to deal with them. Especially when you're doing collision detection and making sure than units don't move through each other. Useing a grid would only make things less realistic.

Of course the base building is probably best if they snap to a grid. Since it'd be hard to line up buildings at the right distance so the tubes between "fit".

Although, just because something snaps to a grid, doesn't mean you can't use the same coordinate system as a vehicle. In fact, if you want to make sure your vehicles don't drive through the buildings, it'd be easiest to keep the coordinates in the same format.

Of course that doesn't mean units won't align on a grid, or that you can't have some sort of formation control. A lot of games will allow for that even though the units coordinates have finer detail. Besides, to make a unit move smoothly from say one grid point to another, you'd need to keep track of how far it is between grid points as it's moving. Why not handle this all in one uniform coordinate system? The grid idea seems like a restriction on movement. But you can always add that to a system with finer positioning detail. Trying to hack a grid based system up to finer detail can get a little sick though.

Anyways, that's my thoughts. Sounds like Leeor has already thought this out. Leeor seems to knows what he's doing.

[leeor_net]

As a note, the above images are photographs but they demonstrate what would be possible with the world geometry format I plan on using.

Well, TH300 has pointed out a few possible difficulties with my original planning namely in narrow spaces (such as a chasm) and a few possible glitches in the pathfinding methods.

Essentially pathfind is going to be handles using two passes: the rough-pass which uses a World Point method of finding a general path between two points and then the fine-tuned WayPoint Path Point Setter which will essentially set a series of waypoints. The paths between points is based on spline-interpolated paths and vehicle height will be adjusted as it moves along its iterpolated path.

The 'grid' system used for colony structures essentially uses the world coordinates... but, because world-coordinates are spaces farther than most buildings are wide, there will be floating-point values that allow for a finer structure-snap grid (e.g., between world coord 0.0 and 1.0 there could be 0.2, 0.4, 0.8 which allows for 5 distinct gridlines).

As far as vehicles are concerned, all structures are considered in the path-finding code and are generally considered obstructions except for special cases (such as a cargo truck entering a Smelter) in which case a 'docking point' is set as the end points of a path and units will engage whatever special attributes are necessary.

Generally, there's no need for a grid-structure for units because it can cause a whole lot of problems with realistic movement if vehicles are moved strictly along a grid-path (tile based A* pathfinding). However, the 'grids' will be used for the quick'n'dirty method to find a general path from point A to point B.

TH300's concern was that highly complex pathfinding problems could end up with no paths being found... Well, that would be the case in real life so a vehicle would likely back-track and try again from its backtracked location. What is possible is that highly complex paths could be navigated using a series of beacons placed by explorer/surveyor robots which would allow for a unit to traverse a highly complex path.

Whew... I should be teaching a college course on this stuff... maybe... sorta...  :heh:  

[TH300]

Yea, I agree in the point that movement will be nicer without a grid.

However, what you suggest for the "quick and dirty method", to find paths aligned to the world grid may not find a simple path which is streight ahead, if this path is too narrow. Its like this:

Tile1 obstacle
Tile1 obstacle
Tile1 ---------- \
Tile1 ---------- |passable terrain which is not recognized as passable
Tile2 ---------- |by the tile-aligned algorithm
Tile2 ---------- /
Tile2 obstacle
Tile2 obstacle

however, I'm sure that a good solution will be found. Noone should worry about op2-style pathfinding in op3.

[BlackBox]

Well, maybe you could think of it this way.

A unit would appear to travel without the use of a grid (as it does in a game like starcraft) but when it stops, it stops at a certain cell and other units cannot occupy that space. However it's less apparent to the user as the unit moves smoothly and doesn't look like it's travelling along a grid.
The only place where the user uses the grid is when they place things like buildings, walls, bridges, etc.

For an example, look at the game The Moon Project (only 3d RTS I've really played). They use a grid system for the user to specify locations of objects (buildings, etc) but as units move they don't follow the grid. And only one unit can occupy a grid space.

But yes, it would save you from having to do a bunch of collision detection and other "fun", time consuming calculations.

[leeor_net]

All great suggestions but when it comes down to a 3D game (at least of the nature that OP3's engine will work) the rules get thrown out and data is looked at completely differently.

First off, OP3 is not tile based (and yes, 3D games CAN be tile-based games, e.g., Warcraft 3, Age of Mythology, etc.) which makes pathfinding different.

Paths are looked at not through a grid but rather by traversing through the DotScene matrix through the use of directional vectors as well as point-to-point angle differences.

Basically, each point in the DotScene Matrix is a point in 3D space containint an X, Y and Z component describing its location.

As the scenes in OP3 are not heightfields but rather large, complex 3D Meshes (hence the intricate detail), the first pass in the pathfinding code will traverse through the world coordinates in the DotScene Matrix. It judges its next move (which point to move on to) by looking at a few things: the height of a potential next point in comparison to the current point. If the height is too different, it chooses another point and then continues from there (hence the modified A* style of pathfinding).

After the first pass has successfully found a viable path, the second pass comes into effect. The second pass creates a series of waypoints starting with the vehicles current position, where it needs to go and determines a viable path based on the first pass.

After the waypoints have been set in a vehicles path, a spline-interpolated path is calculated between all the points. This gives the vehicle a completely smooth and realistic motion. Its directional vector will be adjusted depending on the terrain's slope.

The pathfinders will be doing most of the work. The spline-interpolated paths are going to be the hardest and most expensive calculations to do so if there's a large group of units that have been assigned to the same end-point, the calculations will only be done once (through the 'lead' unit) and then similar paths will be given to the other units.

A note about 'lead' units, they are not explicitly assigned nor is a 'lead' unit any different than any other unit. What determines a 'lead' unit is generally the unit that is closest to the end-point but that's not a strict case. Basically it's just a temporary assignment to a particular unit in a group and is used to reduce the CPU's load for pathfinding calculations.

[Leviathan]

Glad its geting talked about

[Arklon]

What about pixel/vertex shading? Not that I understand how to code them (I know it's assembly or something similar to it).

[leeor_net]

What about pixel/vertex shading? Not that I understand how to code them (I know it's assembly or something similar to it).

That's part of the refresh engine already. Pixel/Vertex shading will be supported on any hardware that is technically a GPU (GeForce 4+ and equivalents are GPU's). Those shaders are actually programs that run on the GPU rather than the CPU. Only newer hardware can do that real-time.

[dm-horus]

if anyone has read many more docs for other rts, what leeor is explaining is relatively common not to say that it is simple or weak. this method isnt exactly extreme or revolutionary as most 3d rts games use a mothod that is similar. especially in that when large numbers of units are ordered to move, the path is not as precise. this can be observed in total annihilation. a single unit willfind a very direct path but a group of 40 units will wander and follow along cliffs much like in op2 when you have no rcc. this all sounds very good to me. im anxious to see more progress. im also glad to see this being talked about. the grid system leeor explained isnt anything you wont find in other rts games so i doubt there will be problems or visible faults. when the thread starter (i forget who) said "grid" did you mean a visible build grid like in op1 to guide construction? i doubt it would be needed. having buildings osnap to eachother would help users. i like the method employed by earth 2160: buildings that can support addons and even tube start points appear as if it were built and attached to the structure (or in the place of one yet to be built), glowing green showing where the user can place the structure. a grid also appears around any buildings that can support expansion when a "kit" has been built and the user is in the process of placing it. when it is placed or deselected, the build grid-guide disappears. it would take some of the guess work out of building, especially if you have to choose between building an expensive kit that might not be placable or building 3 rpg tigers

[leeor_net]

Well, Horus pretty much explained everything I had previously said...

As far as building construction, I thought that something that might be neat is to have a grid appear when a user selects a building to be built (wow... redundant). Anyway, the grids will appear where the user can and can't place the new structure. But this is all speculation. I have to discuss exactly how that's done with my collegues. It'll all be part of the design doc.

[TH300]

if anyone has read many more docs for other rts, what leeor is explaining is relatively common not to say that it is simple or weak. this method isnt exactly extreme or revolutionary as most 3d rts games use a mothod that is similar. especially in that when large numbers of units are ordered to move, the path is not as precise. this can be observed in total annihilation. a single unit willfind a very direct path but a group of 40 units will wander and follow along cliffs much like in op2 when you have no rcc. this all sounds very good to me. im anxious to see more progress. im also glad to see this being talked about. the grid system leeor explained isnt anything you wont find in other rts games so i doubt there will be problems or visible faults.

Sounds good to you, although pathfinding is op2-like with many units? Are you sane?
I'm not going to iplement such pathfinding, unless I really don't find something better. Its not a matter of what other games do, its a matter of what WE do.

[Saturne]

i think a grid is a very good idea, like the Build mode of "the sims". it will be simpler to manage all units and building, not risk the embendding of two building.

[leeor_net]

Something I would like to point out, however, is the way that units will 'park' themselves. They will not be worrying about grids, squares, tiles, sections or anything else like that. That's actually more complex than is necessary. Each unit will be given a 'proximity sphere'. These spheres will will only vary depending on the size of the unit (although I get the feeling that the only difference will be in the aerial units). When parking or moving, the engine will compare the proximity sphere against other units (rather than that units sphere).

Example:

We will be focusing on Unit A and its proximity sphere.

Unit A is traveling with two another unit, B. Unit B is the 'lead' vehicle and thus unit A is following it. They are travelling parallel to eachother with unit B half way in the lead. The two units are far enough apart that unit B is just outside of unit A's proximity sphere.

Unit B makes a 20 degree left and is now going to head in front of unit A. If the two keep moving, they will collide. However, unit B has now touched unit A's proximity sphere so there will be a decision.

At this point, A can either make a 20 degree change toward the right or it can stop dead. It's likely that it will just stop dead as it's easier to do that. When unit B moves out of the proximity sphere, unit A will adjust its directional vectors to match unit B.

=====================================================

On a side note, I just had an idea. Vehicle collisions. The idea of the proximity sphere made me think that if two units collide, they should take damage. If the collision is severe enough, both units could be destroyed.

This could possibly add a new dimension to defense and combat: You have 4 laser lynxes and the enemy has a squadron of panthers. Run the lynxes right into the front line and smash up the first few panthers. The other panthers were set by the other user to use a tight proximity sphere (turn safties off). They're so close to the front line of panthers that they smack into the first damaged line before they can decellerate and stop (no reaction time, basically).

Sounds like a lot of fun to me. What do you guys think?

[TH300]

On a side note, I just had an idea. Vehicle collisions. The idea of the proximity sphere made me think that if two units collide, they should take damage. If the collision is severe enough, both units could be destroyed.

This could possibly add a new dimension to defense and combat: You have 4 laser lynxes and the enemy has a squadron of panthers. Run the lynxes right into the front line and smash up the first few panthers. The other panthers were set by the other user to use a tight proximity sphere (turn safties off). They're so close to the front line of panthers that they smack into the first damaged line before they can decellerate and stop (no reaction time, basically).

Sounds like a lot of fun to me. What do you guys think?

Sounds like making the game more complicated than necessary. I don't see why people would want to control proximity spheres all the time. Plus: vecs don't really drive so fast that it would matter in reality, except in very extreme situations.

[leeor_net]

Well, my idea in terms of the proximity spheres is 'Loose formation' and 'Tight formation'. It would just be a toggle button that would appear in the command pane when two or more units are selected.

[Jgamer]

OH, MY! I still have my account over here >_>
Anyway, TH300, what you just said, that collisions aren't to be worried about because they will just make tactics more cumbersome to deal with, I completely disagree. After spending some time playing a few games where collisions mattered (indeed, there was a level where you had to avoid collisions. And yes, it was an RTS) I know that those are great weapons. Tough probably only lighter vehicles such as scouts and linxes would have enough speed to make impact dangerous. Also, i'm away you rose that point, TH, maybe I just went random-ranting now

[TH300]

What are those games where collision matters?

Thats it is good in other games, doesn't imply that it'll be good in Outpost3. Consider that OP3 focuses on things that don't matter in other games.

What do others think?

[Jgamer]

More precisely, I was thinking of Homeworld, with even more precision the time the Mothership enters an asteroid field (that's compromised of moving objects). And also of the ships that actually rammed yours (Kadeshi's needleship, if you've played that game) that were usually OHKO to any ship.
But as I said there, and i'm sure it wasn't clean enough, most if not all vehicles here ere too slow for collisions to realistically matter, anyway