Announcement

**Lord God Jinnai** · October 18, 2000, 17:59

quote:

Resource

name

total quantity

available quantity determination (An equation or set of rules based on technology and infrastructure levels that determines what your civ is capable of extracting. FE you might only be able to get 30% of the availiable ore until you get a certain level of technology. This number would be defined once per resource type, and the individual resource objects would have a pointer to that definition.)

Well the player should only see available quanity then.

quote:

quality/purity (Multiplies the effect of the resource)

concentration/ease of extraction (Determines the effort needed to get a unit of the resource)

effect of the resource (What it does and what it is used for. I am guessing that this should be defined globally for all resources of that type. FE we define what oil does and then put a pointer to that definition in the resource object.)

Another thing might need to be added...

renewability Speed at which the resource is replaced in game terms. This can be not at all also.

Do you want a list of the resources we need right now?
[This message has been edited by Lord God Jinnai (edited October 19, 2000).]

**Mark_Everson** · October 18, 2000, 21:31

First of all, I'm having some trouble with the definition of infrastructure as something that includes tanks and other military vehicles. Here is a definition I took off a web page, just because I was too lazy to think of my own definition for infrastructure:

the term "infrastructure" usually refers to public investment in constructing and maintaining roads, bridges, airports, railroads, communications networks, water supplies, solid waste management, electricity production and distribution systems, the legal system, police and fire protection services, etc.

Now we have agreed in another thread that we might treat things like capital in the economic model using an infrastructure class, seeing as its just essentially slightly mutilating a piece of nomenclature, and would keep down the number of unique game objects that we need. So I don't have a problem with you calling factories infrastructure for the game object model, even though it's technically wrong.

But it seems to me to be hopelessly confusing things to also add self-propelled military vehicles and ships as an infrastructure class. They are really completely different from the other things we are calling infrastructure, and the should be an object all their own called perhaps weapons, or weapons systems, or something like that.

Doesn't this almost all-inclusive definition of infrastructure seem wrong to anyone else?

So when putting together a military unit you would add people, weapons, and training to create the aggregate military unit. (Perhaps the training should be associated directly with the people in the object model for a military unit). But this is another topic, and we can cover it later.

Leaving the issue of tanks etc. as infrastructure aside for the moment, I agree with the things that Richard put down for the infrastructure class:

Infrastructure
Name
Pointer to infraclass (Defines what it does and how it works)
Quantity
Quality (Multiplies effects defined by the infraclass)

Each infraclass (describing the overall behavior of the type of infrastructure) should have the characteristics that axi outlined in Proposal for a Complete Infrastructure Model. I'll name them below, and provide a short definition, but you may need to look in the thread to see what the specific meaning of each is.

Infraclass:
- Persistant/Consumed. A dummy variable. An infraclass is consumed (0) when the amount that gets used is lost in the process (this is true for food and consumer goods; it might also be true for other classes too).
- Mobility. What % of this classes units is mobile and can be taken away from the mapsquare/province/civ the model is applied.
- Decay. What % of each classes units gets lost each turn.
- Backup. The % of a classes units that is kept unused, although it can be used. This has sense chiefly for making stores of consumed classes.
- Minimum Output. The minimum (per capita) # of each classes units that are needed for survival.

These definitions don't work really well with what I would call military infrastructure, at least for things like fortifications. So perhaps what we really need is an Infrastructure superclass, that then has EconomicInfrastructure, MilitaryInfrastructure and other objects that inherit from it.

Sorry, but that's all I've got time for tonight. I'll put more thoughts down as soon as I get a chance.

**Richard Bruns** · October 18, 2000, 21:34

I was listing everything in the guts of the model, not what the player sees.

The renewability attribute is a good addition. But rather than being an innate property, I think it should be determined by outside factors. FE the renewability of a particular patch of forest is determined by the ecology model and can change over time.

**Richard Bruns** · October 18, 2000, 21:47

Mark:

I didn't mean for the TF itself to be a part of the Fort infrastructure. The pointer in the Fort is simply a flag showing the location of the army. So when that TF moves, the pointer could move to the "Forest" or "Village". The TF itself is stored seperately and independently, at the square level.

**F_Smith** · October 19, 2000, 00:18

Infrastructure and Resource Class OO Design

Hi, all:

I'm going to have a lot of free time to code this weekend, so let's try and help me get a good understanding of what will have to go into these classes before I code them up!

Otherwise, who knows what I'll produce . . .

First, the background --

A 'MapSquare' has a 'Terrain' object. This 'Terrain' object will hold a collection of 'Infrastructure' objects, and a collection of 'Resource' objects. (Or a collection of 'pointers' to those objects, to be more accurate).

So what we need to do first is have a quick brainstorming session. Post any and all ideas for properties of each of these objects. Even post ideas that might seem silly -- we need to consider everything.

We need people willing to stretch the limits, push the boundaries, consider things that might seem a bit off. This is absolutely important. Most of the ideas might not make the cut into the final object, but if even one excellent new idea does come along, we've gained big-time.

I'll try and start this off. First, some definitions:

Infrastructure: any man-made structures/facilities. Structures with a single use but multiple buildings can be grouped, like 'housing' instead of one object for each house. Or 'factories' instead of one object for each factory. Examples of 'Infrastructure' instances are,

Resource:

**axi** · October 19, 2000, 04:53

Hi guys! I think I will be probably able to help out too this weekend.

Please take extra care to have a sound definition of what is and what is not considered infrastructure. I feel that we should try to hold any manmade item in such a class. Of course food, consumed goods, military units and Kapital infrastructure are odd categories, but we could try to include them and if we don't like the way it gets done, we can exclude them from the investment machine only, or even from the preferences machine too.

Someone had said that military units are not just piles of "shields" (mil.units ifra units) put are also a whole "habitat" carrying people inside it. So #of infra units is only one element of a TF object, which covers the total amount of it's military equipment. This means that the characterisitics of a TF won't be defined singly by the infraclass's attributes.

**F_Smith** · October 19, 2000, 14:41

Cool, lot's to digest.

I only have a little while, so I'll mull this over and comment tonight.

One thing --

Mark:

'Tanks' would not be 'infrastructure'. Unless it was a tank so large that it qualified. I was thinking 'tank yard' or somesuch would be an 'infraclass'. The individual 'tanks' would be 'tools', which we haven't really gotten to yet. All weapons are armor will likely be 'tool' subclasses/instances. So a military unit is a combination of men and tools. The men have training and experience with various tools.

Ships, I am not to certain about. Perhaps they should be 'tools' too. We should discuss this further.

Does that sound okay?

Similarly, 'horses' wouldn't be infrastructure. But a 'warhorse stable' would be. The stable, or tank yard, would contain a number of horses, or tanks. So those horses, or tanks, could be added to a 'TaskForce' when necessary. This does not work for 'ships', which are not necessarily tied to one port. Altho we could force all ships to have a 'home' port . . . that would simplify things. I'm open to that.

* * *

Richard:

I'm swamped at work today, so I can't really do justice to your post, but it looks okay on the whole. I'm sure I'll have one or two comments, later tonight, but for now, I'm sorry but time is short.

[This message has been edited by F_Smith (edited October 19, 2000).]

**Mark_Everson** · October 19, 2000, 19:03

F_Smith:

Your take sounds basically ok. I hope to never use many of the things you talk about, like horse maintainence infrastructure, but to make them available in the OO design is fine .

**axi** · October 21, 2000, 07:58

F_Smith: I think that you're too influenced by RTS games architecture. Your vision of the game reminds me of AOE, where you had buildings which produced units, hence your reference to "infrastructure" vs "tools". My vision is more like in civ2: infrastructure is considered anything that a province can build (what would have been in the build menu in civ). So it is both the actual immobile structures, mobile units, wonders and even consumable goods.

All differences between these categories can be expressed via the varius attibutes of infraclasses, such as "mobility" and "persistant/comsumed" and their commodity costs. You can of course make 2 or more kinds of infraclasses OO-wise, but they still have to be treated in the same way in what concerns the infrastructure model: the preferences and the investment machine. So whatever behavior you give your infraclass objects it must be expressed OUTSIDE the infrastructure model.

The infraclass units can be used generically (as we do with food, consumed goods and durable goods) or as the "equipment quantity" variable of an object, such as a certain building of a military TF, common or wondrous. In these cases the infra units will not belong to the economic unit that produced them (the province), but to the unit/object they are assigned (although many of these objects will be linked to/belong to a certain province: buildings even TFs in some cases). Please do not misunderstand my talking of buildings: Clash is and will continue to be a "NO BUILDINGS GAME", but, using infraclasses the way I prescribed, it's architecture allows for buildings to be used. Using the reverse logic, it allows generic warfare to be conducted, without the need for certain TF objects, but simply using the # of "military units infraclass" units that a province posseses, regardless of the fact that we still CHOOSE to develop the military model with the use of TF objects.

------------------
"In a time of universal deceit, telling the truth is a revolutionary act."
George Orwell
[This message has been edited by axi (edited October 21, 2000).]

**F_Smith** · October 21, 2000, 16:34

Axi:

'Tools' will not be handled the same was as 'infrastructure'. They must be two different objects. And object behavior will not be handled outside outside of the object, each object type will have it's own behavior encapsulated within it. The basic difference between a tool and an infrastructure unit is a 'tool' will have the ability to be 'used' by a person/people.

One sign that we've ended up with a good object structure will be that it will be able to handle both the more detailed, 'RTS'-style level of detail and the more abstract, 'Civ 2' level of detail. So don't worry if all you want to do with tools is track their number. In your basic game, you don't have to use the ability to track tool attributes like tool quality, tool damage, etc. But others will want to use those.

Again, this is only data storage structure. Your game logic will be in the 'turnhandlers', and can treat tools and infrastructure in any way you want. This data structure already does what you want -- it just is capable of more, to please others, also.

Because I'll be honest with you, the abstract approach to infrastucture does not sound very "fun", to me. I'm willing to code it into the turn logic, but if/when it ends up "not fun" I do not want to be stuck with an object architecture that can only make a Civ clone. Which is what I think you're really making.

I want much more than that, personally.

Announcement

Infrastructure and Resource Class OO Design

Infrastructure and Resource Class OO Design

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment