Possible Future Direction (personal view)

[primem0ver]

Furthermore, the places where C++ excels are in things like graphics-associated calculations, which are anyway implemented inside of things like DirectX (and often are running on the GPU). Switches between managed and unmanaged code are a pain, and the martialing mechanisms needed themselves introduce overhead, so you cannot do it at a very granular level and still get any performance benefit. The one place outside of the graphics where I can see there being a significant potential performance advantage, is in the map-generation modeling code. However, this is not running during gameplay (so doesn't matter turn to turn), and could anyway be written as a totally separate utility calling through same cross-process APIs that the UI/AI would use if necessary (and then be written in whatever you want provided someone writs an API wrapper)

C++ can be used to write managed code as well and the boundary between C++ managed code and c# managed code is practically non-existent when it comes to object access.

I could be wrong but I would think it would be possible to write C++ code that handles both managed and unmanaged classes to allow the exchange of information between basic types. Since number crunching is almost exclusively handled by simple (non string) types and structures, little or no marshalling would be necessary since c# allows explicit ordering in structures when necessary for cross-language compatibility; the rest would only involve simple types. I would think this would be relatively simple to accomplish. If so, the C++ intermediary managed code could act as the exchange layer between the c# code and the native number crunching.

 

[ls612]

Furthermore, the places where C++ excels are in things like graphics-associated calculations, which are anyway implemented inside of things like DirectX (and often are running on the GPU). Switches between managed and unmanaged code are a pain, and the martialing mechanisms needed themselves introduce overhead, so you cannot do it at a very granular level and still get any performance benefit. The one place outside of the graphics where I can see there being a significant potential performance advantage, is in the map-generation modeling code. However, this is not running during gameplay (so doesn't matter turn to turn), and could anyway be written as a totally separate utility calling through same cross-process APIs that the UI/AI would use if necessary (and then be written in whatever you want provided someone writs an API wrapper)

I agree, that is why I want to use OGRE with the C# MOGRE wrapper for graphics. Other than that I'd much rather work with managed code for this as it is harder to make stupid mistakes with that.

 

[Koshling]

C++ can be used to write managed code as well and the boundary between C++ managed code and c# managed code is practically non-existent when it comes to object access.

I could be wrong but I would think it would be possible to write C++ code that handles both managed and unmanaged classes to allow the exchange of information between basic types. Since number crunching is almost exclusively handled by simple (non string) types and structures, little or no marshalling would be necessary since c# allows explicit ordering in structures when necessary for cross-language compatibility; the rest would only involve simple types. I would think this would be relatively simple to accomplish. If so, the C++ intermediary managed code could act as the exchange layer between the c# code and the native number crunching.

C++ managed code is just-in-time compiled to the same runtime intermediate language as C# managed code is. Any performance benefits you may have had from using C++ raw certainly go away if you use the managed compiler.

 

[primem0ver]

I know that pure managed code classes using .NET use the JIT compiler. Does the same hold for mixed code? What about IJW (It just works) and code that implements the stuff found here?

http://msdn.microsoft.com/en-us/library/aa712789%28v=vs.71%29.aspx

The answer may be in the documentation but I am still reading it.

 

[Koshling]

I know that pure managed code classes using .NET use the JIT compiler. Does the same hold for mixed code? What about IJW (It just works) and code that implements the stuff found here?

http://msdn.microsoft.com/en-us/library/aa712789%28v=vs.71%29.aspx

The answer may be in the documentation but I am still reading it.

I hadn't realized this technique was available, and on first reading I does look like it would provide the benefits. However, I STILL wouldn't use unmanaged code over managed as an initial design decision, just because of the reliability and productivity benefits of the managed environment. Having said that, it IS reasonable to consider moving some performance-critical pieces into unmanaged code based on profiling - that is - I would start fully managed, and then if profiling showed up hot-spots that couldn't reasonably be further optimized in managed space, and appeared to have the right characteristics to benefit from unmanaged code, THEN migrate them.

Thanks for pointing out the mixed model though - good to know it exists.

 

[masaykh]

Koshling, do you start coding or is it only concept now?
There is russian site of game developers and i can open thread for recruiting if something already started to appear in code.

 

[primem0ver]

I hadn't realized this technique was available, and on first reading I does look like it would provide the benefits. However, I STILL wouldn't use unmanaged code over managed as an initial design decision, just because of the reliability and productivity benefits of the managed environment. Having said that, it IS reasonable to consider moving some performance-critical pieces into unmanaged code based on profiling - that is - I would start fully managed, and then if profiling showed up hot-spots that couldn't reasonably be further optimized in managed space, and appeared to have the right characteristics to benefit from unmanaged code, THEN migrate them.

Thanks for pointing out the mixed model though - good to know it exists.

Sounds like a reasonable approach for the most part. It's just that having already built a C# engine I want to remake because I know it isn't as efficient as it could be, I just was hoping to avoid as much unnecessary re-coding as possible.

 

[AIAndy]

Sounds like a reasonable approach for the most part. It's just that having already built a C# engine I want to remake because I know it isn't as efficient as it could be, I just was hoping to avoid as much unnecessary re-coding as possible.

You will never reach an optimum of efficiency as you could always write it all in highly optimized assembler and offload a lot of computations on the GPU. Remember that there is also stability and coding time to consider. Writing it all in managed code then profiling it to find the performance hotspots and only optimizing those is a better approach in both stability and coding time.

 

[Galacticat42]

I remember this new game project being talked about a while ago, but this is the first time I've seen this thread and any talks on it. So here I am! Koshling - if you do go about this, you can count me in on the project.

-I've gone over the majority of the thread and this is what I have to say-

For tiles, I like the points idea, but instead of a hexagonal/triangular/square approach, why not a dual-overlay approach? For example, on the first run on map generation, the heightmap is made with triangles. Second pass, the map recognizes a hexagonal layout (vertici and edges) and then for a third pass an inverted hexagon. This way, the the map itself is made with hexagons, yet during gameplay players see all the directions they can move as if a simplified circle. This way, all directions can be appropriately assigned a distance while not having to zig-zag any particular direction.

GUI-wise, what the player sees, is a tile-less landscape with a circle defining where the next 'tile' spots are. Instead of seeing every single point possible, they simply see a array of directions they can take from a targetted unit. Using this system would effectively allow units to go the four cardinal directions as well as East-North-East, North-North-East, etc. with twelve possible directions in total. The aformentioned triangles will define what is inside each place and allow for a passible or impassible tag that the AI will be able to use for pathfinding.

EDIT:
As for the question about money, I say yes and no. It's my strong belief that free-to-play games are the future of PC gaming as proven multiple times over that financially, companies do better via optional micro-transactions than outright selling a game. Of course some companies like Blizzard do both, but they can afford to sell their games because of their huge fanbase. Games like EVE by CCP on the other hand is a free to play game with microtransactions that players buy PLEX or other in-game accessories that are non-essential. Granted, a game like this would be difficult to have such a financial structure where modability is the name of the game. However, I have no doubt that something can be done to support it.

EDIT2: I'll have an example pic up here once I get back home.

On another note, I suggest regulating EVERYTHING gameplay-wise through complex algorithms as to keep balance in check - perhaps using my anti-overpower logarithmic algorithm as a basic checksum between other equations. This way, for example, one can derive the tax income with anything between simulation of economy stifling, to game difficulty modifiers and never be overpowered or unbalanced no matter how many buildings there are.

 

[ls612]

As for the question about money, I say yes and no. It's my strong belief that free-to-play games are the future of PC gaming as proven multiple times over that financially, companies do better via optional micro-transactions than outright selling a game. Of course some companies like Blizzard do both, but they can afford to sell their games because of their huge fanbase. Games like EVE by CCP on the other hand is a free to play game with microtransactions that players buy PLEX or other in-game accessories that are non-essential. Granted, a game like this would be difficult to have such a financial structure where modability is the name of the game. However, I have no doubt that something can be done to support it.

This is the way I see it (sorry if I am a bit curt, I don't mean to be). Adding money to this can only cause problems. The Civ modding community has lasted for 7 years on volunteer efforts, I don't see why AXXXXE couldn't do that too.

I would strongly encourage us to license AXXXXE under the GPL, that is a very well known license in the open-source community and using it would open up the use of many pre-existing open-source libraries in AXXXXE.

But please let is not go down this path further, it will only lead to distractions.

 

[Galacticat42]

So I'm being a bit lazy and decided not to post what I said since it would take a lot of math just to set up the example in the first place (Needs perfect placing with distortions for globes). So as a replacement, I'm putting this pattern up for debate on globe tiles. Plus, keep in mind: who says we need a 2D representation of the world in the main viewport?

Spoiler :

 

[Koshling]

FYI - I haven't been active here for a couple of weeks for the same reason that I haven't been active generally on C2C - work is hugely busy right now. However, I will be getting back to this when things calm down.

 

[ls612]

FYI - I haven't been active here for a couple of weeks for the same reason that I haven't been active generally on C2C - work is hugely busy right now. However, I will be getting back to this when things calm down.

After Christmas? My RL has been a pain too and added to my concerns about C2C I haven't got much work done either recently. I hope that we can get some return to normalcy after the holidays.

 

[primem0ver]

For tiles, I like the points idea, but instead of a hexagonal/triangular/square approach, why not a dual-overlay approach? For example, on the first run on map generation, the heightmap is made with triangles. Second pass, the map recognizes a hexagonal layout (vertici and edges) and then for a third pass an inverted hexagon. This way, the the map itself is made with hexagons, yet during gameplay players see all the directions they can move as if a simplified circle. This way, all directions can be appropriately assigned a distance while not having to zig-zag any particular direction.

GUI-wise, what the player sees, is a tile-less landscape with a circle defining where the next 'tile' spots are. Instead of seeing every single point possible, they simply see a array of directions they can take from a targetted unit. Using this system would effectively allow units to go the four cardinal directions as well as East-North-East, North-North-East, etc. with twelve possible directions in total. The aformentioned triangles will define what is inside each place and allow for a passible or impassible tag that the AI will be able to use for pathfinding.

The problem with this approach is that the base model: an icosahedron already has points at the top and bottom. Inverting and dividing those the same way would result in the same arrangement. The only way to get the effect that you are describing is to rotate the grid PI/5 degrees in one direction.

However, doing that will cause 22 pentagons instead of 12 that are offset from each other by 1/10 of a circle and the two "polar" pentagons will have 2 different arrangements. From what I can surmise, this will not give you the arrangement you would expect since the pentagons will cause an interruption in the hexagon arrangement you are suggesting. Drawing the grid would probably become treacherously complex. It is already fairly complex as it is. We will already have our hands full by creating a grid that is divisible by prime numbers other than 2 (to make the number of possible grid points more variable).

 

[ls612]

The problem with this approach is that the base model: an icosahedron already has points at the top and bottom. Inverting and dividing those the same way would result in the same arrangement. The only way to get the effect that you are describing is to rotate the grid PI/5 degrees in one direction.

However, doing that will cause 22 pentagons instead of 12 that are offset from each other by 1/10 of a circle and the two "polar" pentagons will have 2 different arrangements. From what I can surmise, this will not give you the arrangement you would expect since the pentagons will cause an interruption in the hexagon arrangement you are suggesting. Drawing the grid would probably become treacherously complex. It is already fairly complex as it is. We will already have our hands full by creating a grid that is divisible by prime numbers other than 2 (to make the number of possible grid points more variable).

I've been thinking about this, and I'm starting to think that rendering the tiles as globes natively would be more effort than it would be worth. Making flat maps makes the math behind this much easier and gives far more flexibility in both workable map sizes and different topological systems. Is it slightly less realistic, sure a little. But it makes things much more of a hassle and involves wierd shaped tiles in almost all cases, and besides, how much stuff do you think will be happening at the poles during the game? (before modern nuclear subs, but that can be handled by map wrapping.)

 

[ls612]

While I'm at it I'd like to bring some legal issues up for discussion (I know, fun, right?)

1. The license. OGRE is licensed under the MIT license, which is not the issue, as it is quite permissive. However, the wrapper MOGRE for the managed aspect of it is licensed under the LGPL, which is more restrictive. I've linked to it at the bottom of the post, but the long and the short of it is that we'd need to license AXXXXE under an open source license to use MOGRE. This is what we were intending to do all along (I assume). I'd recommend the GPL (also linked at the bottom of the post) because it is widely accepted and used in the open-source community and so we wouldn't be taking many risks using that. However this matter certainly needs discussion, even if we don't use OGRE for rendering (because we'd still need to decide what open-source license we'd use).
2. Resources. The Civ IV EULA states that all mods' copyrights belong to Firaxis/2K, so we wouldn't be able to transfer anything from C2C to AXXXXE. Graphics-wise this was already true because the NIF file format is proprietary, and code-wise we are going to be rewriting everything anyways. However we would need to be absolutely sure that we didn't include any Civ 4 stuff in AXXXXE, to avoid potential legal complications.

GPL License
LGPL License

 

[AIAndy]

While I'm at it I'd like to bring some legal issues up for discussion (I know, fun, right?)

1. The license. OGRE is licensed under the MIT license, which is not the issue, as it is quite permissive. However, the wrapper MOGRE for the managed aspect of it is licensed under the LGPL, which is more restrictive. I've linked to it at the bottom of the post, but the long and the short of it is that we'd need to license AXXXXE under an open source license to use MOGRE. This is what we were intending to do all along (I assume). I'd recommend the GPL (also linked at the bottom of the post) because it is widely accepted and used in the open-source community and so we wouldn't be taking many risks using that. However this matter certainly needs discussion, even if we don't use OGRE for rendering (because we'd still need to decide what open-source license we'd use).

1. • 
     The big difference between LGPL and GPL is that you can integrate libraries that are licensed under LGPL in a program that uses any kind of license as long as you separate the library part from the rest, e.g. by using a shared library mechanism.
     So no, it is not required to license AXXXXE using an open source license.

 

[ls612]

The big difference between LGPL and GPL is that you can integrate libraries that are licensed under LGPL in a program that uses any kind of license as long as you separate the library part from the rest, e.g. by using a shared library mechanism.
So no, it is not required to license AXXXXE using an open source license.

Oops, I confused the two in my head while posting that. At any rate making it open source would make things much easier for many reasons, not the least of which is that we could keep our source control with Sourceforge. I'd advocate using an open source license personally, but it's good to know we have some leeway on the specific license.

 

[primem0ver]

I've been thinking about this, and I'm starting to think that rendering the tiles as globes natively would be more effort than it would be worth. Making flat maps makes the math behind this much easier and gives far more flexibility in both workable map sizes and different topological systems. Is it slightly less realistic, sure a little. But it makes things much more of a hassle and involves wierd shaped tiles in almost all cases, and besides, how much stuff do you think will be happening at the poles during the game? (before modern nuclear subs, but that can be handled by map wrapping.)

As I mentioned earlier, the basic foundation for this system already exists. I already wrote an engine that produces the kind of grid we have been discussing. It needs to be improved of course. But technically speaking most of the hard work has been done already. There are only two difficult tasks left:

1. Coming up with a way to incorporate divisions other than two into triangle strips to avoid drawing each triangle separately. Finding a generic method will allow us to incorporate any prime number, making the number of points as flexible as any flat map.
2. Coming up with a way to simplify the resolution when zooming out in a way that more accurately represents the scene (one already exists, it just isn't the best method).

Also: sure flat maps are easier in terms of execution. But in terms of graphics the "weird" shapes are not an issue because all "tile" based graphics would be rendered using triangles that are small enough that the "stretching" from 1/5 to 1/6 of a polygon would be pretty much unnoticeable. Coming up with a couple complex algorithms will still beat the time needed for endless variation of plot graphics for any strictly tile base map system (unless we use triangle plots). Especially since we are short graphic artists and have plenty of programmers.

 

[rightfuture]

Stumbled across a link for a unique and amazing project which seems to be on the same course as where C2C and PrimeMover are both headed,
It is actually more Simulation and Civilization sandbox than Ultima or Roguelike but it has dynamic elements of both. The visual representation, simulation, terrain and element generation, and historic scope should appeal to almost everyone. It is just as ambitious as C2C has become and could be cross-inspirational.
Ultima Ratio Regum
http://www.facebook.com/UltimaRatioRegumRoguelike
http://www.ultimaratioregum.co.uk/
http://www.ultimaratioregum.co.uk/game/info/
http://www.ultimaratioregum.co.uk/game/development-plan-2/
This is a list of current development priorities. Those with a strikethrough have been completed, and those with brackets give more detail about its current state. Next releases:.

0.2.2, February/March 2013:
- World map coloured according to time of day
- New map key and information
- Memory use/loading time improvement
- More messages when moving around the world
- Seasonal soil/tree ‘look’ changes
.
0.3.0, May/June 2013:
- Language generation (20%)
- Myth & legend generation
- History generation
- Civilization generation
- Flag/religious symbol generation (20%)
- Coats of arms generation
- Present-day civilization territories
- Rule, Command and Civilization Traits

There is a working and downloadable file. Currently Version 3.
You have to see the visuals in the links to truly appreciate this.
It's almost as ambitious as C2C, CIV++. A little less Dwarf Fortress(RPG) and more Sim World focusing on strategy, living world, and open ended playing. and it includes great ideas for procedural generation and variation.