Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
design question:game skill system
37 views
Skip to first unread message
Littlefield, Tyler
Oct 2, 2012, 4:00:27 PM10/2/12
to pytho...@python.org
Hello all:
I'm looking at a skill/perk system, where the player builds up his char
by using perk points to add abilities.
Each perk is under a category, and generally costs go up as you increase
the perk.
So I'm trying to figure something out; first, I'd really like the cost
calculation and all of that to be dynamic, so that I don't have to write
a calculateCost per object. I'd also like to be able to specify
dependencies and say a level, as well as other factors before a player
can obtain a perk and have them self documenting. The idea is that a
player could do something like:
data perk extended health
and it would tell them they require health at 50 before they can
purchase extended health, as well as the cost, the increase per level
and the total overall cost.
Any ideas on how to set this up would be really appreciated.
Finally, I'm curious how to store and calculate these. I thought about
using a uid per perk, then storing something like: {uid:level} on the
player, but means that I have to lookup the name somehow still in the
main perk database, then use that uid to check if the player has it. Are
there better ways of storing skills? I'm also thinking about
calculation; currently the CalculateMaxHp method would have to add up
all the possible perks for health, then add stats and all that. That
could get really rough on performance if it's called often; would
something like a cache work, where you have something like:
{attribute:dirty}? So if I call CalculateHealth, it checks for the dirty
flag, and if it doesn't exist just returns the previous max HP, but if
the dirty flag is set, it recalculates? Then anything modifying health
(level gains, perks, stat increases/etc) would just set the dirty flag
and call calculate?
Thoughts/ideas would be welcome.
Thanks,
--
Take care,
Ty
http://tds-solutions.net
The aspen project: a barebones light-weight mud engine:
http://code.google.com/p/aspenmud
He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave.
I'm looking at a skill/perk system, where the player builds up his char
by using perk points to add abilities.
Each perk is under a category, and generally costs go up as you increase
the perk.
So I'm trying to figure something out; first, I'd really like the cost
calculation and all of that to be dynamic, so that I don't have to write
a calculateCost per object. I'd also like to be able to specify
dependencies and say a level, as well as other factors before a player
can obtain a perk and have them self documenting. The idea is that a
player could do something like:
data perk extended health
and it would tell them they require health at 50 before they can
purchase extended health, as well as the cost, the increase per level
and the total overall cost.
Any ideas on how to set this up would be really appreciated.
Finally, I'm curious how to store and calculate these. I thought about
using a uid per perk, then storing something like: {uid:level} on the
player, but means that I have to lookup the name somehow still in the
main perk database, then use that uid to check if the player has it. Are
there better ways of storing skills? I'm also thinking about
calculation; currently the CalculateMaxHp method would have to add up
all the possible perks for health, then add stats and all that. That
could get really rough on performance if it's called often; would
something like a cache work, where you have something like:
{attribute:dirty}? So if I call CalculateHealth, it checks for the dirty
flag, and if it doesn't exist just returns the previous max HP, but if
the dirty flag is set, it recalculates? Then anything modifying health
(level gains, perks, stat increases/etc) would just set the dirty flag
and call calculate?
Thoughts/ideas would be welcome.
Thanks,
--
Take care,
Ty
http://tds-solutions.net
The aspen project: a barebones light-weight mud engine:
http://code.google.com/p/aspenmud
He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave.
Ian Kelly
Oct 2, 2012, 4:34:12 PM10/2/12
to Python
On Tue, Oct 2, 2012 at 2:00 PM, Littlefield, Tyler <ty...@tysdomain.com> wrote:
> Hello all:
> I'm looking at a skill/perk system, where the player builds up his char by
> using perk points to add abilities.
> Each perk is under a category, and generally costs go up as you increase the
> perk.
> So I'm trying to figure something out; first, I'd really like the cost
> calculation and all of that to be dynamic, so that I don't have to write a
> calculateCost per object. I'd also like to be able to specify dependencies
> and say a level, as well as other factors before a player can obtain a perk
> and have them self documenting. The idea is that a player could do something
> like:
> data perk extended health
> and it would tell them they require health at 50 before they can purchase
> extended health, as well as the cost, the increase per level and the total
> overall cost.
What are the cost calculations based on? If there are specific
> Hello all:
> I'm looking at a skill/perk system, where the player builds up his char by
> using perk points to add abilities.
> Each perk is under a category, and generally costs go up as you increase the
> perk.
> So I'm trying to figure something out; first, I'd really like the cost
> calculation and all of that to be dynamic, so that I don't have to write a
> calculateCost per object. I'd also like to be able to specify dependencies
> and say a level, as well as other factors before a player can obtain a perk
> and have them self documenting. The idea is that a player could do something
> like:
> data perk extended health
> and it would tell them they require health at 50 before they can purchase
> extended health, as well as the cost, the increase per level and the total
> overall cost.
formulas then you would need to store them somehow, possibly just as a
function to be called or string to be evaled, but if the security of
the perk database is of concern then you could engineer a more
sandboxed representation. For dependencies, you can keep them in a
container. An extended health perk might look something like:
cost_formula = "5 * level ** 2"
dependencies = {HEALTH: 50, PLAYER_LEVEL: 15}
benefits = {HEALTH: "7 * level"}
where HEALTH and PLAYER_LEVEL are just some arbitrary known constants.
Your core perks library would then be responsible for looking this
information up, running the formulas, and performing whatever
calculations on it are needed.
> Finally, I'm curious how to store and calculate these. I thought about using
> a uid per perk, then storing something like: {uid:level} on the player, but
> means that I have to lookup the name somehow still in the main perk
> database, then use that uid to check if the player has it. Are there better
> ways of storing skills?
there is in using abstracted unique identifiers for these. Assuming
you have full control over what perks are added, you can ensure there
will be no name clashes, so why not just use the name or a name-based
tag to uniquely identify each perk? Regardless of how you identify
them, though, your code is at some point going to have to go to the
database to look them up, so I would suggest you just go ahead and
write that code, and then you can add some caching later if it turns
out to be needed.
> I'm also thinking about calculation; currently the
> CalculateMaxHp method would have to add up all the possible perks for
> health, then add stats and all that. That could get really rough on
> performance if it's called often; would something like a cache work, where
> you have something like: {attribute:dirty}? So if I call CalculateHealth, it
> checks for the dirty flag, and if it doesn't exist just returns the previous
> max HP, but if the dirty flag is set, it recalculates? Then anything
> modifying health (level gains, perks, stat increases/etc) would just set the
> dirty flag and call calculate?
When max HP becomes dirty, clear the cached value, and use the absence
of a cached value to inform your code that it needs to recalculate.
Jean-Michel Pichavant
Oct 3, 2012, 4:50:09 AM10/3/12
to Tyler Littlefield, pytho...@python.org
----- Original Message -----
> Hello all:
> I'm looking at a skill/perk system, where the player builds up his
> char
> by using perk points to add abilities.
> Each perk is under a category, and generally costs go up as you
> increase
> the perk.
> So I'm trying to figure something out; first, I'd really like the
> cost
> calculation and all of that to be dynamic, so that I don't have to
> write
> a calculateCost per object. I'd also like to be able to specify
> dependencies and say a level, as well as other factors before a
> player
> can obtain a perk and have them self documenting. The idea is that a
> player could do something like:
> data perk extended health
> and it would tell them they require health at 50 before they can
> purchase extended health, as well as the cost, the increase per level
> and the total overall cost.
> Any ideas on how to set this up would be really appreciated.
> Finally, I'm curious how to store and calculate these. I thought
> about
> using a uid per perk, then storing something like: {uid:level} on the
> player, but means that I have to lookup the name somehow still in the
> main perk database, then use that uid to check if the player has it.
> Are
> there better ways of storing skills? I'm also thinking about
> about
> using a uid per perk, then storing something like: {uid:level} on the
> player, but means that I have to lookup the name somehow still in the
> main perk database, then use that uid to check if the player has it.
> Are
> calculation; currently the CalculateMaxHp method would have to add up
> all the possible perks for health, then add stats and all that. That
> could get really rough on performance if it's called often; would
> something like a cache work, where you have something like:
> {attribute:dirty}? So if I call CalculateHealth, it checks for the
> dirty
> flag, and if it doesn't exist just returns the previous max HP, but
> if
> the dirty flag is set, it recalculates? Then anything modifying
> health
> (level gains, perks, stat increases/etc) would just set the dirty
> flag
> and call calculate?
> all the possible perks for health, then add stats and all that. That
> could get really rough on performance if it's called often; would
> something like a cache work, where you have something like:
> {attribute:dirty}? So if I call CalculateHealth, it checks for the
> dirty
> flag, and if it doesn't exist just returns the previous max HP, but
> if
> the dirty flag is set, it recalculates? Then anything modifying
> health
> (level gains, perks, stat increases/etc) would just set the dirty
> flag
> and call calculate?
> Thoughts/ideas would be welcome.
> Thanks,
Hi,
> Thanks,
Again, do not think about performances before actually having an issue with them. What's the point to optimize something that doesn't need it ?
For your cache problem, google "python memoize decorator" for a bunch of decorators that will allow you to cache your data without any effort.
JM
Littlefield, Tyler
Oct 3, 2012, 5:20:43 PM10/3/12
to Ian Kelly, Python
I just wanted to say thanks to all the people that provided input, both
aonand off list. It gave me a good direction to head in. Thanks again.
aonand off list. It gave me a good direction to head in. Thanks again.
On 10/2/2012 2:34 PM, Ian Kelly wrote:
> On Tue, Oct 2, 2012 at 2:00 PM, Littlefield, Tyler <ty...@tysdomain.com> wrote:
> On Tue, Oct 2, 2012 at 2:00 PM, Littlefield, Tyler <ty...@tysdomain.com> wrote:
>> Hello all:
>> I'm looking at a skill/perk system, where the player builds up his char by
>> using perk points to add abilities.
>> Each perk is under a category, and generally costs go up as you increase the
>> perk.
>> So I'm trying to figure something out; first, I'd really like the cost
>> calculation and all of that to be dynamic, so that I don't have to write a
>> calculateCost per object. I'd also like to be able to specify dependencies
>> and say a level, as well as other factors before a player can obtain a perk
>> and have them self documenting. The idea is that a player could do something
>> like:
>> data perk extended health
>> and it would tell them they require health at 50 before they can purchase
>> extended health, as well as the cost, the increase per level and the total
>> overall cost.
>> I'm looking at a skill/perk system, where the player builds up his char by
>> using perk points to add abilities.
>> Each perk is under a category, and generally costs go up as you increase the
>> perk.
>> So I'm trying to figure something out; first, I'd really like the cost
>> calculation and all of that to be dynamic, so that I don't have to write a
>> calculateCost per object. I'd also like to be able to specify dependencies
>> and say a level, as well as other factors before a player can obtain a perk
>> and have them self documenting. The idea is that a player could do something
>> like:
>> data perk extended health
>> and it would tell them they require health at 50 before they can purchase
>> extended health, as well as the cost, the increase per level and the total
>> overall cost.
> What are the cost calculations based on? If there are specific
> formulas then you would need to store them somehow, possibly just as a
> function to be called or string to be evaled, but if the security of
> the perk database is of concern then you could engineer a more
> sandboxed representation. For dependencies, you can keep them in a
> container. An extended health perk might look something like:
>
> cost_formula = "5 * level ** 2"
> dependencies = {HEALTH: 50, PLAYER_LEVEL: 15}
> benefits = {HEALTH: "7 * level"}
>
> where HEALTH and PLAYER_LEVEL are just some arbitrary known constants.
> Your core perks library would then be responsible for looking this
> information up, running the formulas, and performing whatever
> calculations on it are needed.
>
> formulas then you would need to store them somehow, possibly just as a
> function to be called or string to be evaled, but if the security of
> the perk database is of concern then you could engineer a more
> sandboxed representation. For dependencies, you can keep them in a
> container. An extended health perk might look something like:
>
> cost_formula = "5 * level ** 2"
> dependencies = {HEALTH: 50, PLAYER_LEVEL: 15}
> benefits = {HEALTH: "7 * level"}
>
> where HEALTH and PLAYER_LEVEL are just some arbitrary known constants.
> Your core perks library would then be responsible for looking this
> information up, running the formulas, and performing whatever
> calculations on it are needed.
>
>> Finally, I'm curious how to store and calculate these. I thought about using
>> a uid per perk, then storing something like: {uid:level} on the player, but
>> means that I have to lookup the name somehow still in the main perk
>> database, then use that uid to check if the player has it. Are there better
>> ways of storing skills?
>> a uid per perk, then storing something like: {uid:level} on the player, but
>> means that I have to lookup the name somehow still in the main perk
>> database, then use that uid to check if the player has it. Are there better
>> ways of storing skills?
> When you say uids, you mean UUIDs, right? I'm not sure what advantage
> there is in using abstracted unique identifiers for these. Assuming
> you have full control over what perks are added, you can ensure there
> will be no name clashes, so why not just use the name or a name-based
> tag to uniquely identify each perk? Regardless of how you identify
> them, though, your code is at some point going to have to go to the
> database to look them up, so I would suggest you just go ahead and
> write that code, and then you can add some caching later if it turns
> out to be needed.
>
> there is in using abstracted unique identifiers for these. Assuming
> you have full control over what perks are added, you can ensure there
> will be no name clashes, so why not just use the name or a name-based
> tag to uniquely identify each perk? Regardless of how you identify
> them, though, your code is at some point going to have to go to the
> database to look them up, so I would suggest you just go ahead and
> write that code, and then you can add some caching later if it turns
> out to be needed.
>
>> I'm also thinking about calculation; currently the
>> CalculateMaxHp method would have to add up all the possible perks for
>> health, then add stats and all that. That could get really rough on
>> performance if it's called often; would something like a cache work, where
>> you have something like: {attribute:dirty}? So if I call CalculateHealth, it
>> checks for the dirty flag, and if it doesn't exist just returns the previous
>> max HP, but if the dirty flag is set, it recalculates? Then anything
>> modifying health (level gains, perks, stat increases/etc) would just set the
>> dirty flag and call calculate?
>> CalculateMaxHp method would have to add up all the possible perks for
>> health, then add stats and all that. That could get really rough on
>> performance if it's called often; would something like a cache work, where
>> you have something like: {attribute:dirty}? So if I call CalculateHealth, it
>> checks for the dirty flag, and if it doesn't exist just returns the previous
>> max HP, but if the dirty flag is set, it recalculates? Then anything
>> modifying health (level gains, perks, stat increases/etc) would just set the
>> dirty flag and call calculate?
> Sounds reasonable. I wouldn't use a separate flag attribute, though.
> When max HP becomes dirty, clear the cached value, and use the absence
> of a cached value to inform your code that it needs to recalculate.
> When max HP becomes dirty, clear the cached value, and use the absence
> of a cached value to inform your code that it needs to recalculate.
Ramchandra Apte
Oct 4, 2012, 9:19:33 AM10/4/12
to Tyler Littlefield, pytho...@python.org
Ramchandra Apte
Oct 4, 2012, 9:19:33 AM10/4/12
to comp.lan...@googlegroups.com, pytho...@python.org
On Wednesday, 3 October 2012 14:19:57 UTC+5:30, Jean-Michel Pichavant wrote:
0 new messages