Possible Future Direction (personal view)

[primem0ver]

I'm not sure. I think you under-estimate the difference in "feel" between the two. With tiles, you basically have a digital boardgame (which is a pretty apt description for what Civilization is). Throw tiles out, and I'd say you largely lose that digital boardgame feel, and change it to something quite different.

I'm torn on the issue. I see the advantages you cite for using points (and I'm interested in what the other techies here have to say about this). On the other hand, I have to say... I do like tiles! I find myself in the unusual role of the stodgy old conservative for once, but there you are. I think there's just a certain, endearing "old-fashionedness" about tiles...

I agree that there would be a different feel. I also agree on the endearing-ness of tiles. I just think that the benefits are worth it. But my real point wasn't this. My point was that the relationship to Civilization would not be lost or contrived. It would be obvious in screen shots and in what the game is about even if actual play had a different feel to it. Yes... it would take some getting used to but I think people would eventually. And I think they would like it in the end.

 

[primem0ver]

One more thing... the "feel" could be partially preserved in an artificial way. We could have a user option to still draw a hexagonal grid for reference and look. The difference would be that the points on the perimeter of the hexagon could be used for placement. Once they got used to that, they could turn off the grid if they wanted.

 

[3335d]

there is a developed game like this http://thrivegame.forum-free.ca/forum

I knew about this project already, and unfortunately it's not yet complete.

 

[Thunderbrd]

About this 'on the points' thing - wouldn't that make it tough to define where a unit was in regards to its current terrain? Could you provide us with some more graphic examples to show what you have in mind there?

I was playing around with geometry a bit earlier this week and hit on some concepts I can't just explain so I'm going to need a bit of time to workup some graphics to express before I really make any suggestions but suffice it to say, I'd like to propose something that might help to make both the Square and the Hex camps happy.

 

[ls612]

About this 'on the points' thing - wouldn't that make it tough to define where a unit was in regards to its current terrain? Could you provide us with some more graphic examples to show what you have in mind there?

I was playing around with geometry a bit earlier this week and hit on some concepts I can't just explain so I'm going to need a bit of time to workup some graphics to express before I really make any suggestions but suffice it to say, I'd like to propose something that might help to make both the Square and the Hex camps happy.

I assume every point would be mapped onto an underlying heightmap, and that would determine what terrain you are on.

 

[strategyonly]

I just saw this, dont know it anything like this would work or not? (Open the spoilers below)

http://forums.civfanatics.com/downloads.php?do=file&id=20387

 

[primem0ver]

I assume every point would be mapped onto an underlying heightmap, and that would determine what terrain you are on.

While every point on the map would be mapped to a "height" map there would also be plot types that modify that height map. Plus, that wouldn't necessarily go along with the "terrain" per se. I explain the basic idea how the AI determines the terrain to use for a player (for points on edges) in this post. The red highlighted sub section at the bottom as well as the last paragraph of this post

 

[primem0ver]

I just saw this, dont know it anything like this would work or not? (Open the spoilers below)

http://forums.civfanatics.com/downloads.php?do=file&id=20387

I couldn't tell if this is a game or just a GE addon that allows for plotting the borders of real empires over google earth terrain.

 

[AIAndy]

I thought a bit more about the core data model.
What about using relational database tables for relationships (that is what relational databases are all about in theory). Then SQL statements can determine what entity to apply a certain effect to. Some database implementations even have query notifications that trigger an event if the result of a certain query changes (I am not sure though if any of the free ones have something like that implemented or how efficient it is).
I guess not all relationships are explicit anyway so some layer to handle change events might need to be set above it anyway.

The advantage of the approach is that you can have n-ary relationships with powerful queries in the form of SQL selects with joins and filters.

 

[Koshling]

I thought a bit more about the core data model.
What about using relational database tables for relationships (that is what relational databases are all about in theory). Then SQL statements can determine what entity to apply a certain effect to. Some database implementations even have query notifications that trigger an event if the result of a certain query changes (I am not sure though if any of the free ones have something like that implemented or how efficient it is).
I guess not all relationships are explicit anyway so some layer to handle change events might need to be set above it anyway.

The advantage of the approach is that you can have n-ary relationships with powerful queries in the form of SQL selects with joins and filters.

It was my intention to use SQL(like at least) tables as the underlying storage model. Specifically the Net DataSet class which abstracts the concept somewhat (but critically gives the same logical model, including relationships and selects), and can be bound to an actual SQL db or not (can just exist as in memory repsentation too, with serialization to XML). I wasn't planning to expose that per se above the data storage layer, but the relation based capabilities already discussed that are closed by that layer would probably wind up as a fairly direct mapping.

 

[Laskaris]

@ primem0ver: So, if there is an edge between land and water, is that edge considered both land and water for movement purposes? Meaning that both land units and naval units can move along that edge? And wouldn't that look funny graphically, with land units as well as ships moving as if they are glued to the coast?

 

[ls612]

It was my intention to use SQL(like at least) tables as the underlying storage model. Specifically the Net DataSet class which abstracts the concept somewhat (but critically gives the same logical model, including relationships and selects), and can be bound to an actual SQL db or not (can just exist as in memory repsentation too, with serialization to XML). I wasn't planning to expose that per se above the data storage layer, but the relation based capabilities already discussed that are closed by that layer would probably wind up as a fairly direct mapping.

I'd assume storing as much as we can in memory would be good for performance, so I personally would push for that approach. It's not like modern comps will have issues with that using a 64 bit engine anyways, we might as well take advantage of new technology if we are going to write our own engine.

 

[AIAndy]

It was my intention to use SQL(like at least) tables as the underlying storage model. Specifically the Net DataSet class which abstracts the concept somewhat (but critically gives the same logical model, including relationships and selects), and can be bound to an actual SQL db or not (can just exist as in memory repsentation too, with serialization to XML). I wasn't planning to expose that per se above the data storage layer, but the relation based capabilities already discussed that are closed by that layer would probably wind up as a fairly direct mapping.

A real database engine might have an efficiency advantage over using the .Net DataSet class (not entirely sure though, I have not used it yet but I think it is more about keeping the client side query result than optimized querying on its content).

If every named relation is a database table, then SQL queries can be used to describe what something applies to.
As an example a building effect that should apply to all cities of the team.
That can be expressed by an SQL query that looks somewhat like this:
SELECT E.city
FROM buildings A
INNER JOIN cities B ON A.city = B.city
INNER JOIN players C ON B.owner = C.player
INNER JOIN players D ON C.team = D.team
INNER JOIN cities E ON D.player = E.owner
WHERE A.building = THIS_ENTITY;

With code that watches for changes in registered expressions a lot of the stuff that is dealt with special code now in C2C can be solved in a more generic way.

 

[primem0ver]

@ primem0ver: So, if there is an edge between land and water, is that edge considered both land and water for movement purposes? Meaning that both land units and naval units can move along that edge? And wouldn't that look funny graphically, with land units as well as ships moving as if they are glued to the coast?

You have a point there. Following the logic I presented previously, a ship would "use" the water up to the shore and the unit would "use" the beach. While this is logical, it would present a graphical and logical issue (i.e. that in normal circumstances, land and water units cannot use the same paths of transportation).

But such an issue already exists with cities. Both units and people inhabit them. In a way it could be viewed as an issue of depth. Generally land units make more sense on the shore line than ships because ships would run aground before encountering the shore. Of course there is the exception with harbors and other places where ships have some depth to work with.

To solve this problem there are a few things to keep in perspective. First, don't forget that the resolution when using vertices (points) is around twice as precise. The distance between two points is on average half the radius of a tile. So the shoreline itself should be considered land and the half "tile" away point is considered sea. This could be applied to all shoreline points except where cities and edifices are built that support land and sea units occupying the same space. This same logic could be applied in other circumstances where ambiguity becomes a problem.

As far as the graphics are concerned, we would need to make sure that beach graphics extend over the line just a touch which isn't too hard to accomplish. We already see this happening in tile based graphics where one tiles texture sometimes reaches over into the next tile.

NOTE: This is a good example of where coming up with rules to be set in programming logic is a lot easier than creating a myriad of graphics to compensate, even when graphics are involved (since "overlapping" does not make more graphics necessary).

 

[Thunderbrd]

I know we've had a lot of discussion here on the tile methods we could/should employ. And I realize I'm probably not saying anything that hasn't been said in a manner that I may not have understood . But my proposition is a bit like the above.

There's some here who would prefer square tiles. For graphic development purposes, my 3d terrain graphics program would also prefer square tiles. Hexes would be tough to design as it doesn't play as nice with the generation methods. Additionally, I, myself kinda don't like the way hexes work in that travel along one cardinal direction is 6/8ths less effective than travel along the other. (So if the Hexes are angled as such, you can travel only 6/8ths as fast directly west or directly east as you can to the north or south.)

However, I DO like how hexes can be made to wrap on a globe much easier. I also like how travel from one plot to the next is always the same distance (though I don't think that can quite be said for my proposition here, its a bit closer than we'd get with diag movements on a square grid.) I also find squares are just easier to wrap the mind around.

I hit on this idea of utilizing the vertices of a hex map and realized it could still be displayed as squares if the squares were arranged like brick tile rather than a perfect array like graph paper. To me, it seems to be able to capture all the same effects. We could use the Hexes to generate the global wrapping map but then graphically, and game engine-wise, use squares (even imperfect ones that get tweaked a little to maintain their borders with each other with the centers focused on the hex points) to represent the actual game tiles themselves.

I think this would pacify all camps. It has the following benefits:

* Movement in any of the main 4 directions is equivalent (travel the same distance with the same # of moves).

* Closer approximation of distances on 'diagonal' movements (although diagonal means more like knight on chess board diagonal than true NE,NW,SE,SW travel but it still suffices.)

* The graphics would be easier to design.

* We could still wrap such a system around a globe by developing a hex map first and enforcing the tiles to center on the hex vertices and center points and allowing the line edges (and overall tile dimensions to adjust according to need which could tweak the tile graphics subtly enough to not be terribly noticeable (except perhaps where we require pentagons.))

I'm sure there's more but I'll let it get discussed out from here.

 

[Koshling]

A real database engine might have an efficiency advantage over using the .Net DataSet class (not entirely sure though, I have not used it yet but I think it is more about keeping the client side query result than optimized querying on its content).

If every named relation is a database table, then SQL queries can be used to describe what something applies to.
As an example a building effect that should apply to all cities of the team.
That can be expressed by an SQL query that looks somewhat like this:
SELECT E.city
FROM buildings A
INNER JOIN cities B ON A.city = B.city
INNER JOIN players C ON B.owner = C.player
INNER JOIN players D ON C.team = D.team
INNER JOIN cities E ON D.player = E.owner
WHERE A.building = THIS_ENTITY;

With code that watches for changes in registered expressions a lot of the stuff that is dealt with special code now in C2C can be solved in a more generic way.

I don't like this direct a mapping because I want relations to be definable dynamically by declarative expressions in the mod XML, and also (as needed) by things like AI modules. Since these may change as we upgrade/enhance, having them map directly to the (storage) table layout would make save game compatibility tricky. However, I DO want the relationship resolution to all take place within the data layer generically, so the benefits of only needing one set of generic code to handle all cases still applies.

 

[Dancing Hoskuld]

All this discussion about the physical storage layer seems a bit limiting at the moment. We will still need the XML storage layer anyway as that would allow other Civ IV mods to move to the new engine as well.

I would assume that XML would be the base storage with the program data model and User Interface model being "made real" in the best form for those layers. remembering that the main program data model would not need any graphical data and the UI layer data model would not need any process/relationships data.

I'd assume storing as much as we can in memory would be good for performance, so I personally would push for that approach. It's not like modern comps will have issues with that using a 64 bit engine anyways, we might as well take advantage of new technology if we are going to write our own engine.

This is an assumption that many modern programmers make when building stuff - "Just load the file into memory and work on it there." Doesn't work when the file is terabytes and you only have gigabytes of memory. Happens all the time with genealogy programs.

 

[ls612]

All this discussion about the physical storage layer seems a bit limiting at the moment. We will still need the XML storage layer anyway as that would allow other Civ IV mods to move to the new engine as well.

That could be problematic. I think that due to this we'd need to make all of our own stuff completely.

(from the EULA)

THE SOFTWARE UTILITIES.

The Software may contain a level editor or other similar type tools, assets and other materials (the “Software Utilities”) that permit you to construct or customize new game levels and other related game materials for personal use in connection with the Software (“Customized Game Materials”). In the event the Software contains such Software Utilities, the use of the Software Utilities is subject to the following additional terms, conditions and restrictions:

(a) All Customized Game Materials created by you are exclusively owned by LICENSOR and/or its licensors (as the case may be) and you hereby transfer, assign and convey to LICENSOR all right, title and interest in and to the Customized Game Materials and LICENSOR and its permitted licensors may use any Customized Game Materials made publicly available to you for any purpose whatsoever, including but not limited to for purposes of advertising and promoting the Software;

(b) You will not use or permit third parties to use the Software Utilities and the Customized Game Materials created by you for any commercial purposes, including but not limited to distributing, leasing, licensing, renting, selling, or otherwise exploiting, transferring or assigning the ownership of such Customized Game Materials;

(c) Customized Game Materials must be distributed solely for free; provided, that you may contact LICENSOR for a license to commercially exploit the Customized Game Materials which LICENSOR may grant or deny in its sole discretion;

(d) Customized Game Materials shall not contain modifications to any other executable files;

(e) Customized Game Materials must be used alone and can be created if the Customized Game Materials will be used exclusively in combination with the commercially released retail version of the Software.

(f) Customized Game Materials cannot contain libelous, defamatory or other illegal material, material that is scandalous or invades the rights of privacy or publicity of any third party, or contain any trademarks, copyright-protected work or other property of third parties (without a valid license); and

(g) All Customized Game Materials must contain the proper credits to the authors of the Customized Game Materials and must indicate that LICENSOR is not the author of the Customized Game Materials with additional language that “THIS MATERIAL IS NOT MADE, GUARANTEED OR SUPPORTED BY THE PUBLISHER OF THE SOFTWARE OR ITS AFFILIATES.”

 

[primem0ver]

However, I DO like how hexes can be made to wrap on a globe much easier. I also like how travel from one plot to the next is always the same distance (though I don't think that can quite be said for my proposition here, its a bit closer than we'd get with diag movements on a square grid.) I also find squares are just easier to wrap the mind around.

I hit on this idea of utilizing the vertices of a hex map and realized it could still be displayed as squares if the squares were arranged like brick tile rather than a perfect array like graph paper. To me, it seems to be able to capture all the same effects. We could use the Hexes to generate the global wrapping map but then graphically, and game engine-wise, use squares (even imperfect ones that get tweaked a little to maintain their borders with each other with the centers focused on the hex points) to represent the actual game tiles themselves.[/QUOTE]

Unfortunately this would not allow a global map in the same way that we have been discussing. [B]This is because a hex grid is not very good for making a globe either [/B](though it is better than a completely square grid). I know that we seem to have been discussing a "hex" grid for the globe but that isn't true strictly speaking. An ISEA grid (which is ideal for a globe) is made [B][I]mostly[/I][/B] of hexagons but it also has 12 pentagons that your square grid in a hex (brick) arrangement would not be able to duplicate. Without these 12 pentagons the hex pattern fails to make an adequate globe.

There is no way to use squares adequately on a spherical surface.

[quote="Thunderbrd, post: 12016897"]I think this would pacify all camps. It has the following benefits:

* Movement in any of the main 4 directions is equivalent (travel the same distance with the same # of moves).[/QUOTE]

I disagree with this statement. One now has to zig zag while going north and south in order to stay moving in a straight line.

[quote="Thunderbrd, post: 12016897"]* Closer approximation of distances on 'diagonal' movements (although diagonal means more like knight on chess board diagonal than true NE,NW,SE,SW travel but it still suffices.)[/QUOTE]

This sort of corrects your position above and it is also true. However, movement along points effectively would not be much different.

[quote="Thunderbrd, post: 12016897"]* The graphics would be easier to design.[/QUOTE]
This is NOT true. Tile graphics would remain the same as they are currently. In addition, routes and rivers would be made [B]more[/B] complex because now they have to worry about the swerving back and forth as we move north and south.

[quote="Thunderbrd, post: 12016897"]* We could still wrap such a system around a globe by developing a hex map first and enforcing the tiles to center on the hex vertices and center points and allowing the line edges (and overall tile dimensions to adjust according to need which could tweak the tile graphics subtly enough to not be terribly noticeable (except perhaps where we require pentagons.))[/QUOTE]

Like I mentioned above, a globe map is not a hex map and would not work as one. As a result, this arrangement would not work either.

[quote="Thunderbrd, post: 12016897"]I'm sure there's more but I'll let it get discussed out from here.[/QUOTE]

I agree with you that hexagon tiles would be annoying to do graphically speaking. Pentagon tiles would be even worse. That is one reason why I am suggesting that we use points instead of tiles. The ISEA grid is really based on nearly equilateral triangles. If you go back to the [URL="http://forums.civfanatics.com/showpost.php?p=11999904&postcount=100"]pictures of my ISEA grid based globe "GeoBuilder" program[/URL] you will see that I do not keep track of the number of hexagons. Instead, I keep track of points, triangles, and diamonds (made from 2 triangles). Most of these triangles create hexagons, but there are 60 triangles that create 12 pentagons (5 triangles each).

If we do points on an ISEA grid instead of using tiles, the "tiles" between the points are more or less equilateral triangles. ALL rendering is based on triangles so creating graphics for an ISEA grid would be very simple both in terms of creation and rendering.

 

[AIAndy]

I don't like this direct a mapping because I want relations to be definable dynamically by declarative expressions in the mod XML, and also (as needed) by things like AI modules. Since these may change as we upgrade/enhance, having them map directly to the (storage) table layout would make save game compatibility tricky. However, I DO want the relationship resolution to all take place within the data layer generically, so the benefits of only needing one set of generic code to handle all cases still applies.

I realized only today that it can actually be interpreted as an expression on relations, not on the underlying data layer.
Consider it like a joining of relations (relational algebra), not of tables, then you can implement SQL statements on implicit or declarative relations as well (a relation in this case is not only between two entities, it is an n-ary relation with named parts):
SELECT named_relation_part
FROM named_relation A
INNER JOIN other_named_relation B ON other_named_relation_part
WHERE A.yet_another_named_relation_part = B.yet_another_named_relation_part

It does not really matter how the relations are actually implemented, the query has a meaning regardless.