primem0ver
Emperor
LOL Laskaris! You stole my thunder!
Possible Future Direction (personal view)
- Thread starter Koshling
- Start date
Yep!
And I think I for my part have derailed this thread long enough for the time being. Let Koshling figure out whether he wants any part of this!These icosahedral equal area grids (that's the technical term!) on globes are just right now getting more widely used in climate simulations, tectonic plate simulations and the like. It's exciting stuff. So far, virtually nothing at all in gaming. But I did a couple of Google searches, and it turns out people have definitely discussed the idea on wargaming forums, and there's quite a bit of buzz about it. For a dev team that wants to try something innovative, it's certainly an intriguing option.
But, like I said, I'm shutting up about it now.
primem0ver
Emperor
1. A layered grid (aka "Multiple Overlays")
In my above post, I mention "lighter" splotches being hot spots. This grid is actually composed of linked lower grids below the surface and a higher grid (currently not implemented) that represents the atmospheric layer. The nice thing about it is that these grids don't have to be the same data size as the grid beneath them. The hot splotches rise through the grids until they hit the surface. The smaller size grid below the hot spots means that the splotches will only appear on points that coincide with the grid below the surface. This is one way of achieving Koshling's multiple overlays.
2. Resolving navigational issues
All points on the grid are linked to latitude and longitude by a sort of hashtable system that uses longitude and latitude as the source of the hash. This can be adapted to any set of coordinates one wishes to use. This way one can still index the globe using a type of "rectangular" x and y coordinate system.
3. Pathfinding
Each grid point is linked to its neighbors so pathfinding should not be a problem. Start with a starting latitude and longitude and ending latitude and longitude a path can be generated through the grid. With enough memory available, it would even be possible to store the path cost in terms of distance for quicker results (skipping calculation).
As questions arise and I think of other things, I will post more points of interest.
In my above post, I mention "lighter" splotches being hot spots. This grid is actually composed of linked lower grids below the surface and a higher grid (currently not implemented) that represents the atmospheric layer. The nice thing about it is that these grids don't have to be the same data size as the grid beneath them. The hot splotches rise through the grids until they hit the surface. The smaller size grid below the hot spots means that the splotches will only appear on points that coincide with the grid below the surface. This is one way of achieving Koshling's multiple overlays.
2. Resolving navigational issues
All points on the grid are linked to latitude and longitude by a sort of hashtable system that uses longitude and latitude as the source of the hash. This can be adapted to any set of coordinates one wishes to use. This way one can still index the globe using a type of "rectangular" x and y coordinate system.
3. Pathfinding
Each grid point is linked to its neighbors so pathfinding should not be a problem. Start with a starting latitude and longitude and ending latitude and longitude a path can be generated through the grid. With enough memory available, it would even be possible to store the path cost in terms of distance for quicker results (skipping calculation).
As questions arise and I think of other things, I will post more points of interest.
Hydromancerx
C2C Modder
Have you played SimEarth. That would be so cool to have a map generator that worked like that in how the map "evolved" and thus was created.
Hello C2C team. I have been following this mod for quiet a time now. I installed an early version back in the day I think it was v13 and quiet liked it even though even back then I thought the prehistoric ara was way too long but hey that's by personal opinion. Anyway I didn't update it for quiet a while since I wasn't interest in Civ IV as CivV came out and there was a promising mod for it unfortunately the main dev guy got fed up with Firaxis slow Dll release policy that he quiet. So I looked back at C2C and reading about MultiMap it got me extremely excited. As it would finally make it possible Civ to be what I always wanted it to be something closer and even beyond CtP. Sea/Underground colonize and a proper expansion into space.
In the end I actually installed v26 just to see how far it has progressed. And I was really impressed.
Okay long story short. I don't want to be a scaremonger but seeing this post from Kosling made me really scared for the future of C2C. Simply because I've seen this happening so many times over. Making a mod and making a complete new game / game engine are two very very different things. And people coming from the first tend to totally underestimate the amount of work for the later.
So here is my worst predication how things will pan out:
People get excited about Koshlings idea and there is a real drive at the beginning but over the months it is going to fizzle out really quickly simple because the amount of work and the lack of visible progress. Visible progress is usually very important for people as they would like to see the things and the ideas in action not just on paper or in abstract code. But building something from ground will take a very long time if not years before you will be able to see the first progress. Unlike in a mod you put something in and you can basically see it very quickly.
Even after the first release in general lots of people will be disappointed by it as it just doesn't look very good as all the assets and graphics will be missing. Never underestimate this. So even more people will loose interest in the idea so that in the end it will most likely die a slow death.
At the same time as now most attention and resources are carried away to Koshling's new project progress in C2C will slow down as well so much that people who even quiet Koshling's project will not return to C2C naturally.
Or to take a famous quote: If you are trying to chase two rabbits you will loose both!
In the end I actually installed v26 just to see how far it has progressed. And I was really impressed.
Okay long story short. I don't want to be a scaremonger but seeing this post from Kosling made me really scared for the future of C2C. Simply because I've seen this happening so many times over. Making a mod and making a complete new game / game engine are two very very different things. And people coming from the first tend to totally underestimate the amount of work for the later.
So here is my worst predication how things will pan out:
People get excited about Koshlings idea and there is a real drive at the beginning but over the months it is going to fizzle out really quickly simple because the amount of work and the lack of visible progress. Visible progress is usually very important for people as they would like to see the things and the ideas in action not just on paper or in abstract code. But building something from ground will take a very long time if not years before you will be able to see the first progress. Unlike in a mod you put something in and you can basically see it very quickly.
Even after the first release in general lots of people will be disappointed by it as it just doesn't look very good as all the assets and graphics will be missing. Never underestimate this. So even more people will loose interest in the idea so that in the end it will most likely die a slow death.
At the same time as now most attention and resources are carried away to Koshling's new project progress in C2C will slow down as well so much that people who even quiet Koshling's project will not return to C2C naturally.
Or to take a famous quote: If you are trying to chase two rabbits you will loose both!
I'm so glad you map guys are here! I wasn't aware of the details of tiling spherical approximations like this, but I think it's cool. I am very interested in going for globes with a base grid of equal area hexagons (and 20 pentagons) as you propose. The following twists arise/are IMO useful (but are not necessarily fundamental to the initial implementation):
- Render (aka UI) layer allows pan-in and pan-out, always showing a from-above view of a region of the globe (up to maximum of hemisphere) with distortion applied to tiles by the render layer as a simple projection into the viewing plane (so no noticeable distortion at local scales, but ultimately at the full hemisphere view the tiles on the circumference of the visible hemisphere are highly distorted (as in narrow) because you're viewing them at an extreme angle.
- Render layer allows user to spin the globe in either axis (with a button to reset the vertical axis to the polar diameter)
- Overlay tiles addable as extra layers as per layering suggestion from the blog post (to handle river movement, tunnels, etc.)
- Non-global (always planar at least for a while) maps are also allowed, and for consistency are also hex-based, since that is need for the regular tiling of the global maps. The use I have in mind here is true toruses or (more probably) cylinders to represent Ringworld/Rama-like constructs, or simple planes to represent segments in segmented orbital constructs (think Ian M Banks style Orbitals)
Great, let's look into it! Just one very small correction: the twenty-sided dice has to be filled up with 12 pentagons, not 20. I think primem0ver also got it wrong in his post.
Fairly trivial error, but I just wanted to squash it before we get confused over this.
I think you don't really realize that we can use a lot of pre-existing code for the complex stuff (render specifically) and save ourselves a whole lot of time. Given what I understand Koshling's and AIAndy's abilities to be, along with what I know mine to be, I suspect that we could see something come of this much sooner than you suspect.
primem0ver
Emperor
Actually I changed my numbers too hastily
. I realized you were right in that it was a 20 sided die rather than a 12 sided die but I remembered the number 12 from the number of pentagons that the 20 triangles create. So I also changed the number of pentagons without thinking about it.
primem0ver
Emperor
@DrBalthar
I think you have a good point. But I also think that ls612 has a point as well. Here is my breakdown/opinion on the matter.
So the question is what would we really need to do? Koshling has already addressed this realization in this post. Essentially this simply boils down to creating a new UI, graphics engine and graphics. The data engine could change more slowly over time since it is not necessary to change the data format for the initial game even though that is a goal.
Here is what we could keep (for now):
All or most things in the dll related to rules, ai, xml, data structures (except those related to the map)
Here is what we would need to change before we could play: with my personal opinion on feasibility
I think that the feasibility of creating all new map graphics is going to be the deciding factor/Dr Balthar's breaking point (as two people, including Koshling have pointed out). This will be grueling work unless we can find a graphic artist or two willing to do it. There are LOTS of graphics that would need to be completely redone from the ground up even if this list appears short:
Also, if we were going to go to the depths of redoing these graphics, IMO it would also be beneficial to separate "terrain" into the following new concepts:
Features could also use a major revamp since different features should/could belong to different layers and features may not be visible before certain techs are discovered. A weather system "feature" could be introduced as a layer above the ground that would be visible if one backed out far enough.
All in all I think we really need to consider what needs to be done and whether or not we have the resources before we dive into such a major undertaking as opposed to simply refining what is feasible with C2C for Civ4
I think you have a good point. But I also think that ls612 has a point as well. Here is my breakdown/opinion on the matter.
So the question is what would we really need to do? Koshling has already addressed this realization in this post. Essentially this simply boils down to creating a new UI, graphics engine and graphics. The data engine could change more slowly over time since it is not necessary to change the data format for the initial game even though that is a goal.
Here is what we could keep (for now):
All or most things in the dll related to rules, ai, xml, data structures (except those related to the map)
Here is what we would need to change before we could play: with my personal opinion on feasibility
- The way all plotting is done in terms of the actual graphics engine. (a challenge)
- The parts of the dll and exe that relate to map and plot positions. (a challenge but feasible given that we already have part of an engine in my ISEA implementation)
- The AI relating to movement and attack moves. (fairly easy)
- All graphics relating to plots (The BIGGEST challenge)
- A hack to allow us to use existing models for graphics that are not related to plots This refers to things like units and bonuses. (medium to hard challenge depending on how good we are at discovering how the graphics are drawn or the presence of a graphic artist who may know already).
- A UI engine that makes use of most python already in place, or an original one that must be scripted from the ground up (a fairly big challenge or HUGE challenge respectively)
I think that the feasibility of creating all new map graphics is going to be the deciding factor/Dr Balthar's breaking point (as two people, including Koshling have pointed out). This will be grueling work unless we can find a graphic artist or two willing to do it. There are LOTS of graphics that would need to be completely redone from the ground up even if this list appears short:
- terrains
- features
- rivers (could be implemented on a separate layer as suggested by Koshling)
- routes
- probably a few more I am not thinking of at the moment
Also, if we were going to go to the depths of redoing these graphics, IMO it would also be beneficial to separate "terrain" into the following new concepts:
- Plot type (aka geography using height maps, allowing us to create things like continental shelves, plateaus, mid ocean ridges etc... the current 4 just aren't adequate for more realistic maps. Particularly if we want the ocean floor to eventually become a playable surface.)
- Soil type (aka the coloration and yield aspects of the current terrain system). These would simply be texture overlays.
Features could also use a major revamp since different features should/could belong to different layers and features may not be visible before certain techs are discovered. A weather system "feature" could be introduced as a layer above the ground that would be visible if one backed out far enough.
All in all I think we really need to consider what needs to be done and whether or not we have the resources before we dive into such a major undertaking as opposed to simply refining what is feasible with C2C for Civ4
@primem0ver:
I don't think we need to make our own graphics engine, there are plenty of open source alternatives out there. We would need to create new assets though, which could pose an issue. However, given how much CC-licensed art there is out there that may help us somewhat.
We also couldn't reuse the DLL, as that is still mostly firaxis code. Our XML content though could be used as we (or ROM/AND/DCM/whatever) made that. Also, Koshling wants to code this all in C# and have the rulesets be modular, so that would mean that we'd need new code for that. Overall, here are the things I think we'd have to do to get a workable product out of this, in their approximate order.
If we have these five things done that would be an accomplishment, and also release-worthy. I don't think we'd really need anything else to have a playable (albeit shallow and incomplete) result. After that we could expand from there.
I don't think we need to make our own graphics engine, there are plenty of open source alternatives out there. We would need to create new assets though, which could pose an issue. However, given how much CC-licensed art there is out there that may help us somewhat.
We also couldn't reuse the DLL, as that is still mostly firaxis code. Our XML content though could be used as we (or ROM/AND/DCM/whatever) made that. Also, Koshling wants to code this all in C# and have the rulesets be modular, so that would mean that we'd need new code for that. Overall, here are the things I think we'd have to do to get a workable product out of this, in their approximate order.
- Write a base logic and data engine for the game, essentially what Koshling described in Blog Post 2.
- Integrate that with an existing open source graphics and render engine, writing one of those ourselves would be IMO a waste of time and potentially a project-killer
- Write a basic ruleset, defining as little as we can get away with to have a playable game (probably only including Prehistoric Era at first, and moving up from there)
- Make some content for the Prehistoric Era.
- Write AI for this
- Make a basic UI
If we have these five things done that would be an accomplishment, and also release-worthy. I don't think we'd really need anything else to have a playable (albeit shallow and incomplete) result. After that we could expand from there.
primem0ver
Emperor
Eeewwwww...!
I love C# as a language and know it fairly well because it is much more object oriented and easy to learn while still being based on the very readable C++ format. My project was built on C# in the original implementation.
However, I am very opposed to doing the graphics handling and number crunching in c# because c# does not use native data types (strictly speaking). From what I can tell, all data types in c# are actually objects even if the data itself is formatted in the same way as a native type. So adding a new local variable is not as simple as increasing the stack pointer anymore. Creating an instance of a simple data type requires the same object overhead in terms of processing time because a constructor (and later a destructor) must be called. In my experience this has a major disadvantage when it comes to the time it takes to do number crunching and graphics handling (which is why I am undertaking conversion to C++).
The whole point of the frames per second data (in my screenshots) that appears in the upper left corner of the 3d drawing was to figure out what number crunching and processing would do to the fps count. I did not like the results...
Ultimately I think a mixed language project may be the best approach.
We'd probably be using a rendering engine in C++ with a C# wrapper for performance reasons. However, no one has really commented on my suggestion to use OGRE with it's wrapper MOGRE for graphics, so I don't know if anyone else wants that or even cares.
primem0ver
Emperor
Probably because we aren't familiar with it. My biggest question in using an already existing graphics engine is whether or not it can be adapted to use the plot systems we might be adapting... I suppose the answer would be yes if it is completely open source.
Hydromancerx
C2C Modder
So how much of the code and graphics will be usable in this new engine? So much work has been put into Civ4 C2C that I worry that if we do convert things over that it will taken even longer to put everything back in, let alone progress with new stuff. I also feel that things will then be cut out because of either lack of motivation to put it back in or the excuse of "do we really need this?" syndrome of AND where they had an awesome mod and then Afforess started taking stuff out of it.
I know this is asking a lot but I thought I would ask. Is there a way to recreate the existing engine so the game runs like Civ4 but still can expand beyond the limitations of the Civ4 game engine? Since in this case we would have the source code. Or the fact that we don't have the civ4 source code we can never truly recreate the engine to support all the stuff we have now?
In other words how much of the content we already have done could be converted over as is? How much could be redone? And how much could not be converted? And why?
I know this is asking a lot but I thought I would ask. Is there a way to recreate the existing engine so the game runs like Civ4 but still can expand beyond the limitations of the Civ4 game engine? Since in this case we would have the source code. Or the fact that we don't have the civ4 source code we can never truly recreate the engine to support all the stuff we have now?
In other words how much of the content we already have done could be converted over as is? How much could be redone? And how much could not be converted? And why?
Yes, it is completely open source. It uses the MIT license, which is very easy to comply with.
As far as I can tell the MOGRE wrapper is licensed under the LGPL, which is a tad more complicated, but the gist is if we keep our project open source we won't encounter any issues with either license. I am nowhere good enough at this to be able to explain in detail the features of OGRE from a technical perspective (but the links below can do this), but given that it is used in other game engines and it is actively developed today using it would probably save us loads of work and give a very nice result.
@anyone technical:
Here are some links to documentation and explanations for OGRE and the MOGRE wrapper.
OGRE website
Manual from a technical perspective
Non-technical FAQ
MOGRE website
Blog post 5 will be directly addressing the feasibility and effort question, since it is a big (and entirely valid) concern (so next but one). I'll lay out my thoughts on the matter then.
In regard to performance overhead of C# - it's way less than you think. Object allocation is almost as cheap as local (stack frame) allocation in C++, and much cheaper than heap based allocation in C++. Because it's a virtual machine, there is some translation overhead for code generally, but:
In regard to performance overhead of C# - it's way less than you think. Object allocation is almost as cheap as local (stack frame) allocation in C++, and much cheaper than heap based allocation in C++. Because it's a virtual machine, there is some translation overhead for code generally, but:
- Modern JIT techniques actually make this quite small (which would also apply to Java)
- Because only the runtime need adapt to the actual hardware, things like optimization against the processor tend to be much better than with a traditional compiler (where you're probably generating code targeted at a Pentium as lowest common denominator), with the JIT being adaptive and emitting code that is tuned to the actual CPU present
- the most performance intensive code is almost certainly inside the native code of DirectX for the rendering anyway
primem0ver
Emperor
I took a quick look at the features. Looks promising. I started converting my source from its original format to a mesh format but I would have to do some more research to complete this and to figure out how to make it compatible with the OGRE system.
Similar threads
