ACK! Buildings Model Details

For what's not in 'Top Priority Game Design'. Post your ideas, visions, suggestions for the game, rules, modifications, etc.

Moderators: Oberlus, Oberlus

Post Reply
Message
Author
User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12471
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

ACK! Buildings Model Details

#1 Post by Geoff the Medio » Mon Dec 20, 2004 11:14 am

As I mentioned here, viewtopic.php?p=17424#17424

There are some glaring omissions in the current model for buildings. We spent a lot of time working out effects, but forgot to deal with most of the non-effects details of buildings, aside from cost, build time, simple maintainance and a name and description.

In order to remedy that, I've written up a draft pseudobrainstorming wiki page of buildings model issues and possible solutions. It is here: http://www.freeorion.org/index.php/Buil ... l_Quickpad

Thoughts / comments? tzlaine / Aq?

edit: fixed wiki link from before it was changed...
Last edited by Geoff the Medio on Mon Jan 24, 2005 10:01 am, edited 1 time in total.

emrys
Creative Contributor
Posts: 226
Joined: Fri Oct 24, 2003 3:44 pm

Re: ACK! Buildings Model Details

#2 Post by emrys » Mon Dec 20, 2004 3:30 pm

Geoff the Medio wrote:As I mentioned here, viewtopic.php?p=17424#17424

There are some glaring omissions in the current model for buildings. We spent a lot of time working out effects, but forgot to deal with most of the non-effects details of buildings, aside from cost, build time, simple maintainance and a name and description.

In order to remedy that, I've written up a draft pseudobrainstorming wiki page of buildings model issues and possible solutions. It is here: http://www.freeorion.org/wiki/index.php ... l_Quickpad

Thoughts / comments? tzlaine / Aq?
Random collection of thoughts:

Not keen on the 'Register' property. Having temptingly non-specific properties like this just seems like a recipe for confusion , conflict and disaster. In other words, an OO nightmare. Either make it more specific, or allow a series of more general variables (i.e. something like the (hideous if you're into C) syntax of Source("SpecificRegister") defaulting to some number if unset previously).

Timer is just about o.k. since at least it pins the use down to the time domain. However <Activated>1</Activated> etc. should probably be replaced with synmoblic constants like <Activated>NonZero</Activated> etc. Otherwise we're just asking for some loon to write and effect based on <Activated>4</Acitvated>!

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12471
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: ACK! Buildings Model Details

#3 Post by Geoff the Medio » Mon Dec 20, 2004 3:51 pm

emrys wrote:Not keen on the 'Register' property. Having temptingly non-specific properties like this just seems like a recipe for confusion , conflict and disaster. In other words, an OO nightmare.
I suspect tzlaine will agree with you... I think he's mentioned dislike of overly general and thus hard to test and debug properties. Hence my making it optional.
However <Activated>1</Activated> etc. should probably be replaced with synmoblic constants like <Activated>NonZero</Activated> etc. Otherwise we're just asking for some loon to write and effect based on <Activated>4</Acitvated>!
tzlaine uses true = 1 and false = 0 in several other effects XML formats, so I'm going to stick with that convention unless he says otherwise.

(remainder edited based on noelte's comments)

For the TimerState condition, the values for the <activated> field would be 0 for false and any non-zero number for true. Putting 4 or any other non-zero number would work exactly the same as putting 1. So you wouldn't be able to hijack the TimerState condition to do anything unintended that way.

The same applies to the SetEnabling effect and Enabled condition.
Last edited by Geoff the Medio on Mon Dec 20, 2004 4:46 pm, edited 1 time in total.

User avatar
noelte
Juggernaut
Posts: 872
Joined: Fri Dec 26, 2003 12:42 pm
Location: Germany, Berlin

#4 Post by noelte » Mon Dec 20, 2004 4:29 pm

Using numbers within <Activated>1</Activated> is the most easy way to do it (from a programmers point of view). BTW only 0 is taken as False any other value is True. But IMO we should use <Activated> True </Activated> and <Activated> False</Activated>
Press any key to continue or any other key to cancel.
Can COWs fly?

emrys
Creative Contributor
Posts: 226
Joined: Fri Oct 24, 2003 3:44 pm

#5 Post by emrys » Mon Dec 20, 2004 5:15 pm

noelte wrote:Using numbers within <Activated>1</Activated> is the most easy way to do it (from a programmers point of view). BTW only 0 is taken as False any other value is True. But IMO we should use <Activated> True </Activated> and <Activated> False</Activated>
<pedantry> Using hard coded (meaningless) constants (e.g. '0' = false, '1'= true (or worse anynumber but 0 = true) is not a great move (for readability, maintenance, portability, clarity etc.). (It is VERY C though :) ) </pedantry>

<realism> If anyone saw the number of hardcoded, cyptic constants in my code, they'd have apoplexy!</realism>
Putting 4 or any other non-zero number would work exactly the same as putting 1. So you wouldn't be able to hijack the TimerState condition to do anything unintended that way.
Unintended? But I intended that incomprehensible weird behaviour to happen! The mere fact that nobody else knows what's going on is their problem, not mine... :wink: :wink: :wink: (Aren't you glad I'm not coding on this project)

User avatar
utilae
Cosmic Dragon
Posts: 2175
Joined: Fri Jun 27, 2003 12:37 am
Location: Auckland, New Zealand

#6 Post by utilae » Mon Dec 20, 2004 9:14 pm

Out of interest:
What is the difference between the time and register effects you propose?

Also what possible practical uses could they be used for?

What practical use would the galaxy turn condition have?

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12471
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

#7 Post by Geoff the Medio » Tue Dec 21, 2004 3:59 am

utilae wrote:What is the difference between the time and register effects you propose?
The time value, condition and effect would only be useful for counting time, while the register stuff would be much more versatile. With time, you can only set the value to a positive integer or 0, but the register can be set to any value. I suppose if you really wanted, you could use the SetTimer effect to set the timer to any value each turn, and if the optional TimerValue condition is used, be able to use it just like a register, but it's specifically named with "Timer", so it's clear that it's only intended for use as a timer. Timer would, however automatically decrement by 1 each turn.

Perhaps, if we wanted to avoid the misuse of timer, we could make the only effect that can alter it "ResetTimer" which sets the Timer value = 0. Then the TimerValue condition would be used to check if the timer value was with a certain range. This way, it would be impossible to misuse the timer like a general purpose register.
Also what possible practical uses could they be used for?
An event, or series of events, that occur over several turns could be made. Say I had a plague that progressed slowly over several turns, doing differing and repeated damage to population and health. Say I had a star that was about to impode... there could be a series of smaller events leading up to the big one. Say I had a building that could only be used once every 10 turns... this would allow the game to keep track of how long it had been since it was used.
What practical use would the galaxy turn condition have?
Timing the release of space monsters or ion storms so the players have a chance to build up and prepare. Scheduling all of the special events in a game scenario. Having an effect that changes in magnitude as a function of game turn. Having an effect that has changing chance of firing as a function of game turn.

User avatar
tzlaine
Programming Lead Emeritus
Posts: 1092
Joined: Thu Jun 26, 2003 1:33 pm

#8 Post by tzlaine » Tue Dec 21, 2004 11:51 pm

Events (not yet in the game) will take care of effects that have a certain duration. And, yes, I do think the Register idea is just plain wrong.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12471
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

#9 Post by Geoff the Medio » Wed Dec 22, 2004 2:13 am

tzlaine wrote:Events (not yet in the game) will take care of effects that have a certain duration.
Including disabling a building for N turns after a player activates its function (causing an event?), during which time the player would be unable to re-activate the function?

Will they be able to handle dynamic-length delays between effects? Eg. N turns between discrete events, not events that last M turns.

If so, that probably takes care of the timing issues.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12471
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

#10 Post by Geoff the Medio » Sat Jan 01, 2005 2:57 pm

I've updated the suggested solutions stuff on the wiki page.

The Timer stuff is still there until I know whether tzlaine's events will deal with all desired timing issues.

The Register stuff is gone.

I'd like some comments about the Production Prerequisites stuff (for buildings) here: http://www.freeorion.org/index.php/Buil ... requisites

What do we or don't we need for this?

Post Reply