19-10-2000 09:18									#1
	Infrastructure and Resource Class OO Design Tired of ads?

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 . . .

[*]defenses
[*]housing
[*]large vehicles (tanks, ships, etc).
[*]irrigation ditches/tractor/crop-dusting airplane
[*]schools/factories/etc
[/list]

* * *

Resource: anything that can be the input to a production function. Resources will be grouped by type, with an 'amount' variable -- one object for 'trees', instead of one object for each tree. Examples are,


[*]trees
[*]berry bushes
[*]tin
[*]iron
[*]water
[*]horses
[*]sheep
[*]wheat
[*]cotton
[/list]

So the question now is, what 'properties' does each object need? For example, 'Resources' needs a 'units' integer, and a 'type' String.

Have at it!

	19-10-2000 02:13									#2
	Enter the AD-FREE zone

Here is something I posted in the last thread. It seemed like everyone agreed with it. It seems to fit in to this discussion as well. The text in bold is a change to the original post.
---

I have been thinking about the vegetation class being derived from the resource class. Simply for naming purposes, it would be good to call them different things. Right now, we don't know if "resourse" means the entire forest or just the medicinal herbs.

So I propose creating a derived class called "GroundCover." Originally I called it "Vegetation", but that definition wasn't broad enough. This class extends the resource class or the infrastructure class and adds the following functionality:

Defines the percent of land area of the terrain occupied by the ground cover.

Determines erosion, soil loss, water quality changes, global climate change effects, and other things needed by the ecology model.

Determines defense adjustment and travel time for land units. It also determines if it is even possible for a unit to cross the terrain. FE tanks could not cross a swamp but infantry could.

GroundCover classes include crops, natural vegetation, water, and human habitation.

So we have:

[*]mapsquare


[*]Climate ("Warm Temperate Zone")
[*]Natural Water Rating
[*]Ethnic Group ("3,000 Romans")
[*]Ethnic Group ("200 Etruscans")
[*]Task Force ("Fifth Legion")
[*]terrain ("Mountains, 20%)


[*]Potential Water Rating
[*]Land Value
[*]resource ("X tons of iron ore")
[*]resource ("Y tons of non-ferrous ore")
[*]GroundCover ("Barren ,99%")
[*]GroundCover ("Human Habitation, 1%")


[*]infrastructure ("Lookout Posts")


[*]pointer to TF
[/list][/list][/list]
[*]terrain ("Hills, 70%")


[*]Potential Water Rating
[*]Land Value
[*]resource ("X tons of coal")
[*]resource ("Y tons of iron ore")
[*]resource ("Z tons of non-ferrous ore")
[*]GroundCover ("Scrubland, 30%")


[*]resource ("Y tons of game")
[/list]
[*]GroundCover ("Forest, 68%")


[*]resource ("X cord feet of lumber")
[*]resource ("Y tons of game")
[*]resource ("Z pounds of medicinal herbs")
[/list]
[*]GroundCover ("Human Habitation, 2%")


[*]infrastructure ("Fort Valor")


[*]pointer to TF
[/list][/list][/list]
[*]terrain ("Valley, 10%")


[*]Potential Water Rating
[*]Land Value
[*]resource ("X tons of clay")
[*]resource ("Y tons of gravel")
[*]GroundCover ("River, 10%")


[*]resource ("X tons of fish")
[*]resource ("Y gallons of water")
[/list]
[*]GroundCover ("Human Habitation, 10%")


[*]pointer to EG's
[*]infrastructure ("Dock")
[*]infrastructure ("30 Fishing Boats")
[*]infrastructure ("Housing")
[*]and so on. . .
[/list]
[*]GroundCover ("Crops, 80%")


[*]resource ("X bushels of barley")
[*]resource ("Y bushels of wheat")
[*]resource ("Z bushels of vegetables")
[/list][/list][/list] [/list]

---

I'm not sure how to approach the properties, but here is my shot at it:

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.)
[*]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.)

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

Ground Cover
Since this would probably extend the other two classes, I'll only list the added properties:
[*]Percentage of the terrain
[*]Pointer to global properties definition
[*]Density/Concentration (Modifies some global properties. FE a dense forest is harder to move through and gives better defense.)

The global properties list would have the following:
[*]Ecology Effects (Full Details not yet determined)
[*]Defense Modifier
[*]Movement cost defined seperately for each unit type. (Can be a number or "Impassable")
[*]Attrition effects on each unit type. (Rugged terrain wears down machines more.)

Is that what you were looking for, F_Smith?
[This message has been edited by Richard Bruns (edited October 18, 2000).]

	19-10-2000 06:31									#4
	Browse Apolyton AD-FREE

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.

	19-10-2000 06:34									#5
	Support Apolyton, buy Call to Power 2

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.

	19-10-2000 06:47									#6
	Increase the size of your Attachments

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.

	19-10-2000 13:53									#7
	Increase Your PM Length

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.

	19-10-2000 23:41									#8
	Support Apolyton, pre-order Civilization IV

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).]

	20-10-2000 04:03									#9
	Support Apolyton buy from Amazon

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 .

	21-10-2000 16:58									#10
	Avatar Enlargement: We've got the solution

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).]

	22-10-2000 01:34									#11
	Support Apolyton, buy GURPS/ Alpha Centauri

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.