Because we don't have the code for it to try to modify it. We only have the code for the DLL that implements the rules and AI, not for the overall game or graphics.
Edit - blog post 2 up BTW.
Possible Future Direction (personal view)
- Thread starter Koshling
- Start date
Because we don't have the code for it to try to modify it. We only have the code for the DLL that implements the rules and AI, not for the overall game or graphics.
Edit - blog post 2 up BTW.
Koshling has said that he wants to work on AI, it's really been me and Hydro that are prodding towards Multi-Maps. At any rate, I would definitely move to this project if it goes anywhere. It is really the natural continuation of C2C, to make it it's own separate game. In fact, I don't see why we couldn't still call this new project C2C if we get going on it.
@Koshling: Regarding the second blog post, here are my thoughts.
1. We could use SQLlite, it is a full serverless implementation of SQL and it's source code is Public Domain, so no worries there. That is what Tortoise uses for it's database functions IIRC.
2. So what you are essentially proposing for data is a layered hierarchy, IE we say that all Melee units do certain things, then move down and say Axemen do certain additional things, and so on and so forth, right? Because that seems like a very good idea to me.
Very interesting and thoughtful post.
I would suggest to extend the underlying data layer by the following:
All properties are functional, not simple values. Most might be simple constant functions, but they don't need to be.
Entities can inherit from other entities (like the instance of a building might inherit from the building type which might inherit from a class of buildings and so on).
Entities can have effects, which they apply on other entities defined by a relationship (when the relationship changes the effect application might need recalculation). Effects on an entity apply a modification to the function of a property (like adding an increase by 10% at the end of the calculation or adding 5 to the base value).
Effects are inherited (so you can apply an effect on the building class and it will apply to all buildings of that class).
That would allow to define some behavior backwards. Instead of considering everything when you define the tax income formula, you can define some basic formula and then let other entities add to it (like civics, buildings, ...).
DRJ
Hedonist
Wow! Heavy stuff. So interesting to learn about how the final, anticipated fun of playing a game is worked out from the very beginning, especially considering that building that set of highly complex ideas, reminds me of reverse scaping of a sculpture -- like michelangelo said the sculpture is already to be imagined inside the block as a whole; you, Koshling do the same thing but instead of scaping, every little piece of code you add to the structure makes the cold formula become more human in its whole - in the beginning was the word?
In 'future civ's case it's IsAdjacent ((A.x - B.x)2 + (A.y - B.y)2) <= 2.
I see your groundbreaking work with the respect I have for great Artists of all times;
in your case the "making" of stunning art can even be watched as it's done.
Ingredients are a blog (visible, yet unfinished process, representing life itself), raw ideas (in this case abstract formulas that, like geometrical patterns in nature evolve and reveal a fascinating, mystical sense of beauty, especially in "forgetting" about them during the dreamworld kinda dive into the finished gameplay -- the idea [of fun] as a promise [of redemption] ), a subtle sense of politics (independence from current commercial chains).
So what is art in the 21th century, other than interdisciplinary, new-horizons-defining scientific and intrueging idealism? Very much can be found in your case, Koshling! Philosophy, is what comes to my mind at first: the sheer width of anticipating freedom what should the game I create be like, what do I like , why do I like it, where do I want to go to like some more, what possibilities for the future of the projects should I consider to implement even before beginning etc pp. ,
the degree of abstraction to convert the ideas towards applied computer science, to me is like a work of Hercules, a fine, enduring craftmanship is needed, its like painting the sixtine chapel, only that we have it with a huge zooming scale on our screens once its finished. Yes, Koshangelo is also inventing new techniques to paint!
Next part of that state of 21th century art is a solid yet enthusiastic personality with livid social interaction, strong morale and under stable, autochthonous development.
Too bad, the public eye still defines art as something that has to be in a museum to count in the highest ranks, no, it shouldn't anymore, art is something that is alive, a pure essence of the brain evading wad of smoky mist that condenses in giving hope, making people think and discuss about things that move them, that pushes us, as humanity forward to the unknown - with the great promise of something good.
@Koshling:
I apoligize if this is going to be addressed in a future blog post, but you stated that we wouldn't have something playable for a very long while, and while I agree this would be a lot of work, from what you are saying the only things that would need to be made from scratch are the ruleset engine (the basics and sockets for the actual rulesets) and the UI renderer. And you are suggesting that we make this at the core as lean as possible, so I think we be able to make good progess at this if we work at it.
I apoligize if this is going to be addressed in a future blog post, but you stated that we wouldn't have something playable for a very long while, and while I agree this would be a lot of work, from what you are saying the only things that would need to be made from scratch are the ruleset engine (the basics and sockets for the actual rulesets) and the UI renderer. And you are suggesting that we make this at the core as lean as possible, so I think we be able to make good progess at this if we work at it.
rightfuture
Emperor
- Joined
- Mar 11, 2008
- Messages
- 1,649
i updated my prev post a little to clarify, if anyone's interested.
I like aspects of this, but I'm not sure about all. It is possible for properties to be neither constant (at the schema level), nor functional, just 'variable'. For example consider the current health of a unit - it's not a constant (it varies due to combat, terrain damage, healing, ...), but neither is it functionally calculable at any given point in time - it's just a variable, that is modified by ongoing calculations, but is necessarily a persisted value. At one level that's just a quibble, since clearly we can have a syntax that means 'just a variable' that fits in with a functional notation, just as easily as we can have one for constants. However, I want to keep the lowest levels data-centric, and try to have the functional aspects layered above them.
Having said that, I think you raise interesting points. How about this:
- Properties are just persisted values, BUT, functional modifiers may optional accrue to them, when applied programmatically or declaratively by other elements (see below). The set of functional modifiers that have been attached to a property instance are applied to the underlying value when it is retrieved in some schema-defined order (see below). So say a building has a commerce value of 10. Application of a civic may then apply a functional modifier value = value*110/100 (say), which would cause it to report a value of 11
- Entities may define (declaratively in the schema) functional modifiers to apply to named properties of related (via an arbitrary relationship definition) entities
- A specific property type of 'functional' may be defined (and implemented in a separate layer slightly above the base data layer, through which it acts as a projection). Such properties are not stored, and their values are calculated from other properties. This **MAY** be restricted to only other properties of the same entity, or we may allow more general definitions (TBD). The motivation for this will become apparent in a moment.
- Entity classes may be defined in the schema, and may inherit from one another.
The first two points are intended to address the same needs you pointed out with 'reverse definitions' - i.e. - a base formula may be modified by other components that it does not need to be aware of. One minor issue is that if multiple functional modifiers are applied to a value, then ordering matters unless the functions commute, which will not generally be the case. For example, obtaining access to a bonus might add 1 commerce, and a civic might modify it by 10%. However (x + 1)*1.1 != x*1.1 + 1. Hence the order of application of functional modifiers must be well defined and consistently applied. I suggest that modifier functions declared in the schema should also require a numeric priority to be defined , and in the event of a priority clash we declare a schema error - we might able to do better, but it's probably not worth it provided schema errors are clearly reported (unlike in Civ!)
The combination of class-based inheritance and the addition of optional functional properties is intended to provide what amounts to virtual properties. Consider a base class that defines a functional property BuildingCommerce, with formula '=0' (think of this as a kludgy pure virtual), and also defines CommerceOutput with some complex formula that references 'BaseCommerce' (e.g. - the base class for all buildings perhaps defines commerce output in terms of some city-level modifiers operating on the BaseCommerce). Derived classes (e.g. - orbital buildings) can then provide differing implementations of 'BaseCommerce' that are specific to that sub-class (so orbital buildings double their commerce if orbital infrastructure is present for example), all probably operating on some underlying raw commerce output of the individual building instance, which is just a regular property defined by a constant in the schema.
Restricting the functional properties to the same entity means we don't have to worry about (inobvious) loops and having to calculate closures or dependency trees. If there are solid reasons for needing them to be more general though, they could be in principal.
Since I got a PM about this, I'd also like to leave a comment.
The biggest problem which I see are the assets.
If you wanted to recreate (or whatever) a Civ4 like game, you need assets. Units, leaders, etc.
2 options:
- You choose to use Civ4 assets. Which means you need either the Gamebryo engine, which costs money, or you need another engine which is compatible, and I doubt that such a thing exists
- You choose to create your own assets, or to use other assets. While I'm sure that you could deal with the programming of the engine, I'm not sure if/how you'd deal with that. Because to be honest: That's too much work, and I doubt you'd be skillful enough to do the art and the coding.
I'd be totally happy for this project if this could be answered in a sufficient way
.
The biggest problem which I see are the assets.
If you wanted to recreate (or whatever) a Civ4 like game, you need assets. Units, leaders, etc.
2 options:
- You choose to use Civ4 assets. Which means you need either the Gamebryo engine, which costs money, or you need another engine which is compatible, and I doubt that such a thing exists
- You choose to create your own assets, or to use other assets. While I'm sure that you could deal with the programming of the engine, I'm not sure if/how you'd deal with that. Because to be honest: That's too much work, and I doubt you'd be skillful enough to do the art and the coding.
I'd be totally happy for this project if this could be answered in a sufficient way
.Since I got a PM about this, I'd also like to leave a comment.
The biggest problem which I see are the assets.
If you wanted to recreate (or whatever) a Civ4 like game, you need assets. Units, leaders, etc.
2 options:
- You choose to use Civ4 assets. Which means you need either the Gamebryo engine, which costs money, or you need another engine which is compatible, and I doubt that such a thing exists
- You choose to create your own assets, or to use other assets. While I'm sure that you could deal with the programming of the engine, I'm not sure if/how you'd deal with that. Because to be honest: That's too much work, and I doubt you'd be skillful enough to do the art and the coding.
I'd be totally happy for this project if this could be answered in a sufficient way
Yeah, the latter will probably have to happen. THe working assumption (and granted, this specific plan is two days old so things may change) is that eventually there will be enough interest in this that someone with art skills would come and help. Failing that there are literally terabytes of CC art out there that we could use for this. But yes, that would be a major stumbling block.
Since I got a PM about this, I'd also like to leave a comment.
The biggest problem which I see are the assets.
If you wanted to recreate (or whatever) a Civ4 like game, you need assets. Units, leaders, etc.
2 options:
- You choose to use Civ4 assets. Which means you need either the Gamebryo engine, which costs money, or you need another engine which is compatible, and I doubt that such a thing exists
- You choose to create your own assets, or to use other assets. While I'm sure that you could deal with the programming of the engine, I'm not sure if/how you'd deal with that. Because to be honest: That's too much work, and I doubt you'd be skillful enough to do the art and the coding.
I'd be totally happy for this project if this could be answered in a sufficient way
Absolutely. I'll be making a blog lost on the downsides and sticking points in a few more posts time (I have the first four or five planned out). We absolutely will not be able to reuse graphical asserts (apart from movies and sound clips).
Thunderbrd
C2C War Dog
Just read your blog post from today... fascinating. I was able to follow about 80% of it and what I could follow was brilliant so I presume the rest is Genius and thus beyond my current understanding. I'm sure it will make more sense as I see examples taking place - that's where I begin to get an understanding of things as I must visualize to grasp.
But for the most part, much of this made absolute and perfect sense.
One thing I wonder... would it be possible for one property to have multiple parent IDs? I think here of some of the property connections I've been making in the code already between promos and buildings and such... would it be possible for say, Promos to have both buildings and units as parents but with only some effects functioning for buildings, some functioning for units, and some for both?
But for the most part, much of this made absolute and perfect sense.
One thing I wonder... would it be possible for one property to have multiple parent IDs? I think here of some of the property connections I've been making in the code already between promos and buildings and such... would it be possible for say, Promos to have both buildings and units as parents but with only some effects functioning for buildings, some functioning for units, and some for both?
Would need a more concrete example ro know if I'd actually recommend it, but yes, with an inheritance system you could have a base class that was instantiated as an entity in both contexts.
I agree, my main point was that from the usual access layer to properties it would be transparent if a property is a variable, a function or a variable with functional modifiers (so you can easily replace them with each other later).
An important point as that influences the stacking behavior of modifiers. Maybe in addition to a simple priority some predefined stacking declarations could be made that add the modifier at specific points in the function.
Another point: I wonder if there should really be entity references as properties. They could as well be represented as relationships (and profit from the .
And maybe instead of relationships with properties ternary relations (or more) could be used.
@Koshling:
I've been thinking about the data model some more and I think perhaps some concepts that may be reducable should be defined in the core engine nonetheless. For instance, I think that there should be the following "hardcoded" (in quotations because someone could change it if they were so inclined, but it would be in the engine) entities.
because honestly I don't see how those couldn't be required given that we would be making a TBS 4x game/engine.
Also, how would you be planning for rulesets to be implemented? My vote would be for doing it as a DLL, and making it so that you can only have one at a time. The reasoning here is that if we allow multiple rulesets to be loaded at the same time that has the potential for so much error and confusion, so I would vote for keeping it at one base ruleset (with potentially allowing extensions to that) at a time. Unless of course you have another plan that would address this.
I've been thinking about the data model some more and I think perhaps some concepts that may be reducable should be defined in the core engine nonetheless. For instance, I think that there should be the following "hardcoded" (in quotations because someone could change it if they were so inclined, but it would be in the engine) entities.
- Map (Superentity, ie one level below game)
- Player (also a superentity)
- City (subentity of Player)
- Plot (subentity of Map)
- Unit (subentity of Player)
because honestly I don't see how those couldn't be required given that we would be making a TBS 4x game/engine.
Also, how would you be planning for rulesets to be implemented? My vote would be for doing it as a DLL, and making it so that you can only have one at a time. The reasoning here is that if we allow multiple rulesets to be loaded at the same time that has the potential for so much error and confusion, so I would vote for keeping it at one base ruleset (with potentially allowing extensions to that) at a time. Unless of course you have another plan that would address this.
Little is gained and a lot of flexibility is lost if there are such hardcoded things.
Most of the rules should be in a data format (text, XML, something like that), not in DLL code.
Rules might be quite modular with probably some options implemented as rule modules.
But then wouldn't we get stuck with people reinventing the wheel so to speak for each ruleset that is made? I assume that we would support some ruleset (like with C2C) and also make it open for others to make their own stuff (mods). Would they have to define then again what maps and players are?
Interesting. I understand the flexibility that brings, but I can see many pitfalls there as well. I suppose there will be more to come in that field.
That is one reason why modularity is useful.
And yet modularity can cause a plethora of conflicts that may be hard to find and diagnose. I agree, there is a good argument for as much flexibility as possible, but having some framework defined will make things easier I suspect.
Also, I'm looking forward to blog post three, hopefully that will come soon.
I'm snowed under with work currently, which is why post 3 has not happened the past 2 days, and also why I have had zero modding time to look at any bug reports here.
That's understandable, I have a lot of schoolwork now before the thanksgiving break so I have next to no modding time.
Similar threads
