We can't because we aren't legally allowed to, as the code and assets were made originally by Firaxis. That and a lot of it is outdated, so we'd want to replace it anyways.
Possible Future Direction (personal view)
- Thread starter Koshling
- Start date
We can't because we aren't legally allowed to, as the code and assets were made originally by Firaxis. That and a lot of it is outdated, so we'd want to replace it anyways.
Ok i understand this but some time ago Openttd project (if you know it or dont know - not really a matter) used original and so copyrighted files with stating in README " you needoriginal game files to play this game" but after (i dont certain in that matter) 3 years openttd got its own graphic files.
so in short : there is no need to inventing the bicycle for begining.
i seen somewhere some grandstrategy open engine...cant remember where or its name... hm
so in short : there is no need to inventing the bicycle for begining.
i seen somewhere some grandstrategy open engine...cant remember where or its name... hm
Great! Here are my first thoughts.
1. In the data model you talk about relationships and their separation from entities from a data perspective. Would we be then coding relationships into the engine then or would those be extensions? I'd prefer the former, adding relation definitions to the core engine and having higher-level stuff say something like relation(entity A, entity B), where we define what relations are in the engine.
2. Would we have two separate schema, one of Entities and their properties and one for relations and adding them?
3. What extension types would we support (VB.NET, C#, other?)
4. Would it make sense to run the AIs on their own hardware thread, as they would be their own separate process anyways?
5. You say that perhaps it would be a good idea to make a base DLL that defines core rulesets and classes (cities, units, etc). Why not just build that into the engine then?
6. Have you thought at all about the graphical render engine we would use for this project? Have you looked at OGRE at all?
Either - relationships would be defined in the same schema XML as entities. I just wanted to keep the separation in eh software that implements them at runtime since it's a useful separation there (it isn't in the XML)
No. Each XML file can contain both.
Any .NET. It doesn't matter since they all compile to the same virtual machine and virtual runtime structure.
Everything will be inherently multi-threaded. Whether it's in-process or not won't influence that
Because it's a meta-engine, and those concepts are all game-specific. Separate assembly doesn't mean separate process though, nor does it mean not-bundled-in-an-installer necessarily, so it doesn't really have any end user impact or any significant developer impact.
I looked at the links you posted, and it seems plausible to me. However, I know next to nothing about graphics programming. I **DO** think the UI I a big job though, even with a render engine like MOGRE. I am more focusing on making the choice of render engine as independent as possible from h rest of the game engine, since that way I know that if we can find someone with the skills to do the 3D engine it won't cause rework of the rest (which could be developed entirely with a Civ 1 type 2D engine if necessary)
I also know very little about graphics programming. I think that you are right, that we'd need to make something usable with crap graphics, and then present it and say that we need someone to volunteer as a graphics programmer (unless AIAndy or primem0ver know more about that stuff?)
primem0ver
Emperor
You have a point there. In addition, the separation of graphical point based rendering and tiles would also allow for combining feature height maps with an overall variable elevation (which can change from point to point). This could still be done with points only though.
And there's still a problem with rivers using a tile system. Although technically, rivers could flow through the middle of the tile, there is the difficulty of keeping the rivers always going through the center of tiles. I know this can be done graphically and through programming but it seems a bit messy to have rivers both on edges and centers. I guess the solution is to have rivers always go through centers... but that seems too limiting.
I have done. It's basically a Civ II style UI (essentially 2D). It could probably be pressed into service as a temporary measure, but I'm not sure how decoupled it's graphics are from its engine.
primem0ver
Emperor
Thanks for the new post. Good stuff. One problem I see though: We have already discussed the problems posed by the lack of a variable height in placing units in Civ4 (link will be posted below when I find it). Any type of terrain that emphasizes altitude (such as mountains, plateaus, ocean floor features, etc...) will need some way to maintain height information for unit (and other entity) positioning. This could be done with tile definitions using a height map but I think it would be easier to simply be part of the map definition itself.
I did some thinking before you put this post up on how to adapt my grid engine for the kind of system you are proposing. I think the easiest way to do this would be to have three base kinds of layers: a data layer (no height), a (drawing) surface layer (a generic, layer wide height), and a drawing layer (with height).
The addition of height would also be very important in a space based 4x game. Since this is a generic engine to be used by any 4x game, it should be designed with all types of 4x games in mind. There are already several 4x space games that have three dimensional maps. The original 3D space game (which would still be my favorite if it wasn't for the tedious colony management system since the AI for colony management was TERRIBLE) was called Ascendency. AMAZING 3D interface that was very realistic in terms of unit movement.
Such a space game would require a 3d data layer as well.
EDIT: I would highly recommend you take a look at the Ascendancy game page (here is the one in wiki) because in reality Ascendancy had two completely different kinds of maps (even if technically one was just a grid). One was for the game itself and units in the game, the other was for building placement within a colony. It will help give a perspective on the variety that can exist in a 4x game.
I did some thinking before you put this post up on how to adapt my grid engine for the kind of system you are proposing. I think the easiest way to do this would be to have three base kinds of layers: a data layer (no height), a (drawing) surface layer (a generic, layer wide height), and a drawing layer (with height).
The addition of height would also be very important in a space based 4x game. Since this is a generic engine to be used by any 4x game, it should be designed with all types of 4x games in mind. There are already several 4x space games that have three dimensional maps. The original 3D space game (which would still be my favorite if it wasn't for the tedious colony management system since the AI for colony management was TERRIBLE) was called Ascendency. AMAZING 3D interface that was very realistic in terms of unit movement.
Such a space game would require a 3d data layer as well.
EDIT: I would highly recommend you take a look at the Ascendancy game page (here is the one in wiki) because in reality Ascendancy had two completely different kinds of maps (even if technically one was just a grid). One was for the game itself and units in the game, the other was for building placement within a colony. It will help give a perspective on the variety that can exist in a 4x game.
Dancing Hoskuld
Deity
I really liked Ascendancy pity it is only an Apple App now
. One thing I liked was the way you ended up building (space)ships just like naval ships are built now. You build the hull with rudimentary engines and control at one place then move the ship to another to fit it out. Given the time it took to get near your front lines it was often best to only have basic weapons and do a complete refit at the front. 
Not suitable for civ because you have a lot more units in civ.Is it really necessary to bake locations into entities like units or cities. At least with the normal plot based approach the relationship between units and plots or cities and plots defines the location without having to add coordinates to units themselves. The relationships regarding to connectivity, adjacency and distance are then defined on the plots and if you need one for units or cities you can use one or more joins.
One thing I would like to see on the lower layers is the following:
It is quite common that you bind entities to the existence of a relationship. Like when player X researches tech Y, then the entity building Z is added to all cities of player X.
That could be done with an event that adds the buildings when the tech is researched, but what happens if the player builds a new city or loses one. That needs extra events for all those cases and extra handling.
I think that is error prone. So I would like to see that kind of common binding solved generically on the lower layers.
This means the ability to bind an entity to a relationship (or a relationship expression in SQL or whatever). If that is then handled by adding the necessary events automatically or in a different way should not matter from the layers above.
One thing I would like to see on the lower layers is the following:
It is quite common that you bind entities to the existence of a relationship. Like when player X researches tech Y, then the entity building Z is added to all cities of player X.
That could be done with an event that adds the buildings when the tech is researched, but what happens if the player builds a new city or loses one. That needs extra events for all those cases and extra handling.
I think that is error prone. So I would like to see that kind of common binding solved generically on the lower layers.
This means the ability to bind an entity to a relationship (or a relationship expression in SQL or whatever). If that is then handled by adding the necessary events automatically or in a different way should not matter from the layers above.
Personally, I think it would be better if Koshling could reinforce an existing project rather than starting our own, in order to increase the likelihood of producing a complete game at all. I suggest that Koshling, rather than trying to make an entire game himself, could along with some other C2C developers work on the Thrive Project. Although the developers of Thrive are former Spore and not Civilization players, the fact that there will be a civilized-life portion of both proposals here as well as the common need for a lightweight game and graphics engine, means that Koshling could work with Thrive and be able to tap a greater workforce of developers than he could if he struck out alone. Thrive is still in its early stages of development, so while I am not part of the project, I am sure that Koshling's engine proposal would help them - and us - greatly.
In addition, working with Thrive would add the feeling of "completeness" by creating pre-civilized stages. It would always be interesting to explain where the civilized man in Civilization came from.
In addition, working with Thrive would add the feeling of "completeness" by creating pre-civilized stages. It would always be interesting to explain where the civilized man in Civilization came from.
Looking at the layers that there are now I think the event management and probably some other basic functionality like pathfinding should be in a separate layer between the basic data model and the rule based game model.
While it is ok that the basic data layer stays somewhat simple, we need to avoid reinventing the wheel as often as it happens now in the C2C DLL. So it would probably good to think some more about the types of rules that will be present in the game model layer and what part of that can be generalized and dealt with below the rule layer.
This also includes thinking about modularity, how different rules interact and how the XML/rule based definitions interact with the serialized savegames.
While it is ok that the basic data layer stays somewhat simple, we need to avoid reinventing the wheel as often as it happens now in the C2C DLL. So it would probably good to think some more about the types of rules that will be present in the game model layer and what part of that can be generalized and dealt with below the rule layer.
This also includes thinking about modularity, how different rules interact and how the XML/rule based definitions interact with the serialized savegames.
I have thought about this myself. The issue of rivers and where / how to place them...
Just as an idea: would it be possible to treat rivers as features? In the same way as forests? That should enable us to have rivers go through the centers of tiles without needing separate "river" terrains. It would enable us to have different kinds of rivers as features, such as "navigable river" or "non-navigable river". And it would enable us, if there is the capacity to add multiple features per tile, to have things like "plains + river + forest".
Yes, if we are making our own engine that is certainly possible. The Navigable part would just be a rule in the Pathing engine, and the river travel could be defined in an XML ruleset.
primem0ver
Emperor
This is one way to approach it but I don't think it is the best. Whether we use points or tiles (where a point is still at the center), features are centered on points. Rivers would not be. Rivers would be anchored to points and flow along edges that connect points regardless of whether we used points or tiles as the basis for movement and/or placement. Your thought gives me an idea though
One side comment: rivers are not ever considered terrains in Civ 4. Terrains occupy tiles. Rivers occupy the borders of tiles so they are not handled the same way.
In geography/geology, the concept of stream order (Strahler number) is used to relate stream flow and width to relate that to how many tributaries it has. The smallest body of water (stream) is given a stream order of 1. When two streams of the same number come together, the number is incremented by one. Streams of a lesser order do not increase the order of a larger stream when joined.
So what? Well, we could use a generic version of this system to create the rules for river and tile placement: their placement through or between tiles. Obviously the higher the stream order, the wider it is. Tiny tributaries would not be shown on a map so the smallest rivers would probably of a fairly high stream order. Rivers must be near the highest stream orders in order to support ships. It would be possible to give water based units a "stream order minimum" to designate how small of a river they could handle but for the most part, this number would still need to be fairly high. Even a canoe requires a stream order of 3 or 4 for a smooth journey. It would make sense that only these high order rivers should be bound to go through the centers of tiles since they are the ones that can be navigated by boats and ships.
This paper gives one a good idea of what the Strahler number for United States rivers is.
To give an idea:
Probably the minimum for ANY kind of ship should be 6 or 7.
Cruise and large ships require a 10
Ironclads should probably require a 8 or 9.
Yacht types should require a minimum of 7 and primitive craft a 6.
Honestly though, a map probably wouldn't show a river of anything less than 6 or 7 so we can revamp our original numbers:
large ships: 10
ironclads: 9
small boats: 8
So ideally a stream order of 8 (if you want canoes to travel further) or 9 would be the minimum for requiring the river to go through the center of a tile.
primem0ver
Emperor
Koshling,
I really think you should do a little more research on the C# vs C++ issue. The bottom line is that a mixed language system is probably best. Here is the best article I have found so far on the subject:
http://www.codeproject.com/Articles/212856/Head-to-head-benchmark-Csharp-vs-NET
The bottom line is that C++ really does seem like the best language for pure number crunching (as evidenced by that vast difference between the results for matrix multiplication). On the other hand C# seems to be significantly superior in certain types of data structures that would probably be used. I really think that C++ should be the basis for any part of the engine that uses vector calculations and c# used for things like data tables etc.
I am still researching this issue as I need to make a decision about my own ISEA grid base for later but I am strongly leaning toward going in the above direction.
I really think you should do a little more research on the C# vs C++ issue. The bottom line is that a mixed language system is probably best. Here is the best article I have found so far on the subject:
http://www.codeproject.com/Articles/212856/Head-to-head-benchmark-Csharp-vs-NET
The bottom line is that C++ really does seem like the best language for pure number crunching (as evidenced by that vast difference between the results for matrix multiplication). On the other hand C# seems to be significantly superior in certain types of data structures that would probably be used. I really think that C++ should be the basis for any part of the engine that uses vector calculations and c# used for things like data tables etc.
I am still researching this issue as I need to make a decision about my own ISEA grid base for later but I am strongly leaning toward going in the above direction.
I doubt we will end up on an optimization level where that kind of differences really matter. And in many cases you get more safety in return for the slowdown like array boundary checks.
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)
