Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #30700
| 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
Re: design question:game skill system "Littlefield, Tyler" <tyler@tysdomain.com> - 2012-10-03 15:20 -0600
csiph-web