Possible Future Direction (personal view)

[Acularius]

I tend to believe that sailors and soldiers are at the base 2 different things.

As for the dog thing, generally that was an example.
I remember reading up on it a bit and figured that an 'event' could have wolves trailing your camp... they benefit from the safety of fire and scraps while humans gain early warning.
After a set period of time the grouping could learn to handle the animals and eventually breed them. Could be event determined if the area has wolves 'present'.

I do apologize about the Capital/Capitol thing, it slipped past me.

The tiers are also not locked in place, you can have some of the more advanced forms so long as you can support them.
As for the initial seeding stage, I figured it would serve to populate the world from... I figure to make it as simple as possible, but would allow for it to be expanded upon.
Also, I always 'assume' that I am on 'Earth', so the examples are generally based of them.
Basically what I proposed was a 'population chit' concept, I had brainstormed on how the 'market' system would work that would allow the transition from a communal to a bartering to form of coinage or monetary system.
Essentially it worked out to be called the 'Production value', which worked out to be the (Product units)/[Upkeep+(Work points)].
Production value being what it cost to make the unit.
Product unit: Quantity of product produced from a PC's assigned 'work points', determined by 'tools', 'production site' and 'efficiency'. [Rounded up to the nearest whole number]
Work point: What the Population chit can produce, based off efficiency and density.
Upkeep: Any cost associated with the maintenance of the PC, such as tools, food and the production site.


Past that, I was only proposing a template. A combination of any of those PC's could work with what traditional academia proposes as the proper order of things.

That and I tend to view technology and concepts as simply being there at th right place and the right time, so essentially by chance. Given that the environment and conditions are correct.
[So I tend to say that the 'tech tree' can be removed entirely, which would allow for the differences in society as you propose.]


Edit: As for the mechanics that represent the 'changes' in society, I figure would be a combination of civics and populations that are satisfied tend not to change. (GROSS oversimplification, but as an example)
A mechanic that could be introduced later.

As for the 'Seeding' stage, was an example that truly never stops. Migration will keep on occurring. Also will be useful to show the movement of ideas.
An example is that it is believed that the horse was domesticated by a fairly paternalistic society in th Urals.
These people migrated in ALL directions, displacing the maternal society in Europe that had formed (The Basque are suppose to be descendant from the maternal societies) while moving into Persia and India introducing the Caste system to the Hindu religion.
Or that's the current understanding of the Indo-European grouping.
It would also allow for your examples of the Migration period of Europe which among other things is thought to be one of the reasons for the decline of Western Europe (I tend to believe it was a combination of events and not just one thing)...

http://en.wikipedia.org/wiki/Dog
Since C2C currently starts in 50.000 BCE (Before Common Era), that would mean the dog wasn't domesticated until the earliest example at 31k BCE, where the more common result could appear around 13k BCE...
So generally, it should be possible to domesticate the dog unless the world itself starts before the 100k mark... or there was a setting to remove 'dogs'.
So there is a period of around 19k years for humans to migrate around the world before the earlier example of domesticated dog was found...

The present lineage of dogs was domesticated from gray wolves probably about 15,000 years ago.[5] Though remains of domesticated dogs have been found in Siberia and Belgium from about 33,000 years ago, none of those lineages seem to have survived the Last Glacial Maximum. Although DNA testing suggests an evolutionary split between dogs and wolves around 100,000 years ago, no fossil specimens prior to 33,000 years ago are clearly morphologically domesticated dog.[6][7][8]

I might take a LOT of this for granted since I worked on the family farm a lot growing up though...


As for discovering how to manage 'bigger populations', think of it as discovering the tech 'cooperation' in C2C currently.

Edit: I always assume things happen on an 'Earth' map unless stated otherwise, it helps keeps my ideas cohesive and my examples relevant or we could be talking here to the moon about possible variations in the environment would result in different 'societies'.
Yes, I enjoy talking about those possible variations, I'm a fan of Alternative History.

I do agree that 'Employees' could be scrapped... but I tend to think Sailors should be kept, but begins to be outmoded when civilization moves into Space, granted if 'Earth' is not unified, navies would probably be kept around.


EDIT 2: Actually, Sailors can be scrapped, so long as Soldiers on the cost provide a different source of manpower. Naval manpower, with the unlocking of Air warfare and eventually Space, the Soldiers can give manpower to however they are specialized.
Soldiers can therefore fish, and so will farmers when they unlock.

 

[ls612]

@Koshling:

Are you still interested in doing this at all?

 

[Koshling]

@Koshling:

Are you still interested in doing this at all?

Interested yes, but I actually think it's too large a project for me to want to undertake it right now. Especially without a really solid graphics person on board. I've actually found myself re-engaged with C2C on BtS more recently (largely because I am confining myself to AI and performance work), so I plan to stick with that for now.

 

[xanhou]

Especially without a really solid graphics person on board.

May I present to you: Me.
I have a bit of experience with openGL 3.3+ and would like to learn how to use Ogre (or MOrge, the C# version of Ogre) for graphics.

I could create a completely thread-safe, 3D graphics component, no problem. BUT I do need to proper API description for this component.

From my point of view to most important question would be what component is using the other. Does the Graphics component uses the game to generate graphics, or does the game uses a graphics component to render graphics?

Both approaches have their own advantages.
Graphics uses game:
Advantage: The game has no notion of graphics, it just needs to expose enough info to render everything. (get objects, determine type of objects, retrieve graphics related to this objects, etc). Hence no graphics related code AT ALL inside the game logic code.
Disadvantage: If minor changes are made to the game, it is likely this breaks compatibility with the graphics component.
Game uses graphics:
Advantage: The graphics code does not need to understand the underlying game code.
Disadvantage: The more advanced the graphics become, the more graphics related code gets into the game logic. The graphics engine also need to store much more state info, so it can render stuff in-between calls to the graphics engine.

There is a third option:
Create a layer in-between. A layer that can extract the info needed for graphics and present it to the graphics engine.
This may seem utopia at first sight, but there is one issue: you end up with both advantaged and disadvantages: you still need to adjust a separate component when something in the game changes, the graphics engine still needs its own state. You simply create a separate place to solve there problems.

The biggest advantage of option three is that I could start developing the graphics engine while the game is being developed. When both are in a usable state, the in-between layer can be created.

With that said I can propose a plan:
If the graphics are the biggest hold-back for the project, I could start working on a graphics engine and when done, show you the result. If satisfying, we start working on the rest of the game. If we do this, I do want to be sure that time will be spend on the remaining game, so I did not develop the graphics, only to hear nobody is interested any-more.

 

[ls612]

With that said I can propose a plan:
If the graphics are the biggest hold-back for the project, I could start working on a graphics engine and when done, show you the result. If satisfying, we start working on the rest of the game. If we do this, I do want to be sure that time will be spend on the remaining game, so I did not develop the graphics, only to hear nobody is interested any-more.

I don't know what the others will say, but that sounds like a great idea to me.

 

[strategyonly]

With that said I can propose a plan:
If the graphics are the biggest hold-back for the project, I could start working on a graphics engine and when done, show you the result. If satisfying, we start working on the rest of the game. If we do this, I do want to be sure that time will be spend on the remaining game, so I did not develop the graphics, only to hear nobody is interested any-more.

That will NEVER happen in the CFC community. SomeONE SomeWHERE, will always be interested in new stuff and willing to support any endeavor that is made in the CFC community. The only ones that ever give up are actually the "authors."

 

[xanhou]

I don't know what the others will say, but that sounds like a great idea to me.

I do want to finish my 1600 page book on C# first though. But on day three im at page 500, so that won't take too long.

ps. Dear god thank you for this divine gift called C#.
Regards,
a java programmer.
pps. In the ps. god refers to the genius engineers working at microsoft that designed C#.
In this sense, MS would be the devil: without evil, there cannot be good, yet it is always a pain in the ass. For example: there is no official linux/mac runtime for C#!

 

[Koshling]

May I present to you: Me.
I have a bit of experience with openGL 3.3+ and would like to learn how to use Ogre (or MOrge, the C# version of Ogre) for graphics.

I could create a completely thread-safe, 3D graphics component, no problem. BUT I do need to proper API description for this component.

From my point of view to most important question would be what component is using the other. Does the Graphics component uses the game to generate graphics, or does the game uses a graphics component to render graphics?

Both approaches have their own advantages.
Graphics uses game:
Advantage: The game has no notion of graphics, it just needs to expose enough info to render everything. (get objects, determine type of objects, retrieve graphics related to this objects, etc). Hence no graphics related code AT ALL inside the game logic code.
Disadvantage: If minor changes are made to the game, it is likely this breaks compatibility with the graphics component.
Game uses graphics:
Advantage: The graphics code does not need to understand the underlying game code.
Disadvantage: The more advanced the graphics become, the more graphics related code gets into the game logic. The graphics engine also need to store much more state info, so it can render stuff in-between calls to the graphics engine.

There is a third option:
Create a layer in-between. A layer that can extract the info needed for graphics and present it to the graphics engine.
This may seem utopia at first sight, but there is one issue: you end up with both advantaged and disadvantages: you still need to adjust a separate component when something in the game changes, the graphics engine still needs its own state. You simply create a separate place to solve there problems.

The biggest advantage of option three is that I could start developing the graphics engine while the game is being developed. When both are in a usable state, the in-between layer can be created.

With that said I can propose a plan:
If the graphics are the biggest hold-back for the project, I could start working on a graphics engine and when done, show you the result. If satisfying, we start working on the rest of the game. If we do this, I do want to be sure that time will be spend on the remaining game, so I did not develop the graphics, only to hear nobody is interested any-more.

I essence option 3 was what I had in mind. The game engine itself makes available location info about the entities in the game (cities, units, etc.) and their composition (the units in a sack, the buildings in a city, etc.), together with what are (to it) essentially opaque references to graphic assets (what model to use for a unit say). The engine thus doesn't really know anything about graphics (beyond some opaque labels that identify assets indirectly, which is just opaque meta-info at he gam engine level). Conversely the graphics don't need to know anything about the game rules - just where things are in map-space, which it queries (asynchronously to game operation for the most part) from the engine API and renders as it sees fit.

The only things that complicate this picture (I suspect) are the whole question of tiling (which can be thought of as quantization of location), and pathing. There is a lot of discussion earlier in this thread and also on the blog on the tiling question, so your thoughts on that would be helpful (I lean to the hexes + fixed pentagons approach myself). Pathing is the issue that means that both the UI and the engine have to understand tiling (and hence tiling semantics have to match, or at least be compatible). Pathing display is also an area where the rendering and the engine need to work in tandem (the engine necessarily has to generate paths, but while the human player is deciding what to do the render layer has to be capable of displaying potential paths, which implies path querying).

 

[strategyonly]

Once you'll get something working (at least good) i will try and see if any of the graphic people i know would be willing to help out alittle (i doubt it) but never know they just might (darnell, bernie etc)
Heck never know, even Schafer is working on a new engine protocol.

 

[rightfuture]

Once you'll get something working (at least good) i will try and see if any of the graphic people i know would be willing to help out alittle (i doubt it) but never know they just might (darnell, bernie etc)
Heck never know, even Schafer is working on a new engine protocol.

We should probably all (that means EVERYONE, including players and forum lurkers) reach out to people from different places;
Game Designers, modders, art students, programming students, Civ V complainers, optimists, old Civ 1,2,3 modders other 4x game forum participators, social media, etc!
I was just about to launch a major PR campaign for Caveman2Cosmos, so if you are willing to do it, now is a good time! (so is when Multi-Maps are launched)!!
Share the word about C2C in your way! Let people know we are looking for people who want to expand the vision of C2C!!!
YOUR ECHO MATTERS!

 

[rightfuture]

May I present to you: Me.
I have a bit of experience with openGL 3.3+ and would like to learn how to use Ogre (or MOrge, the C# version of Ogre) for graphics.

I could create a completely thread-safe, 3D graphics component, no problem. BUT I do need to proper API description for this component.

From my point of view to most important question would be what component is using the other. Does the Graphics component uses the game to generate graphics, or does the game uses a graphics component to render graphics?

Both approaches have their own advantages.
Graphics uses game:
Advantage: The game has no notion of graphics, it just needs to expose enough info to render everything. (get objects, determine type of objects, retrieve graphics related to this objects, etc). Hence no graphics related code AT ALL inside the game logic code.
Disadvantage: If minor changes are made to the game, it is likely this breaks compatibility with the graphics component.
Game uses graphics:
Advantage: The graphics code does not need to understand the underlying game code.
Disadvantage: The more advanced the graphics become, the more graphics related code gets into the game logic. The graphics engine also need to store much more state info, so it can render stuff in-between calls to the graphics engine.

There is a third option:
Create a layer in-between. A layer that can extract the info needed for graphics and present it to the graphics engine.
This may seem utopia at first sight, but there is one issue: you end up with both advantaged and disadvantages: you still need to adjust a separate component when something in the game changes, the graphics engine still needs its own state. You simply create a separate place to solve there problems.

The biggest advantage of option three is that I could start developing the graphics engine while the game is being developed. When both are in a usable state, the in-between layer can be created.

With that said I can propose a plan:
If the graphics are the biggest hold-back for the project, I could start working on a graphics engine and when done, show you the result. If satisfying, we start working on the rest of the game. If we do this, I do want to be sure that time will be spend on the remaining game, so I did not develop the graphics, only to hear nobody is interested any-more.

Welcome Xanhou!
Sounds awesome!! Can't wait to see what you can figure out!

We should all learn how to team up and reach out, so that we can figure out what else we can do!!!
Looking forward to your participation! I hope I can help in any way!

 

[xanhou]

I essence option 3 was what I had in mind. The game engine itself makes available location info about the entities in the game (cities, units, etc.) and their composition (the units in a sack, the buildings in a city, etc.), together with what are (to it) essentially opaque references to graphic assets (what model to use for a unit say). The engine thus doesn't really know anything about graphics (beyond some opaque labels that identify assets indirectly, which is just opaque meta-info at he gam engine level). Conversely the graphics don't need to know anything about the game rules - just where things are in map-space, which it queries (asynchronously to game operation for the most part) from the engine API and renders as it sees fit.

The only things that complicate this picture (I suspect) are the whole question of tiling (which can be thought of as quantization of location), and pathing. There is a lot of discussion earlier in this thread and also on the blog on the tiling question, so your thoughts on that would be helpful (I lean to the hexes + fixed pentagons approach myself). Pathing is the issue that means that both the UI and the engine have to understand tiling (and hence tiling semantics have to match, or at least be compatible). Pathing display is also an area where the rendering and the engine need to work in tandem (the engine necessarily has to generate paths, but while the human player is deciding what to do the render layer has to be capable of displaying potential paths, which implies path querying).

I see the problem.
The problem with the problem is that the UI will need to know the tiling anyway: how can I draw tiles if I do not know their shape?
I think it would be best to stick to squares at first, but design everything such that we can extend the project later on to support hexagons, and finally a globe build of hexagons and pentagons. The only reason I can think of not to start with squares is that it complicates a lot of the AI / game logic code. For the graphics engine and mouse processing it is easier to start simple and build up.

Keeping modding in mind I see the following structure:
Game logic exposes an API that provides the info for the UI.
Various different render API's exist: One for squares, one for hexagons and one for a globe of hexagons and pentagons.
Each UI module is build to support a pair of a game logic API and a graphics API.
The UI module would be the only "Active" module, in that both the render and game logic modules take no action without an order of the UI (although the game logic may change because of networking or AI, but those can be seen as separate UI's working on the same game logic).

But we have to think carefully when designing the API's and where to put what code. Here are some example problems I just came up with:
- Are all actions on the game logic instant? Aka: move unit from x to y is an atomic action. This means the UI is responsible for delaying the graphics and such. My answer would be: yes.
- Do we make it such that different UI's (player, AI, network) work concurrent on the same game logic? This sounds really complex for the AI, since something may change while the AI is working with it, changing assumptions, making the AI move invalid, etc ,etc. It is, however, very use-full for playing in a simultaneous turns mode. I think it would be best to freeze all player interaction when processing the AI.
- Can we cache pathing solutions? This sounds like a much better improvement for the AI then multi-threading. Especially if the AI is moving stacks of units around. I have no final answer to the problem of AI optimization, but we should keep it in mind.
- Is lighting up buttons on hovering over them the responsibility of the graphics code, or the UI code. Both have advantages: If the graphics do the work, the UI code becomes cleaner, but if the UI does it, you know for sure that if the button lights up, the UI code is not hanging in some loop trying to calculate some AI pathing, hence your button click is processed instantly. I prefer leaving this to the graphics (similar to any other GUI code I have seen).
- About networking: I think it would be best to have a single instance of the game (hereby referred to as a single PC), take control. Every other PC will probe that PC for the truth. All PC's send the commands of the user to that PC, rather then to there own state of the game. However, pathing issues may be solved on the local game state, until an actual command is given that changes the state of the game. This can result in some strange situations when playing simultaneous turns, but at least it will be consistent, valid behaviour. Example: two rival players move there unit to location X and the game does not see the difference between a move and attack order (yet), they do this at the same time. Then one of the moves is executed first on the server, after which the second move becomes an attack on the unit that just moved there!
- Does the UI needs to make complicated queries to the game logic or is all info presented in simple ways. Example: amount of gold income for the next turn. The UI could retrieve a single value, but could also have to make a query on a data set containing info about gold income/expenses. I think there is no definite answer to this. It will be one of the major things that will define the game logic API.

That being said. I will try to work on a simple render engine for squares at first. Note that I will keep it very simple, so I can build things up slowly. Example: I start with a top down view, no 3D, no GUI. Then add GUI, then 3D, then hexagon, etc.

 

[strategyonly]

I start with a top down view, no 3D, no GUI. Then add GUI, then 3D, then hexagon, etc.

Now that sounds like a plan

 

[Koshling]

I see the problem.
The problem with the problem is that the UI will need to know the tiling anyway: how can I draw tiles if I do not know their shape?

You can't, but some of the discussions suggested tile-less solutions. However, I think those are probably over-complicated to begin with.

I think it would be best to stick to squares at first, but design everything such that we can extend the project later on to support hexagons, and finally a globe build of hexagons and pentagons. The only reason I can think of not to start with squares is that it complicates a lot of the AI / game logic code. For the graphics engine and mouse processing it is easier to start simple and build up.

Agreed

Keeping modding in mind I see the following structure:
Game logic exposes an API that provides the info for the UI.
Various different render API's exist: One for squares, one for hexagons and one for a globe of hexagons and pentagons.
Each UI module is build to support a pair of a game logic API and a graphics API.
The UI module would be the only "Active" module, in that both the render and game logic modules take no action without an order of the UI (although the game logic may change because of networking or AI, but those can be seen as separate UI's working on the same game logic).

I disagree here with separate APIs being needed. A single API which provides a means to enumerate tiles, a set of coordinates for a given tile, and a way to retrieve a specific tile given it's coordinates (or retrieve nearest) is tiling-geometry independent. That is not to say that the engine and the UI don't have to agree on the geometry (at runtime), but the API can be fixed regardless. The coordinate system should be 3-dimensional, layer-supporting (but we can all work to single layer at first) and multi-map supporting. Since we will be focused on globes I suggest polar coordinates, so something like

(alpha, beta, height, layer_id, map_id)

where alpha and beta are latitudinal angle, and longitudinal angle.
How the UI chooses to render that is up to it (3D globe you can zoom into, or just distort it and map to the kind of projection CiV uses now, with adjustable tile size distortions if you zoom right out). For an early run you could (for instance) simply, not provide the ability to zoom out so that the map subtends more than, say 30% of arc, and approximate the bit you are displaying as planar. The player could still pan the section displayed around (or click on a globe to center it?), but the implementation would be initially simpler for the UI than actually zooming out to a globe.

The map id is to allow for multiple planets (and possibly more abstract maps of inter-planetary/inter-stellar space), the layer id is to allow for things like underground maps (we can assume a single layer for a while I'm sure).

Querying the map entity itself would tell you things like the diameter of the globe (necessary to scale things), tile size, map type (planetary globe, space, ... - just implementing a planetary globe for now would be fine)

But we have to think carefully when designing the API's and where to put what code. Here are some example problems I just came up with:
- Are all actions on the game logic instant? Aka: move unit from x to y is an atomic action. This means the UI is responsible for delaying the graphics and such. My answer would be: yes.

Agreed

- Do we make it such that different UI's (player, AI, network) work concurrent on the same game logic? This sounds really complex for the AI, since something may change while the AI is working with it, changing assumptions, making the AI move invalid, etc ,etc. It is, however, very use-full for playing in a simultaneous turns mode. I think it would be best to freeze all player interaction when processing the AI.

Simultaneous so far as the UI is concerned. What locking we perform in the engine is a separable decision. However, I want the engine (at least its modeling layers) to see all AIs and humans as equivalent, which amounts to simultaneously connected UIs. I see there being a callback the engine makes to the UI to tell it that it's ok to make moves, but whether it tells multiple at once they can is up to it. In concrete API terms this DOES mean that order execution APIs will always have the possibility of returning a failure code due to some other action having got in first, and invalidated the action the user just asked to perform.
In the first instance (and we can code this first) we'll only implement strictly serial turns however.

- Can we cache pathing solutions? This sounds like a much better improvement for the AI then multi-threading. Especially if the AI is moving stacks of units around. I have no final answer to the problem of AI optimization, but we should keep it in mind.

The engine will cache what it can to minimize path generation times when the UI asks for a path. The UI should not assume things are cachable, since once we enable simultaneous turns that will give us a cache invalidation issue across the API.

- Is lighting up buttons on hovering over them the responsibility of the graphics code, or the UI code. Both have advantages: If the graphics do the work, the UI code becomes cleaner, but if the UI does it, you know for sure that if the button lights up, the UI code is not hanging in some loop trying to calculate some AI pathing, hence your button click is processed instantly. I prefer leaving this to the graphics (similar to any other GUI code I have seen).

Definately agree. The engine should not even be aware of what controls the UI chooses to display (it can be text based for all the engine should care), so it cannot possibly know what the UI wants to highlight with lights etc.

- About networking: I think it would be best to have a single instance of the game (hereby referred to as a single PC), take control. Every other PC will probe that PC for the truth. All PC's send the commands of the user to that PC, rather then to there own state of the game. However, pathing issues may be solved on the local game state, until an actual command is given that changes the state of the game. This can result in some strange situations when playing simultaneous turns, but at least it will be consistent, valid behaviour. Example: two rival players move there unit to location X and the game does not see the difference between a move and attack order (yet), they do this at the same time. Then one of the moves is executed first on the server, after which the second move becomes an attack on the unit that just moved there!

The plan is to make it multi-tier, so the machine the core engine is running on may not be one that the UI is running on. The UI will be backed by a game-model module which acts as a proxy to the (possibly remote) engine. All UIs and their proxies will talk to a single engine instance. This allows for internet hosted game instances and mutliplayer without synchronization issues. The initial release will however require all components to be co-hosted (so single player only at first with co-hosted AIs)

- Does the UI needs to make complicated queries to the game logic or is all info presented in simple ways. Example: amount of gold income for the next turn. The UI could retrieve a single value, but could also have to make a query on a data set containing info about gold income/expenses. I think there is no definite answer to this. It will be one of the major things that will define the game logic API.

The game model should provide distinct values where possible (so total income per turn would be one, and so on). However, we might well achieve this with value ids defined in XML to allow for meta-game modding. In such a schema the API itself would be fixed but have a small call-set. For example:

ValueType getCurrentValue(ValueTypeId);

might be a method on all game entities, and for a particular meta-game (CiV IV say) a valueTypeId might be VALUE_TYPE_ID_GOLD_PER_TURN.
The UI (code) can be fixed for a defined meta-game ruleset (that is changing meta-game rules might require a corresponding UI change), so the UI and meta-game authors (which is the same as engine authors in the first instance) would need to agree a set of basic concepts (like gold-per-turn) that are queriable on (appropriate) entities (like players, cities, etc.). We can just assume the set that is used by CiV IV for now (he said, waving his hands airily!)

That being said. I will try to work on a simple render engine for squares at first. Note that I will keep it very simple, so I can build things up slowly. Example: I start with a top down view, no 3D, no GUI. Then add GUI, then 3D, then hexagon, etc.

Sounds good

 

[xanhou]

I have encountered an issue that I cannot solve without the agreement of everyone else.

I was hoping to use MOgre, a C# wrapper for Ogre for the graphics.
I have worked with bare-bone OpenGL and can tell you it is VERY frustrating (I even found the differences between NVidia and ATI driver implementations of OpenGL, resulting in a game that could only be played on ATI cards ).
Ogre is a rendering engine that would allow me to skip all the tedious low level work and actually start working on the graphics code itself.
MOgre is the most advanced C# wrapper for Ogre. There exist two others: Axiom and OgreDotNet. Axiom is actually not a wrapper, but a port, which is lagging multiple versions of Ogre behind. OgreDotNet is a wrapper, hence has less trouble keeping up with Ogre, But the last post on the OgreDotNet forum was made in 2011...
MOgre is up-to-date and actively supported.
So it would seem MOgre is the obvious choice.

But there is a catch.
MOgre uses a wrapping technique not supported by Mono, the linux/Mac replacement of .Net, Hence if I use MOgre, it will be a Windows only engine...

I'm going to investigate whether or not Axiom supports enough features for our purpose.

I'm open to other options, but note that I want more than a bare-bone C# wrapper for OpenGL/DirectX (@See OpenTK or XNA).

I will report back when I know more about the capability of Axiom, and what it is lacking.

 

[ls612]

I have encountered an issue that I cannot solve without the agreement of everyone else.

I was hoping to use MOgre, a C# wrapper for Ogre for the graphics.
I have worked with bare-bone OpenGL and can tell you it is VERY frustrating (I even found the differences between NVidia and ATI driver implementations of OpenGL, resulting in a game that could only be played on ATI cards ).
Ogre is a rendering engine that would allow me to skip all the tedious low level work and actually start working on the graphics code itself.
MOgre is the most advanced C# wrapper for Ogre. There exist two others: Axiom and OgreDotNet. Axiom is actually not a wrapper, but a port, which is lagging multiple versions of Ogre behind. OgreDotNet is a wrapper, hence has less trouble keeping up with Ogre, But the last post on the OgreDotNet forum was made in 2011...
MOgre is up-to-date and actively supported.
So it would seem MOgre is the obvious choice.

But there is a catch.
MOgre uses a wrapping technique not supported by Mono, the linux/Mac replacement of .Net, Hence if I use MOgre, it will be a Windows only engine...

I'm going to investigate whether or not Axiom supports enough features for our purpose.

I'm open to other options, but note that I want more than a bare-bone C# wrapper for OpenGL/DirectX (@See OpenTK or XNA).

I will report back when I know more about the capability of Axiom, and what it is lacking.

Given that Koshling wants to use WCF for MP, I don't think that would be a big deal. I certainly have no issue with making this windows only, if someone really wants to port it to Linux they can, as it is open source.

 

[xanhou]

I disagree here with separate APIs being needed. A single API which provides a means to enumerate tiles, a set of coordinates for a given tile, and a way to retrieve a specific tile given it's coordinates (or retrieve nearest) is tiling-geometry independent. That is not to say that the engine and the UI don't have to agree on the geometry (at runtime), but the API can be fixed regardless.

Hmmm. I see your point. The advantage would be that a single UI module can support different games/versions/tilings (as long as the remaining API did not change either).
It could even be possible to choose the rendering engine runtime. But it would still require different engines for different tilings. Hmmm. I see some good opportunity for inheritance when designing the graphics engine. A single API for units/city, one for GUI elements and one for the tiling. This could work.

where alpha and beta are latitudinal angle, and longitudinal angle.
How the UI chooses to render that is up to it (3D globe you can zoom into, or just distort it and map to the kind of projection CiV uses now, with adjustable tile size distortions if you zoom right out). For an early run you could (for instance) simply, not provide the ability to zoom out so that the map subtends more than, say 30% of arc, and approximate the bit you are displaying as planar. The player could still pan the section displayed around (or click on a globe to center it?), but the implementation would be initially simpler for the UI than actually zooming out to a globe.

When I have a 3D engine up and running, zooming and rotating is a piece of cake.
I first focus on 2D though.

The plan is to make it multi-tier, so the machine the core engine is running on may not be one that the UI is running on. The UI will be backed by a game-model module which acts as a proxy to the (possibly remote) engine. All UIs and their proxies will talk to a single engine instance. This allows for internet hosted game instances and multiplayer without synchronization issues. The initial release will however require all components to be co-hosted (so single player only at first with co-hosted AIs)

Im not sure if we have the same idea, but different ways of explaining it, or that we have different ideas for the networking. Based on your description, I can think of three options:

Left top is what i would do. The advantage is that the proxy does not differ from an actual game engine. The engine simply does not know it is not used as proxy. Updates are applied by some networking class that processes the updates. The bottom version also has this advantage, but the user has to wait for the networking when it wants pathing suggestions, hence massive lag if you are not on a LAN...
Here comes the best part of the first option: When you are the host, or you are in single player, you make the Actual game engine the same as the proxy engine and remove the network layer (which has the same API as the game engine). This way, the UI (called client here) does not even know (after initialization) whether it is a host or client! Of course this is stored somewhere, but the UI does not care, it uses the same code.
Basically the UI thinks it has two different instances of a game engine. One for issuing commands and one for retrieving info. Whether the first one is a network class that sends everything to the host or both engines are the same is irrelevant for the UI. Making UI programming a lot easier!

 

[Koshling]

Hmmm. I see your point. The advantage would be that a single UI module can support different games/versions/tilings (as long as the remaining API did not change either).
It could even be possible to choose the rendering engine runtime. But it would still require different engines for different tilings. Hmmm. I see some good opportunity for inheritance when designing the graphics engine. A single API for units/city, one for GUI elements and one for the tiling. This could work.


When I have a 3D engine up and running, zooming and rotating is a piece of cake.
I first focus on 2D though.



Im not sure if we have the same idea, but different ways of explaining it, or that we have different ideas for the networking. Based on your description, I can think of three options:

Left top is what i would do. The advantage is that the proxy does not differ from an actual game engine. The engine simply does not know it is not used as proxy. Updates are applied by some networking class that processes the updates. The bottom version also has this advantage, but the user has to wait for the networking when it wants pathing suggestions, hence massive lag if you are not on a LAN...
Here comes the best part of the first option: When you are the host, or you are in single player, you make the Actual game engine the same as the proxy engine and remove the network layer (which has the same API as the game engine). This way, the UI (called client here) does not even know (after initialization) whether it is a host or client! Of course this is stored somewhere, but the UI does not care, it uses the same code.
Basically the UI thinks it has two different instances of a game engine. One for issuing commands and one for retrieving info. Whether the first one is a network class that sends everything to the host or both engines are the same is irrelevant for the UI. Making UI programming a lot easier!

I agree with your logic, but I see that as being embodied equally well by option (2), which is what I meant. Both the engine and the proxy expose precisely the same UI (which would be described in terms of C# interface classes which are abstract interfaces). Said API might well be separate interfaces for command and query (or indeed some larger collection that splits into that taxonomy and allows for a model-view-controller type pattern). The point is that (for both query and command paths) the proxy has any necessary 'remoting' network intelligence (and **possibly** some caching functionality, which might b significant to things like pathing as you mention). In the first version it would (as you suggest) be entirely NULL and the interface provider you actually bind to would be the actual engine (or at least the proxy is minimal and just serves to cross a process boundary on the local machine)

 

[xanhou]

I agree with your logic, but I see that as being embodied equally well by option (2), which is what I meant. Both the engine and the proxy expose precisely the same UI (which would be described in terms of C# interface classes which are abstract interfaces). Said API might well be separate interfaces for command and query (or indeed some larger collection that splits into that taxonomy and allows for a model-view-controller type pattern). The point is that (for both query and command paths) the proxy has any necessary 'remoting' network intelligence (and **possibly** some caching functionality, which might b significant to things like pathing as you mention). In the first version it would (as you suggest) be entirely NULL and the interface provider you actually bind to would be the actual engine (or at least the proxy is minimal and just serves to cross a process boundary on the local machine)

Aah, I now see the difference between our approaches. In my version the UI determines what calls will be send over the net and what calls go to the client engine. In your version this decision is made by a separate layer between the UI and engine, which can be inserted or left out, since it has the same API as the engine (implements the same interface).
Both approaches have their advantages, as usual.
In your version the UI code makes calls to only a single engine. Which cleans up that code a bit. However, it may cause small limitations to the UI's capabilities, since the UI does not know whether it is communicating with the main engine or with the proxy engine. I could not come up with a concrete example, so I guess this situation will be rare. Because such situation could be solved by extending the API of the game engine a bit, I think your solution is the best. (Extending the API is as simple as adding a boolean parameter to the method that needs to be send to both engines).

 

[KMRblue1027]

FreeCiv is open source. Is it possible to use that as a base until a more advanced engine can be built?