Grids: hex, square or gridless

[Trias]

So what kind of grid should the next version of civ use. The old familiar square grid, a hexagonal grid, or maybe some kind of gridless solution?

An overview of the options:

Square:
This has been the option of choice for all the civ games to date. Units and cities are placed on a square grid, and units can move both to the next neighbors as well as along the diagonals, leading to some unintuitive movement situations. The city catchment area is the familiar although a bit irregular BFC.
Pros: Civ tradition.
Cons: Irregular unintuitive unit movement.

Hexagonal:
An option that has been popular with many turn based strategy games. Tiles are laid out in a hexagonal (or honeycomb) grid. Since in a honeycomb grid tiles only border tiles with which they actual share a side, all moves on such a grid are equivalent, leading to more regular movement. The catchment area of cities would also have a more regular hexagonal shape. An aesthetic benefit is that rivers on the edges of the tiles now no longer make 90 degree turns, an have more natural 3-way forks.
A possible downside is that since there only six movement directions on each tiles it might be less intuitive when using the keypad controls for unit movement. (But aren't we all using laptops without keypads anyway?)
Pros: Altogether more regular than square grids.
Cons: Less intuitive controls.

Gridless:
Some sort of solution without a grid. This, ofcourse, has been popular with RTS games. It is however unclear to me how this would work in a civlike enviroment. The only 4X game I now of that uses a gridless solution is Cosmic Supremacy, and that is set in space so the natural objects are planets and solar systems which can be place off a grid without a problem. If you are voting for this option please explain how you would like this to work in civ.
Pros: Can be quite elegant if it works.
Cons: Unclear how to make it work.

Other:
Other options exist like irregular grids (think Risk), etc. Please explain how and why.

 

[Camikaze]

Gridless is impossible. No matter what you have, the design will still have to be based off some form of grid. This can be minimised, I suppose, but would be an impractical idea.

You might want to check out this thread:
What type of grid system would you like in Civilization?, Onionsoilder, 10/12/08

 

[Trias]

Gridless is impossible. No matter what you have, the design will still have to be based off some form of grid. This can be minimised, I suppose, but would be an impractical idea.

Well, you can actually make a coordinate based instead of a grid based game. In such an approach there are no tiles, all objects of interest are described by there coordinates which can be floats (which of course are still limited by machine precision.) This works quite well for space based 4X games, where most of space is empty anyway.

It is less obvious how to do that for a civ type game where the terrain needs to be defined everywhere. You could I guess make a polygonal terrain map, but it leaves many more obstacles then it solves. I'm however not excluding the possibility that somebody would have an idea there that could work.

You might want to check out this thread:
What type of grid system would you like in Civilization?, Onionsoilder, 10/12/08

I was searching for an earlier thread/poll but could only find something back in 2006. Guess I didn't search hard enough.

 

[Camikaze]

Well, you can actually make a coordinate based instead of a grid based game. In such an approach there are no tiles, all objects of interest are described by there coordinates which can be floats (which of course are still limited by machine precision.) This works quite well for space based 4X games, where most of space is empty anyway.

It is less obvious how to do that for a civ type game where the terrain needs to be defined everywhere. You could I guess make a polygonal terrain map, but it leaves many more obstacles then it solves. I'm however not excluding the possibility that somebody would have an idea there that could work.

I have no idea what I'm talking about, but I would assume that a 2D co-ordinate based system would be functionally identical to a grid system. The smallest value difference (for the purposes of the discussion, let's assume that the smallest movement is +1 on x or y) would essentially be the centre of a tile, with the movement to another co-ordinate and subsequent equidistant points would constitute movements to other tiles.

 

[Trias]

I have no idea what I'm talking about, but I would assume that a 2D co-ordinate based system would be functionally identical to a grid system. The smallest value difference (for the purposes of the discussion, let's assume that the smallest movement is +1 on x or y) would essentially be the centre of a tile, with the movement to another co-ordinate and subsequent equidistant points would constitute movements to other tiles.

Well it is not. The difference is akin to the difference between vector and raster graphics. Of course, since both are done on a computer both must have some sort of graining. The difference is that the later needs to have a description of what is at each point in the grid, while the later needs only the description of the various object in the game.

As result the memory requirements of the later grow as the square of the gridsize, while the memory requirements of the former grow with the number of objects in the game. As a result vector graphics can have a very fine graining (much smaller than any graining on the output.) You can design a game in a similar way. The question is whether you could design a civ-like game in such a way.

 

[Camikaze]

It would make things very complicated. A grid allows for a simple viewable and easily utilised system of movement, organisation and placement. Having a co-ordinate based system would make things way more complicated, and would drastically alter many fundamental aspects of the game, like the BFC, unit movement, distance measurements, etc. I for one don't want to have to use a calculator every time I move a unit.

 

[Trias]

It would make things very complicated. A grid allows for a simple viewable and easily utilised system of movement, organisation and placement. Having a co-ordinate based system would make things way more complicated, and would drastically alter many fundamental aspects of the game, like the BFC, unit movement, distance measurements, etc. I for one don't want to have to use a calculator every time I move a unit.

You can still display the coordinated based game visually (just like you can display vector graphics.) It would probably make distances and stuff easier since the distance is now simply the straight line distance between two points. I agree however that it would be horribly complicated to implement in a civ like setting, and I don't think it would be a good idea, but it is not impossible.

 

[Camikaze]

It would probably make distances and stuff easier since the distance is now simply the straight line distance between two points.

So you would only need to plug some numbers into d^2=(Δx)^2 + (Δy)^2 every single time you moved a unit.

 

[Trias]

So you would only need to plug some numbers into d^2=(Δx)^2 + (Δy)^2 every single time you moved a unit.

No, you wouldn't. (The computer would) The graphical interface can just plot a circle on you map to indicate where the unit can move, and you would just click where you want it to go. To see how this works you could take a look at Cosmic supremacy, which has a coordinated based approach for a space based 4X game. (As said it works much easier for space based games since space is mostly empty.

 

[rysmiel]

Square, but layered so they are effectively cubes, and you have a surface one, an underground/underwater one, possibly a deep underwater one, a stratosphere one and an orbit one, stacked appropriately.

 

[moscaverde]

In a gridless map, how units combat each other, I mean, wont they pass by near each other?

@rysmiel: what's the point of different layers?

 

[Ramesses]

Even though I've always been a proponent of square over hex, I see a gridless system as being the best of all. Now technically, you can't really make a gridless map, just one where each tile is the size of one pixel. But if you use sine to calculate the length and direction of non-cardinal movement, you can subvert this restriction.

For the ease of game calculation, the map will still be generated in a square tile format, where coastlines, terrain features, and resources conform to the grid structure as seen in Civ IV. However, once it has been generated, this grid will only be used to keep track of the transitions between tiles of differing elevation (i.e. hills) which would normally impede movement. Tiles are also used as a helpful unit of measure for determining cultural influence.

Culture grows out from cities in a circle, and the rate at which it grows is calculated through tiles per year (or "turn", if you must). The amount by which the radius grows is determined by finding the difference in radius between the current circle and the next year's ("turn's") circle. For example, if a city has 10, and it grows at a rate of 0.1 a year ("turn"), then the city will currently have a culture radius of about 1.78 tiles, and will grow to a radius of 1.79 next year/turn. A larger city might have 100, with a culture rate of 0.5. Its current radius would be 5.64 tiles, and it would grow to 5.66 next year/turn.

How land improvements will work under this system is currently unknown.

 

[Trias]

In a gridless map, how units combat each other, I mean, wont they pass by near each other?

@rysmiel: what's the point of different layers?

You would probably need to add some kind of zones of control mechanism, where units cannot move closer than a certain distance to an enemy unit without provoking s fight.

 

[Hail]

what's the point of different layers?

the point is to have them. e.g. subs should be not sea units, but submerged units. the point to that being units/improvements with different domains do not collide.

 

[Camikaze]

No, you wouldn't. (The computer would) The graphical interface can just plot a circle on you map to indicate where the unit can move, and you would just click where you want it to go. To see how this works you could take a look at Cosmic supremacy, which has a coordinated based approach for a space based 4X game. (As said it works much easier for space based games since space is mostly empty.

Okay, so that would make it slightly more useable, but still difficult. What is the functional difference between two very near co-ordinates that would otherwise be on the same tile? If there is none, then there is no real point in having a co-ordinate based system. It would just lead to imprecise positioning and a completely unnecessary change to game aspects like city BFCs.

 

[Trias]

Okay, so that would make it slightly more useable, but still difficult. What is the functional difference between two very near co-ordinates that would otherwise be on the same tile? If there is none, then there is no real point in having a co-ordinate based system. It would just lead to imprecise positioning and a completely unnecessary change to game aspects like city BFCs.

The difference is that you don't have to store information for every tile, and maybe more importantly you don't have to define a grid. This lead to some interesting new functional possibilities. In a coordinate based system you can...
* ... have true spherical maps, with no distorted distance.
* ... let units move in a straight line between cities or other points of interest.
* ... make more naturally shaped geographical maps, etc.

There many things you can do in a coordinate based system, which are hard/impossible to realize in a tile based system. On the other hand there are many gameplay concepts on a tile based map that don't have a clear reinterpretation in a coordinate based system. Many gameplay elements of civ would have to be rethought in such a system including combat, tile improvements and yields and more. In the end I wonder if such game would in anyway 'feel' like civ, which is why I am not advocating implementing such a system in the next civ game.

However, the more I think of it, the more I'm convinced that you could make such a system work for a civlike 4X game. I'd very much like to see how it would play out in the end. It could potentionally be revolutionary for the genre, opening all sorts of new doors.

 

[Tholish]

Virtually gridless is possible--with the actual grid being very tiny, like pixels. Coordinates as you say. Distances would be calculated geometrically. Movement would be by mouse: select unit, select where you want it to go. It makes one turns worth of movement toward that destination. Yields and such would be by radial area. City radius ought to be by movement rather than tile count anyway--better transportation extends it. Its just numbers, probably wouldn't take that much computing. Of course if you were doing these Venn diagram like calculations it might, but what you could do is like this. Say you build a Farm (which really represents a developed agricultural district with a market town as its center), the computer places a market town where you plunk it down and then various contributing individual "farms" scattered all around it. The productivity rate of the farming town for the city would be by how many "farms' the terrain could support and how far (by existing infrastructure) they were from the town and it from the city. All the calculations could be up front and you could see a stylized farm icon at the coordinates, as now, on the main screen, but would be able to zoom in or go to something like a "Tile Screen" (analogous to a city screen) to see how many farms there were or might be. All this would require would be plenty of storage memory.

Another thing you could do would be something like a hybrid between turn based and real time. You give your orders as above, and other civs do too, then all the movement takes places automatically and simultaneously as you watch. Then you give another set of orders. You could "program" or select varous automatic reactions to happen in reactions to thingsd that might come up during the automatic portion. Thus you might say, "General, go through this valley towards Washington and take it with your cavalry, but if your vanguard encounters any enemy resistance, try not to reveal the size of your unit and run away."

 

[Ramesses]

Another thing you could do would be something like a hybrid between turn based and real time. You give your orders as above, and other civs do too, then all the movement takes places automatically and simultaneously as you watch. Then you give another set of orders. You could "program" or select various automatic reactions to happen in reactions to things that might come up during the automatic portion. Thus you might say, "General, go through this valley towards Washington and take it with your cavalry, but if your vanguard encounters any enemy resistance, try not to reveal the size of your unit and run away."

You know, I've tried suggesting Simultaneous Turn Resolution on this forum before, but I always got shot down. Just letting you know.

That last part sounds a bit too tactical though. Instead, I would suggest that, rather than giving orders beforehand, when your military unit encounters an enemy during turn resolution, it starts fighting automatically, but just like in CivRev, you can order the unit to flee at any time. After the unit wins or flees successfully, you can let the unit do what it was doing before, or change its destination.

 

[Camikaze]

The difference is that you don't have to store information for every tile, and maybe more importantly you don't have to define a grid. This lead to some interesting new functional possibilities. In a coordinate based system you can...
* ... have true spherical maps, with no distorted distance.

So the circular radius of movement for a unit would really be an elliptical radius of movement? It would be pretty hard to represent/understand movement that didn't conform to a circular radius. And the only way this can be done is through having a flat map, whether it be wraparound or not.

* ... let units move in a straight line between cities or other points of interest.

Straight lines would be distorted by the above. They would be curved lines. Unless, of course, it were possible to move through the surface of the Earth and emerge at a particular point.

* ... make more naturally shaped geographical maps, etc.

I'm pretty happy with the shapes of geographical features how they are currently.

There many things you can do in a coordinate based system, which are hard/impossible to realize in a tile based system. On the other hand there are many gameplay concepts on a tile based map that don't have a clear reinterpretation in a coordinate based system. Many gameplay elements of civ would have to be rethought in such a system including combat, tile improvements and yields and more. In the end I wonder if such game would in anyway 'feel' like civ, which is why I am not advocating implementing such a system in the next civ game.

However, the more I think of it, the more I'm convinced that you could make such a system work for a civlike 4X game. I'd very much like to see how it would play out in the end. It could potentionally be revolutionary for the genre, opening all sorts of new doors.

So, yeah, a co-ordinate based system may have certain minimal advantages over a tile based system, but you lose more than you gain, and as you say, it wouldn't feel like civ.

 

[Gangor]

Other.

The map starts as squares (or hexes for that matter, doesn't matter) which are considered "wilderness". Armies move slowley through these places, and possibly even suffer damage(?) due to the uncertainty and undeveloped nature of the land.

Each city's cultural influence is considered "civilised", and constitutes two "tiles" for movement purposes - Inside the city and outside.

This allows for faster movement (in civilised areas), restrictions upon expansion and exploration, the abstraction of the tactical side of combat (to suit the strategic nature of civ) and better siege warfare.