Browse Groups

• ... For that matter, I would expect that you could make it two recurring effects. One from levels 1-n, another from n+1-10 (or higher, if you go Epic). Keith
Message 1 of 20 , Jan 21, 2004
View Source
On Wed, Jan 21, 2004 at 10:07:40AM -0700, Steven Bethard wrote:
> <quote who="CC Noram Carstensen James">
> > Steve wrote:
> >> I also expect to use the same kind of shorthands you do to indicate
> > recurring Effects (e.g. you should not have to indicate that for a
> > class, at a score of 1, you get a d8 HD, at score of 2 you get another
> > d8 HD, etc.)
> >
> > Would the ability not to do the shorthand still exist? For example, the
> > 3.0 Dragon Disciple did have varying HD by level.
> >
> > Hmm, which of course makes me think about the fun undead types that
> > change every previous and future HD to d12. Could something like that
> > be represented?
> </quote>
>
> Absolutely. It would only be a shorthand for the more explicit
> approach. If the bonuses applied by the shorthand are not what you
> want, you could always go the explicit route.

For that matter, I would expect that you could make it two recurring
effects. One from levels 1-n, another from n+1-10 (or higher, if you go
Epic).

Keith
--
Keith Davies I gave my 2yo daughter a strawberry
keith.davies@... Naomi: "Strawberry!"
me: "What do you say?"
Naomi: "*MY* strawberry!"
• ... solution to part of this problem would be like what I did with size: associate integer values with the different size categories, and just treat increasing
Message 1 of 20 , Jan 22, 2004
View Source
Steve wrote:
> Yup. So shorthands may not always be possible (though I think a clean
solution to part of this problem would be like what I did with size:
associate integer values with the different size categories, and just
treat increasing size category as increasing the variable in an
sjb:Score/kjd:Progression.)

Could you have multi-dimensional kjd:Progressions? Frugal mentioned
monk unarmed damage. To put this into array-speak, could you have a
progression Unarmed[Level,Size] such that you can represent all of the
different combinations, and also have easy ways of doing things like
representing the enlarged (+1 size) monk who is wearing a Monk's Belt
(bonus to monk level) because it just changes the lookup on the table.

(I mention size because for some reason the 3.5 monk damage table for
sizes other then medium doesn't quite follow the 3.5
weapon-damage-change-by-size table.)

-- Jim
• ... I was doing something like this using an order attribute in rating but I think you may be right that a Progression may be a better choice. hrm. If we re
Message 1 of 20 , Jan 22, 2004
View Source
On Thu, Jan 22, 2004 at 12:15:50PM -0500, CC Noram Carstensen James wrote:
> Steve wrote:
> > Yup. So shorthands may not always be possible (though I think a clean
> solution to part of this problem would be like what I did with size:
> associate integer values with the different size categories, and just
> treat increasing size category as increasing the variable in an
> sjb:Score/kjd:Progression.)

I was doing something like this using an 'order' attribute in rating but
I think you may be right that a Progression may be a better choice.

hrm. If we're using Progression for things that *aren't* being applied
in layers (the functionality is quite similar) I think that you may be
right that 'Progression' isn't a great name for the generic form. OTOH,
I think that 'Score' isn't such a great name either... we may want to
think of a different term altogether.

> Could you have multi-dimensional kjd:Progressions? Frugal mentioned
> monk unarmed damage. To put this into array-speak, could you have a
> progression Unarmed[Level,Size] such that you can represent all of the
> different combinations, and also have easy ways of doing things like
> representing the enlarged (+1 size) monk who is wearing a Monk's Belt
> (bonus to monk level) because it just changes the lookup on the table.

I hadn't considered it, but it does make some sense. Actually, 'Array'
might not be a bad name for a collection of related/linked effects.

> (I mention size because for some reason the 3.5 monk damage table for
> sizes other then medium doesn't quite follow the 3.5
> weapon-damage-change-by-size table.)

of course not, that would make sense.

Keith
--
Keith Davies I gave my 2yo daughter a strawberry
keith.davies@... Naomi: "Strawberry!"
me: "What do you say?"
Naomi: "*MY* strawberry!"
• ... Can you then either change the Array you are dealing with, or assign a new level to the array? For one of the feats in
Message 1 of 20 , Jan 23, 2004
View Source
<quote who="Keith Davies">
> On Thu, Jan 22, 2004 at 12:15:50PM -0500, CC Noram Carstensen James wrote:
>> Could you have multi-dimensional kjd:Progressions? Frugal mentioned
>> monk unarmed damage. To put this into array-speak, could you have a
>> progression Unarmed[Level,Size] such that you can represent all of the
>> different combinations, and also have easy ways of doing things like
>> representing the enlarged (+1 size) monk who is wearing a Monk's Belt
>> (bonus to monk level) because it just changes the lookup on the table.
>
> I hadn't considered it, but it does make some sense. Actually, 'Array'
> might not be a bad name for a collection of related/linked effects.

Can you then either change the "Array" you are dealing with, or assign a
new level to the array? For one of the feats in Oriental Adventures you
can change the monks unarmed damage progression to something comlpetely
different...

--
regards,
Frugal
-OS Chimp
• ... Variable ? -- regards, Frugal -OS Chimp
Message 1 of 20 , Jan 23, 2004
View Source
<quote who="Keith Davies">
> hrm. If we're using Progression for things that *aren't* being applied
> in layers (the functionality is quite similar) I think that you may be
> right that 'Progression' isn't a great name for the generic form. OTOH,
> I think that 'Score' isn't such a great name either... we may want to
> think of a different term altogether.

"Variable" ?

--
regards,
Frugal
-OS Chimp
• ... You would not register the Entity, but rather the effects of the Entity. ... The other problem is that any time you add a new
Message 1 of 20 , Jan 23, 2004
View Source
<quote who="Keith Davies">
> Hrm. I'm familiar with Observer-Observable, but in this case doesn't it
> lead to a huge number of links back and forth? Any Entity may have
> observable properties, so wouldn't each Entity need to register?

You would not register the Entity, but rather the effects of the Entity.

>> The other solution to this (something similar to what Scott was
>> suggesting, I think) is to associate with each Score a flag that says
>> "I could be wrong!" and every time you need that Score, you first
>> check it's "I could be wrong!" tag and the "I could be wrong!" tags of
>> any Scores that it depends on. Note that even in this scheme, at some
>> point, you'll have to go and check all the Scores that the Score you
>> want to update is dependent on. (Or just check /all/ the other Scores
>> if you don't want to maintain a dependency list. This makes me
>> nervous though because it doesn't necessarily guarantee a reasonable
>> order of Score updating.)

The other problem is that any time you add a new Effect or Score/Variable
to the character you have to invalidate everything. You can not just
invalidate the things that the Effect invalidates, because you have no way
of knowing what newly invalidated Score/Variable will invalidate.

> . Observer would require that each thing that can change have an
> observer attached; managing this would lead to massive resource
> consumption.

Does anyone know just how heavyweight the Observer pattern is in Java?
From what I understand the only thing that the Observable object adds is a
lookup table of Observers (i.e. A reference per Observer (4bytes on a
32bit system)).

> Now, if things are limited as to when they can change (either readonly
> once loaded, or allowed to change only if in the file being edited [my
> preference, since it allows for multiple edits at once], or readonly
> unless 'edit mode' is entered) then the resources for Observer and
> Scott's model both drop immensely.

I am a bit confused by your reference to Data being Editable... Can you
explain under what circumstances an Entity gets edited?

The way I currently view what people are saying is that the Character is a
set of Progression/Score/Variable (what ever they get called) and a set of
references to Entities that can manipulate those P/S/Vs.

As a Character is defined by its' P/S/Vs it will need to have its' own
local copy of each P/S/V that applies to that Character. So character
Alice will have a P/S/V with the ID 'score.stat'. Bob will also have the
P/S/V with the id 'score.stat' but the two P/S/Vs are not the same Object.

As Entities are applied to a Character the character will have a reference
to each Entity, but will never be able to alter it. Alice can have the
Entity "feat.toughness" applied to her, and Bob can have the Entity
"feat.toughness" applied to him. The two Objects will be the same object.

Or are people talking about a completely different layer to me?

--
regards,
Frugal
-OS Chimp
Your message has been successfully submitted and would be delivered to recipients shortly.
• Changes have not been saved
Press OK to abandon changes or Cancel to continue editing
• Your browser is not supported
Kindly note that Groups does not support 7.0 or earlier versions of Internet Explorer. We recommend upgrading to the latest Internet Explorer, Google Chrome, or Firefox. If you are using IE 9 or later, make sure you turn off Compatibility View.