design question:game skill system - comp.lang.python

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
comp.lang.python
Message from discussion design question:game skill system
Path: q11ni134269209wiw.1!nntp.google.com!feeder1.cambriumusenet.nl!feeder3.cambriumusenet.nl!feed.tweaknews.nl!216.40.29.245.MISMATCH!novia!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!news.glorb.com!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Wed, 03 Oct 2012 15:20:43 -0600
From: "Littlefield, Tyler" <ty...@tysdomain.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Ian Kelly <ian.g.ke...@gmail.com>
Subject: Re: design question:game skill system
References: <506B47DB.9030...@tysdomain.com>
	<CALwzidmgwdWgefVz04A63OXpntO7gmTz7T+hsXROYiy1C0W...@mail.gmail.com>
In-Reply-To: <CALwzidmgwdWgefVz04A63OXpntO7gmTz7T+hsXROYiy1C0W...@mail.gmail.com>
Cc: Python <python-l...@python.org>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1776.1349299262.27098.python-l...@python.org>
Lines: 72
NNTP-Posting-Host: 2001:888:2000:d::a6
Bytes: 8686
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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


-- 
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.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
