Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #30700

Re: design question:game skill system

Path csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!ecngs!feeder2.ecngs.de!newsfeed.freenet.ag!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Return-Path <tyler@tysdomain.com>
X-Original-To python-list@python.org
Delivered-To python-list@mail.python.org
X-Spam-Status OK 0.000
X-Spam-Evidence '*H*': 1.00; '*S*': 0.00; 'value,': 0.03; 'cache': 0.05; 'level,': 0.07; 'subject:question': 0.08; 'cached': 0.09; 'constants.': 0.09; 'input,': 0.09; 'lookup': 0.09; 'perks': 0.09; 'subject:design': 0.09; 'cc:addr:python-list': 0.10; "wouldn't": 0.11; 'suggest': 0.11; 'library': 0.15; 'attribute,': 0.16; 'caching': 0.16; 'container.': 0.16; 'dynamic,': 0.16; 'flag,': 0.16; 'from:addr:tyler': 0.16; 'from:addr:tysdomain.com': 0.16; 'from:name:littlefield, tyler': 0.16; 'identifiers': 0.16; 'message-id:@tysdomain.com': 0.16; 'oct': 0.16; 'reasonable.': 0.16; 'received:69.164': 0.16; 'received:69.164.206': 0.16; 'received:69.164.206.65': 0.16; 'received:tds-solutions.net': 0.16; 'rough': 0.16; 'set,': 0.16; 'somehow,': 0.16; 'storing': 0.16; 'uniquely': 0.16; 'later': 0.16; 'string': 0.17; 'wrote:': 0.17; 'char': 0.17; 'specify': 0.17; 'code,': 0.18; 'trying': 0.21; 'regardless': 0.21; 'all:': 0.22; 'assuming': 0.22; 'finally,': 0.22; 'modifying': 0.22; 'object.': 0.22; 'received:192.168.1.100': 0.22; 'work,': 0.22; "i'd": 0.22; 'cc:2**0': 0.23; 'needed.': 0.23; 'player': 0.23; 'idea': 0.24; 'cc:addr:python.org': 0.25; 'header:In-Reply-To:1': 0.25; 'header :User-Agent:1': 0.26; 'first,': 0.27; 'possibly': 0.27; 'separate': 0.27; 'core': 0.27; 'in.': 0.27; "doesn't": 0.28; '50,': 0.29; 'concern': 0.29; 'project:': 0.29; 'though.': 0.29; 'points': 0.29; 'url:code': 0.29; "i'm": 0.29; 'that.': 0.30; 'becomes': 0.30; 'checks': 0.30; 'performing': 0.30; 'function': 0.30; 'figure': 0.30; 'code': 0.31; 'point': 0.31; 'system,': 0.32; 'generally': 0.32; 'running': 0.32; 'could': 0.32; 'builds': 0.33; 'curious': 0.33; 'like:': 0.33; 'right?': 0.33; 'turns': 0.33; 'self': 0.34; 'thanks': 0.34; 'clear': 0.35; 'whatever': 0.35; 'ahead': 0.35; 'direction': 0.35; 'exist': 0.35; 'pm,': 0.35; 'something': 0.35; 'there': 0.35; 'list.': 0.35; 'add': 0.36; 'really': 0.36; 'but': 0.36; 'wanted': 0.36; 'skip:{ 10': 0.36; 'method': 0.36; 'anything': 0.36; 'possible': 0.37; 'level': 0.37; 'why': 0.37; 'previous': 0.37; 'data': 0.37; 'subject:: ': 0.38; 'store': 0.38; 'mean': 0.38; 'some': 0.38; 'sure': 0.38; 'performance': 0.39; 'received:192': 0.39; 'called': 0.39; 'where': 0.40; 'received:192.168': 0.40; 'your': 0.60; 'identify': 0.61; 'url:p': 0.63; 'information': 0.63; 'more': 0.63; 'costs': 0.64; 'gave': 0.65; 'total': 0.65; 'overall': 0.66; 'purchase': 0.67; 'sounds': 0.71; 'increase': 0.72; 'inform': 0.78; 'subject::': 0.83; 'calculations': 0.84; 'cost,': 0.84; 'light- weight': 0.84; 'subject:system': 0.84; 'care,': 0.91; 'dirty': 0.91; 'on?': 0.91; 'factors': 0.95
X-Spam-Checker-Version SpamAssassin 3.3.1 (2010-03-16) on wuff
X-Spam-Level
X-Spam-Status No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1
Date Wed, 03 Oct 2012 15:20:43 -0600
From "Littlefield, Tyler" <tyler@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.kelly@gmail.com>
Subject Re: design question:game skill system
References <506B47DB.9030401@tysdomain.com> <CALwzidmgwdWgefVz04A63OXpntO7gmTz7T+hsXROYiy1C0W5zQ@mail.gmail.com>
In-Reply-To <CALwzidmgwdWgefVz04A63OXpntO7gmTz7T+hsXROYiy1C0W5zQ@mail.gmail.com>
Content-Type text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding 7bit
Cc Python <python-list@python.org>
X-BeenThere python-list@python.org
X-Mailman-Version 2.1.15
Precedence list
List-Id General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe <http://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive <http://mail.python.org/pipermail/python-list/>
List-Post <mailto:python-list@python.org>
List-Help <mailto:python-list-request@python.org?subject=help>
List-Subscribe <http://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Newsgroups comp.lang.python
Message-ID <mailman.1776.1349299262.27098.python-list@python.org> (permalink)
Lines 72
NNTP-Posting-Host 2001:888:2000:d::a6
X-Trace 1349299262 news.xs4all.nl 6887 [2001:888:2000:d::a6]:59660
X-Complaints-To abuse@xs4all.nl
Xref csiph.com comp.lang.python:30700

Show key headers only | View raw


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 <tyler@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.

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread


Thread

Re: design question:game skill system "Littlefield, Tyler" <tyler@tysdomain.com> - 2012-10-03 15:20 -0600

csiph-web