ACK! Buildings Model Details
Moderator: Oberlus
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
ACK! Buildings Model Details
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...
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.
Re: ACK! Buildings Model Details
Random collection of thoughts: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?
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>!
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: ACK! Buildings Model Details
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.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.
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.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>!
(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.
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?
Can COWs fly?
<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>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>
<realism> If anyone saw the number of hardcoded, cyptic constants in my code, they'd have apoplexy!</realism>
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... (Aren't you glad I'm not coding on this project)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.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
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.utilae wrote:What is the difference between the time and register effects you propose?
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.
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.Also what possible practical uses could they be used for?
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.What practical use would the galaxy turn condition have?
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
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?tzlaine wrote:Events (not yet in the game) will take care of effects that have a certain duration.
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.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
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?
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?