Possible Future Direction (personal view)

I'm snowed under with work currently, which is why post 3 has not happened the past 2 days, and also why I have had zero modding time to look at any bug reports here.

That's understandable, I have a lot of schoolwork now before the thanksgiving break so I have next to no modding time.

Thats perfectly understandable everyone, RL is waay more important, especially work/student stuff. Take a week or so off, no big deal . . . SO

Except for my Bugs/Crashes ahaha:lol::p
 
Random observation: The core data layer as it is described here is quite versatile and not really bound to 4X games at all. It could be used as well for a roguelike or even a non game program.
 
I've just read through post 3 and have many thoughts about it.

The first part was about the tiling scheme. Option one was what civ uses, and works to a certain extent. I think that at the start we should use it, as it requires the least work, and if we want to implement something more advanced (ie, option 4) we can do that later while getting a useful result from our efforts sooner, which is always encouraging. Option 2 would be overly complicated and a hassle, why do that when you can do option 4. Option 3 would be a good idea independantly of tiles, and should be done whether or not we go with option 1 or 4.

Now, on to option 4. One could theoretically make all unit/city/anything else coordinates floating point numbers, for all practical purposes dispensing with tiles. A standard 'interaction range' could be defined for combat and unit movement, and the UI for that would not be hard. That range of course would be set in the data layer. But, as you said, the biggest issue would be calculating paths and locations for things. However, one could use calculus to max/min elements of a dynamic path and make a reasonable route from point A to B. That though would be HORRIBLE for the performance compared to basic tiling, so that's something to watch out for.

Overall, I'd vote for option 1 overlaying it with the layers principle from 3. Option 4 would be nice as an extra-long term goal, but for now it seems that sticking with a quantized map is the best idea. And I'd vote for square tiles, it does introduce some distance issues, but I don't want it to look like we are copying CiV on the surface.
 
There is another option with its own advantages and disadvantages:
Small tiles (for instance 16 tiles per 1 we have now) but objects can occupy more than one tile and have different sizes. So a prehistoric scout might accupy 1 tile but a large army stack could be on 32 or more tiles.

Advantages:
  • Objects of different sizes can be expressed well
  • Rivers can flow in a nice looking way and even differ between large and smaller rivers
  • Possibilities for strategic gameplay

Disadvantages:
  • Gameplay rules are more difficult to define
  • Might be confusing
  • Pathing is more difficult (as size matters)

I am not sure myself what the best approach is.
 
I think that @ls612's option is best, as it would remove tiles entirely for a more realistic "movement radius". With regards to performance, I am sure that your game engine would be more efficient than the Firaxis one, so that should be less of a concern.

Also, spherical maps should be looked into. The laws of physics dictate that no plane can be made as large as the current Civ maps.
 
I think that @ls612's option is best, as it would remove tiles entirely for a more realistic "movement radius". With regards to performance, I am sure that your game engine would be more efficient than the Firaxis one, so that should be less of a concern.

Also, spherical maps should be looked into. The laws of physics dictate that no plane can be made as large as the current Civ maps.

I'm not advocating removing tiles for a LONG while, I'd prefer to use civ style tiles at first with the layering option, then possibly get more complicated later.
 
There is another option with its own advantages and disadvantages:
Small tiles (for instance 16 tiles per 1 we have now) but objects can occupy more than one tile and have different sizes. So a prehistoric scout might accupy 1 tile but a large army stack could be on 32 or more tiles.

Advantages:
  • Objects of different sizes can be expressed well
  • Rivers can flow in a nice looking way and even differ between large and smaller rivers
  • Possibilities for strategic gameplay

Disadvantages:
  • Gameplay rules are more difficult to define
  • Might be confusing
  • Pathing is more difficult (as size matters)

I am not sure myself what the best approach is.

Yeh, I had considered this as a special case of irregular, though obviously that's not strictly accurate. The reason I was thinking of it that way was pathing-centric, since you'd want to consider macro-tile (in some sense) sized regions of micro-tiles that were essentially homogenous, as one macro tile for pathing calculations (for scalability reasons), which means that (from a pathing perspective) you wind up with what amounts to an irregular grid (in some areas you just treat it as a macro-scale tiling, in others you need to dive into the details). Also for display purposes it's pretty much an irregular grid, because the snap-to scale would probably need to be more at the stack-size level than the micro-tile level or else movement points would seem a bit un-natural for the player.

Anyway, I'm leaning towards regular grid with overlay layers, because it seems adequately flexible without MUCH added complexity, and because it lends itself to staged implementation (regular grid is all you get in version 1). On how to tessellate, I'd prefer hexagons since neither is rally any more work than the other and I think the end result is, on balance, superior.
 
I have played a game without grids. It makes it very difficult to get two of your groups to meet at the same place and time. In one case the supply train arrived in the morning and was destroyed by the enemy scouts who left before my main army arrived a few hours later. A turn was a day! When I sent the units off it said they would arrive at the same time!
 
I'm not advocating removing tiles for a LONG while, I'd prefer to use civ style tiles at first with the layering option, then possibly get more complicated later.

Perhaps we could not dispense entirely with tiles, just using super-small tiles of which there are a large amount? These would be functionally identical to a continuous surface but would make pathing significantly easier as far as programming is concerned.

Yeh, I had considered this as a special case of irregular, though obviously that's not strictly accurate. The reason I was thinking of it that way was pathing-centric, since you'd want to consider macro-tile (in some sense) sized regions of micro-tiles that were essentially homogenous, as one macro tile for pathing calculations (for scalability reasons), which means that (from a pathing perspective) you wind up with what amounts to an irregular grid (in some areas you just treat it as a macro-scale tiling, in others you need to dive into the details). Also for display purposes it's pretty much an irregular grid, because the snap-to scale would probably need to be more at the stack-size level than the micro-tile level or else movement points would seem a bit un-natural for the player.

Anyway, I'm leaning towards regular grid with overlay layers, because it seems adequately flexible without MUCH added complexity, and because it lends itself to staged implementation (regular grid is all you get in version 1). On how to tessellate, I'd prefer hexagons since neither is rally any more work than the other and I think the end result is, on balance, superior.

This is not at all a bad idea. Using macroscopic tiles for pathing purposes over large distances, and using micro-tiles to give a continuous feeling on the scale of one macro-tile or smaller, would be an ideal solution before tiles are dispensed with entirely. Also, there should be a distinct "terrain layer" to make terrain more continuous and realistic.
 
Perhaps we could not dispense entirely with tiles, just using super-small tiles of which there are a large amount? These would be functionally identical to a continuous surface but would make pathing significantly easier as far as programming is concerned.

I agree with Koshling on this. My philosophy (for everything really) is to start simple and then make things more complex if and when we want to. With his plan (option 3 essentially) that would happen. I don't know about hex tiles though, I don't want it to look like we are imitating the civ 5 engine (even though we aren't at all).
 
I agree with Koshling on this. My philosophy (for everything really) is to start simple and then make things more complex if and when we want to. With his plan (option 3 essentially) that would happen. I don't know about hex tiles though, I don't want it to look like we are imitating the civ 5 engine (even though we aren't at all).

Hex tiles aren't really that great - aside from georealism I liked square tiles better, even though moving diagonally gave a square root of 2 times more "movement" than would moving forward. It's somewhat unrelated, but perhaps in the immediate future of C2C you could make moving diagonally cost 1.5 movement points in order to more closely reflect the reality of how far you can move.
 
perhaps in the immediate future of C2C you could make moving diagonally cost 1.5 movement points in order to more closely reflect the reality of how far you can move.

Not in the immediate future, but if we are making a new engine that sound like a reasonable idea.
 
Hex tiles aren't really that great - aside from georealism I liked square tiles better, even though moving diagonally gave a square root of 2 times more "movement" than would moving forward. It's somewhat unrelated, but perhaps in the immediate future of C2C you could make moving diagonally cost 1.5 movement points in order to more closely reflect the reality of how far you can move.

This doesn't really work, because most early units (indeed many units throughout) only have one movement point but that's always enough for any one tile move, so you can't apply the 1.5 scaling to short moves.
 
Hexagonal game maps have been around far, far longer than Civ5. They date back to very old school war games.
 
Hexagonal game maps have been around far, far longer than Civ5. They date back to very old school war games.

I like hex maps too. I suppose we could use those without issues in all likelyhood. At any rate, I'm looking forward to seeing the proposed programmatic structure of this new project, as that part intrigues me greatly.
 
Hexagonal game maps have been around far, far longer than Civ5. They date back to very old school war games.

1961 I think was the year the ire he's tiled war-game came out. Hex has been de rigor in serious board war-games for ages. Computers went to squares because they were easier to program and display on earlier computers.
 
What I personally think would be optimal is if we could somehow provide many of these as options for the game structure being defined in any given module.

I'd love to see a system where a map could be drawn without any concern for tiles whatsoever, just defined regions, then gets approximated into tiles by an overlay that picks up the most dominant featuristics for that tile. In such a system, we could set things up to utilize EITHER hexes OR squares at player option (though some game functions would have to consider that option in its design, providing a structure for either system.)

I liked what AIAndy presented. Mini-tiles as it were. In such a structure, the middle of the unit would be the 'terrain' the unit is in, even if it does inhabit multiple tiles. Therefore, units can be of a 1x1, 3x3, 5x5, 7x7 etc... size increments and when taking movement into account considers only the central tile. Units (being groupings of individuals) could be made to be mutable in shape, naturally taking on shapes that allow them to fit into/through spaces that would normally not allow them to pass. For example, a 7x7 unit could become a 3x14 size unit to squeeze through a mountain pass. Rivers would be a full mini-tile wide or more BUT would be passable (only on a single mini-tile width) or impassable depending on a trait on that square (river pass) or on traits owned by the units such as the ability to swim itself.

Altitude of each tile should be defined and where altitude differs by more than one stage a ridge forms, the ridge itself defined by the height difference, some ridge strengths being passable depending upon the abilities of the unit attempting to pass, others being so severe as to be cliffs and thus completely impassable.

Just some thoughts...
 
Top Bottom