Some thoughts on map topology and navigable rivers

Interesting and unusual approach to do a Civ like game. Since your work is at a early direct contributions won't make much sense at this point.

But it would be possible to modularize the project a bit so some of us could do some work or planning to help you.
 
I plan to start a blog shortly, which will serve for discussion on design points.

As to mdulatization, both UIs and AIs (which can be run as separate processes or separate servers, and look to the game just like regular players) will be separated from the general running of the environment and mechanics, so those are two areas that it should be readily possible to help with. I'm also not opposed to taking on people wanting to help with core server code when it is sufficiently in place to be easy for that.
 
First a slight apology for posting this here, since it's not strictly about C2C, though I know the audience here will be well-targeted.

Recently I started work on a modern game engine for a Civ-like game, into which I want to incorporate many of the great ideas that have been developed over the years in C2C. This is very early work, and likely to progress slowly - I'll probably be ready to start blogging about the design choices and early working code in a few weeks (at which point I'll post a suitable link to said blog).

As part of this I have abstracted the game engine over possible map typologies (and yes, it won't be restricted to one map, or one view in any way, though that's not relevant to this post), so it'll run happily with any cell arrangement that can be projected in 2 dimensions (including arbitrary connections for things like worm-holes, tunnels, inter-map links, ...). In particular I didn't want to totally bake in a commitment to squares or hexes, though I intend to default to hexes, and the first displays will probably be written to support explicitly hex-based maps.

I had only considered (at least for regular tessellations) hexes and squares (connected to all 8 neighbors or just 4 are both valid possibilities in the square case), but it occurs to me that there is another regular polygon that tessellates in 2 dimensions (on a flat map), which is equilateral triangles. In fact a hex-tessellation can be subdivided into equilateral triangle sub-cells by connecting the vertices to the center in each cell, yielding the equilateral triangle tessellation.

This got me thinking about the old navigable rivers problem in Civ. The problem is that you want to:
  1. Allow movement along rivers by boats etc. (at least parts of a river)
  2. Have a concept of river crossing for land units
For (1) you ideally want the rivers to flow through the center of cells so that the river units move on them. For (2) you want the rivers to flow along the edge of cells, so that as land units move between cells the act of crossing the river is well-defined. In existing Civ map layouts you cannot really achieve both without cell-wide rivers, which don't work for obvious reasons.

However, suppose we have a hex map, and then (logically, not necessarily in a user-emphasized way) sub-divide each cell into its constituent triangles. Then route the rivers along the sub-cell boundaries so that they flow from (hex) cell vertices to centers (i.e. - always through the middle of a cell). Now if we internally hold the position of a land unit as being in a particular sub-cell we can still display it as being in the parent hex cell (maybe we offset it slightly as a visual indication), and can have all the usual movement/combat rules (i.e. - the unit of movement is a full hex, and enemy units in the same hex fight). However, the concept of river-crossing is now well-defined, since the sub-cell arrangement tells us which side of the river a unit started on.

Best of both worlds...?

Opinions welcome - this only occurred to me as a possibility today.
Edit: I deleted the post because I realized I was mistaken. Sorry.

Edit2: You don't actually need sub-cells, you just need to know the direction from which the unit came from.
 
Edit2: You don't actually need sub-cells, you just need to know the direction from which the unit came from.

This could work and the graphical representation could also use this information to display the unit on one side of the river.


I would suggest to just use smaller tiles. A river could simply become one tile type. That would simplify things because it removes the need to generate sub cells.

Settlements could take a single tile but bigger cities would take multiple tiles and so on.
 
This could work and the graphical representation could also use this information to display the unit on one side of the river.


I would suggest to just use smaller tiles. A river could simply become one tile type. That would simplify things because it removes the need to generate sub cells.

Settlements could take a single tile but bigger cities would take multiple tiles and so on.

Smaller tiles don't work well, because (to reasonably represent rivers as whole tiles) they have to be much smaller, which implies MUCH larger maps (in tile dimensions) which greatly increases compute costs for things like pathing. I'll probably go for logical sub-cells (which is to say just keeping a flag to say which notional subcell a unit is in, which in turn is entirely equivalent to remembering the direction of entry)
 
Looks encouraging. I think you are right to deemphasize porting C2C definitions, since really we want something new than to recreate what we already have. I'm biased toward more flexible rule sets, but I understand your reasoning and know first-hand that a project can fail for trying to be too general with it.
 
One thing that I have taken away from 30+ years in the computing industry is that limiting yourself to one data model for everything is very limiting. At a minimum you need 3 or 4
  1. one for the definitions of the rule set and objects in game.

    This is approximately equivalent to the XML in Civ IV. Its purpose is to externalize the rule sets in a way that is easy to understand change.

  2. one used by the engine while playing.

  3. one used by the user interface to display information to the player(s) and receive orders from the player.

  4. one used for saving a game state. This is about optimising saving and loading game states, keeping only what is needed so that saves are lean and mean. They are also done quickly.

Having different data models enables each to be optimized for its particular usage. This allows some immediate modularisation. The down side is that you need data model interfaces to hide the complexities of conversion.
 
I decided to continue using the AXXXXE blog, since this is at least a spiritual descendant of that work. See http://axxxxe.blogspot.com/ to which I have added a post


To build with an 'interesting' modern technology stack, by which I mean one that I find personally interesting to work with and not likely to lead to frustrating brick-walls. This one is admittedly a somewhat selfish goal, and I accept that what I find 'interesting' and 'non frustrating' is a very subjective matter.
Fully understandable since such a project is alot of work and limitations caused by the chosen toolset make it even more challenging.
Can't say that i have much experience with Scala especially purely functional or MongoDB. But they seem not that hard to learn and since both become really popular that knowledge is good to have these days.

Simple declarative schema-based rulesets, which would facilitate much easier modding without having to understand code. I don't want to preclude this, but I won't be prioritizing work to drive rule configuration from some non-code schema - this may come later.
The main reasons for this are that trying to make everything that generic has both performance and implementation costs, and I value scalability, and time-to-first-playable-game more highly than ease of moddability.
There is no need to make it completely modable because the source code is available. That enables people to modify the game unlike closed source games where you need to have at least some kind of scripting to really change the rules.
Also, I intend to be conservative about the introduction of new ruleset features, as these tend to otherwise run ahead of AIs' ability to adapt to them, to the detriment of overall playability in single-player scenarios
+1
 
Top Bottom