Angband.oook.cz
Angband.oook.cz
AboutVariantsLadderForumCompetitionComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Variants

Reply
 
Thread Tools Display Modes
Old February 19, 2013, 22:46   #41
Kinematics
Apprentice
 
Join Date: Feb 2013
Posts: 71
Kinematics is on a distinguished road
Some thoughts on the issues of stat calculations from the #3 thread that never seemed to have gotten resolved (at least, not in the thread, and the code looks like it's still using the same ideas).


More confusing ways to apply: Suppose you decide that hobbits, rather than a static +3 bonus to dex, get a bonus of level/10, or just +20%. (note: seems less likely for base stats, and more likely to apply to things like speed, such as hengband's level-based speed increase for ninjas; just an example, though) Where does this apply in the calculation hierarchy?

It's part of what's considered the 'Inherent' level of calculation -- the race modifier -- yet depends on other calculations. Which leads me to a slightly different approach.


I would construct it like this:

Fundamental - initial birth value (dice roll, player buy, whatever); cannot change during the game.

Fixed mods - Additions that -do not- depend on the stat itself. static +3 from race; +level/10 to speed; etc.

Multiplier mods - Additions that -do- depend on the stat itself. Ring of +20% str, etc. These are only calculated after Fixed mods are done.


Whether it's a permanent or temporary effect doesn't matter. Ring of +3 str or Ring of +20% str are both permanent, but don't get calculated at the same time. A spell of Giant Strength that adds +5 to str for 50 turns would go under Fixed mods, not Multiplier mods, and there's no reason to treat it differently than a ring of +5 str.


Now, the hypothetical example:

Quote:
Okay, so say we have a ring that gives you a bonus to INT based on your magic device skill. Say further that magic device skill is determined in large part by your DEX.
Ring would adjust Int as a Fixed mod based on Magic Devices.
Dex would adjust Magic Devices skill as a Fixed mod.

So when calculating Int, it gets to the Fixed mods level, determines there's a ring that modifies it (or the ring inserts its StatMod call into the queue), asks the ring how much to modify things by. Ring says "Hold on a minute..", asks how much the MD skill is; MD skill queries Dex, which carries out all of its calculations, returns a value, MD gets calculated, returned to the Ring, Ring figures out its value, and gives that to Int. No problems.

Now suppose Magic Devices depends on Int, and the Ring mods Int based on Magic Device skill. What I would do:

What is current Int? Start adding Fixed mods to the Fundamental value. When a StatMod() is called, mark it as 'In Use', and release it afterwards.
Call Ring.StatMod(). It queries Magic Devices for skill.
Magic Devices needs to know Int. Requests current Int value.
What is current Int? Start adding Fixed mods to the Fundamental value. Ring.StatMod() is 'In Use', so gets skipped. Returns a value for all adjustments other than Ring.StatMod().
We now have a Magic Devices skill value relevant to the Ring's query (not full magic skill, but magic skill without the bonus the ring provides). Return that.
Ring.StatMod() now has a value for Magic Devices skill, and returns the amount it increase Int by.
Int completes the Fixed mods calculations.
Int can then proceed to later add a Ring of +20% Int using the value that includes the MD-based Int ring value.

Supposing you had 2 such rings -- each gets locked during the Magic Device Skill query, so that the MDS value that they each use is based on neither of the rings being present. I'm pretty sure this would hold even if every single equip slot was making this same modification, though that would add a huge number of near-circular redundant calls. You could maybe cache each StatMod() call within a given top-level request, to reduce the redundancy; just make sure not to re-cache during a circular cycle.



Differentiating between Fixed and Multiplier mods would probably be easiest by just having two different functions. You can either insert a StatMods() call into the queue for complicated calculations that will eventually provide a fixed value addition, or just provide a simple percentage to the total multiplier value to be used as the final adjustment after Fixed mods are added in. EG:

OnEquip ring of str, AddStatMod(MyFunction)
OnEquip ring of +20% str, AddStatMultiplier(20%)

Though technically there's nothing to prevent the StatMod() call from calculating its result from the stat itself; it's just bad form, and will give lesser results [Edit: actually, it would probably give identical results; it would just take more work since you have to calculate everything twice], but won't break anything.
Kinematics is offline   Reply With Quote
Old February 19, 2013, 23:24   #42
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 8,920
Derakon is on a distinguished road
I admit that I didn't read your entire post, so I apologize for short-circuiting the conversation. But my eventual conclusion on this problem is that there is no right answer, and it's up to the game designer to pick modifier tiers in a way that makes sense. The game will enforce an ordering of stat modifiers, so there can be no cyclic dependencies, but that's all it will do. "Inherent", "permanent", "temporary", etc. tiers may or may not make sense depending on what the designer wants to do, but they clearly won't fit every possible design.
Derakon is offline   Reply With Quote
Old February 20, 2013, 02:16   #43
Kinematics
Apprentice
 
Join Date: Feb 2013
Posts: 71
Kinematics is on a distinguished road
Quote:
"Inherent", "permanent", "temporary", etc. tiers may or may not make sense depending on what the designer wants to do, but they clearly won't fit every possible design.
Been going over the code more. I -think- it's generic enough that my thoughts could be represented with the framework.

If I'm reading it correctly, each mod can set its own tier? That is, individual stats aren't given tiers, just the mods, so the tier isn't dependent on what stat is being calculated?

So, I could have a Ring +3 str on the Add (first) tier, and a Ring +20% str on the Multiply (second) tier, and generally define all stats and mods with respect to just those two tiers?

Possible bug: Not sure, but it looks like if the mods are listed out of order with respect to tier (eg: a queue of tier 1, tier 3, tier 2, tier 3, tier 1, etc) that the results would be unpredictable (specifically, if there are any multiplications in the queue).

Also, I think you preempt the recursive calls too early, and too completely. Basically, rather than blocking recursion at the stat level, it should be blocked at the mod level. Would require mods to be copied by reference rather than generating multiple instances of them, so that local state has meaning, but then you can just have ~~
Code:
    if (!blocked) then
      blocked = true
      get proc value
      blocked = false
      return value
    else
      return 0
Or use whatever atomic lock operations you want, though it shouldn't matter if you're not doing multi-threading.

Honestly, I still think the tiers are a bad idea. The same operation on a different tier can give a different result, which means a single effect (eg: +20% str) can't be relied on to produce consistent values if applied at different tiers. Plus they don't actually add anything of value; their entire purpose of stopping circular calculations can be handled by simply blocking the recursion.

There's really only two necessary operations: unit-based addition (the value is concrete), and unitless multiplication (the value depends on the existing value, and can only be applied after all the concrete values are added in). One might argue the option of multiplying all of the the unitless values together vs adding them together before multiplying by the total (I'd suggest the latter); otherwise I'd expect completely agnostic calculations.
Kinematics is offline   Reply With Quote
Old February 20, 2013, 03:11   #44
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 8,920
Derakon is on a distinguished road
Quote:
Originally Posted by Kinematics View Post
There's really only two necessary operations: unit-based addition (the value is concrete), and unitless multiplication (the value depends on the existing value, and can only be applied after all the concrete values are added in). One might argue the option of multiplying all of the the unitless values together vs adding them together before multiplying by the total (I'd suggest the latter); otherwise I'd expect completely agnostic calculations.
This is true until you decide to add a modifier that can't be easily expressed by addition or multiplication. A StatMod can invoke a Proc to generate a value based on whatever it likes, including e.g. distance from something on a map (grunts getting a morale bonus when close to their leaders), items in inventory (taking a speed penalty because you're carrying heavy stuff), time of day (vampires get bonuses at night), etc. All of these could scale in very weird ways if that's the way the designer wants to run things.

Pyrel's guiding principle for design is "If I can imagine use cases I might reasonably implement that require this feature, then it should be implemented." I'm not going to try to stretch the design to do everything under the sun -- it'd never be done, that way -- but I can easily imagine wanting to have complex stat modifier interactions. Stats form such a key part of the game; that makes them a good place to look to if you want to add interesting decisions.

For what it's worth, if you want to have additive and multiplicative modifiers as separate things, then you can add a new stat that all the multipliers add to, and then attach a low-priority modifier to the base stat that incorporates the multipliers. E.g. have a "STR Multiplier" stat which receives additive modifiers, and then have a multiplicative modifier on STR that uses 1 + the "STR Multiplier" value. This is kind of indirect, but it gets the job done just fine.
Derakon is offline   Reply With Quote
Old February 20, 2013, 07:46   #45
Kinematics
Apprentice
 
Join Date: Feb 2013
Posts: 71
Kinematics is on a distinguished road
First: sorry for the length, but it takes a bit to go through all the points, and I want to make sure that each one is clear. If I'm completely out in left field on this analysis, smack me and send me to my room.


Quote:
This is true until you decide to add a modifier that can't be easily expressed by addition or multiplication. A StatMod can invoke a Proc to generate a value based on whatever it likes, including e.g. distance from something on a map (grunts getting a morale bonus when close to their leaders), items in inventory (taking a speed penalty because you're carrying heavy stuff), time of day (vampires get bonuses at night), etc. All of these could scale in very weird ways if that's the way the designer wants to run things.
Hmm. I'm not sure I get what you mean here. Each of those effects -depend- on non-integral information, but will any of them ever -generate- non-integral (or at least floating point) information? And how does tiering make those possible where non-tiering would not? (Note: Please answer this; it's not a rhetorical question.)

[Aside: Ah, I see you actually have 3 modifiers per mod: an addition, a multiplication, and a trigger (the results of which are added). I've been thinking of things as solely having a trigger value, though hoisting the addition/multiplication for trivial needs makes things simpler for most cases. However it does leave out the possibility of the trigger producing a multiplier that can apply only to totals that have not had multipliers applied, unless your tiers are explicitly separated between additive and multiplicative mods, which isn't something you can guarantee based on the code alone.]


EG: Time of day affects a vampire's strength. Ok, then maybe something like, every hour after dusk, til midnight, the str modifier increases by a non-linear amount (eg: +1 str, +3 str, +6 str, +10 str, +15 str, +25 str). You need to figure out the time of day, and the difference in time, maybe a lookup table, etc, but ultimately it all feeds back into a modification to str, which will only ever be an addition or multiplication (or maybe theoretically log or exponent, though those can largely be reduced to multiplications). That is, the final result of the StatMod function can only perform a simple value manipulation of the stat; you'll never modify the stat by the time itself because the combinations of those two values doesn't make sense (different units, can't combine).

Regardless, you'll never be returning a time value, or a distance value, or whatever. A function may need to know the distance from leader as a parameter, but it must eventually return an actual value that needs to be combined with the base value (eg: morale). None of that oddball stuff is a stat or stat mod, unless maybe you want to allow for dimensional-altering spells that change the distances between any two points (look up a pdf on hyperbolic space-time curvature as it relates to the Cthulhu Mythos for some fun reading). Even then, though, the alteration to the distance must still give you a value that you can use as a parameter, which means it itself is still subject to the same basic mathematical manipulations.


Quote:
Pyrel's guiding principle for design is "If I can imagine use cases I might reasonably implement that require this feature, then it should be implemented." I'm not going to try to stretch the design to do everything under the sun -- it'd never be done, that way -- but I can easily imagine wanting to have complex stat modifier interactions. Stats form such a key part of the game; that makes them a good place to look to if you want to add interesting decisions.
I can absolutely agree with the general principal espoused here. What I disagree with is whether the tiering implementation actually serves that goal.

Basically, I cannot think of any sort of stat manipulation that cannot be expressed as either [stat += StatMod()] or [stat += stat * StatMod()] (though the aformentioned hyperbolic space-time might be a little tricky). Now, StatMod() itself can do all kinds of funky stuff, but that's completely isolated from the ultimate adjustment to the stat (at the level where tiers are in play), and any other stats that StatMod() references must themselves be constrained by those same limits.

The point of using tiers was so that you could be certain that if you needed information about a stat to make a calculation within a StatMod(), then that stat was completely calculated before attempting to use it. However recursion restriction gives you exactly that already. You just can't have a StatMod() that modifies itself, which is the same restriction that is required when using tiers.

So it doesn't seem that you *gain* anything with tiers except extra complexity.


Now, all that said, can I think of any way to make use of tiers that could not be done without them?

1) An effect (eg: pylon in the dungeon) that amplifies magical bonuses. In other words, it doesn't increase base stats, but instead gives a +50% potency to any magical enhancements. So if you had a +10 str spell on you, this would make it a +15 str spell, but a +10 str ring would stay +10.

Counterargument: The tiers wouldn't explicitly allow for this anyway. A modification at a higher level than temp effects would still also apply to every tier below it, so this bonus would affect gear and base stats as well. Instead you'd need a query that gave you all the current temporary effect bonuses. At that point you can take 50% of that value and return it to be added to the stat, but then tiers become irrelevant, as the query would be of a certain 'type' of StatMod.

One could, perhaps, have a modifier that explicitly applies to each effect itself (and thus could apply to only temporary effect), but it would be difficult to have a common reference that would be universally workable, and it would require each effect to be aware of the possibility and code that into its own inner workings. Seems fragile.


2) Same thing, but only affecting base stats, not gear or temp effects. In that case tiering works. However this is really just a special case of the general desire to "affect only the stats on a particular tier" (and fails on any except the lowest tier), which can just as easily be described as "affect only the stat mods of this 'type'" (which would work for any defined type, even if those types are effectively just tiers, if such a query was available).


3) An effect that requires a minimum value before a bonus is given, and that excludes a certain class of other bonuses (eg: no magic bonuses, or no gear). In that case, tiering would work better because you want to exclude a set of bonuses, which means you need to have knowledge of all possible bonus types except the one you want to exclude if you wanted to use the query method (though it wouldn't be too difficult to instead say "get All mods; remove type 'x' mods from this list").


4) Vampire at night gets a 50% bonus to all gear mods, one of which is a ring that increases Int based on Magic Device Skill (which itself depends on Int). So now, what's the value of Int?

Tiered: can't get just all gear effects, but assuming we take all effects underneath 'temporary' (thus, base+gear) the 50% multiplier is straightforward, if not exactly what we wanted. However the ring just won't work because of the tiering -- either MDS is above Int, or Int is above MDS, and can't have both at the same time.

Non-tiered: Query for all gear effects means that aspect is simple. Ring requires MDS, which requires Int, which requires both the ring and the Vampire bonus. Recursion block means that MDS is calculated without the ring's Int bonus, but with the Vampire bonus for the remaining gear. After that the ring bonus is returned, and the Vampire bonus is calculated again on -all- of the gear. Leads to a lot of duplicate calls, which could be mildly annoying if this were to occur on, say, Searching, where you're likely to repeat the call very frequently, and had lots of effects with complicated computations. However it gives us a consistent, 'mostly' correct answer every time.



aside #2) My redirection of everything to a query of type is in large part simply a renaming of the existing 'tier' value -- you still need some means of isolating classes of mods, and just because I say tiers aren't necessary doesn't mean that part of their potential use isn't necessary. However a query on type has freedom to choose any arbitrary mod class at any given time, whereas tiers can necessarily only know about lower tiers (unless you keep adding higher tiers, but then you run into the "turtles all the way down" problem).



aside #3) I left it out of my earlier post to try to keep things simple, but wanted to be clear about the issue of inconsistent values.

Any time you combine multiplied values in a tiered system, you necessarily introduce the possibility that adding exactly the same two stat mods can give different results, simply due to the fact that they are applied on different tiers. EG:

Base str: 100

Ring +10 str & Ring +20% str = 130 str (due to them being on the same tier)
Ring +20% str & Spell +10 str = 130 str
Ring +10 str & Spell +20% str = 132 str !

Also:
Ring +20% str & Ring +20% str = 140 str
Spell +20% str & Spell +20% str = 140 str
Ring +20% str & Spell +20% str = 144 str !

This inconsistency may eventually lead to issues with difficulty in balancing the game, or potential exploits due to spell/gear combinations that yield values outside expectations.


If I'm significantly misreading the behavior of the code, let me know.
Kinematics is offline   Reply With Quote
Old February 20, 2013, 15:44   #46
fizzix
Prophet
 
Join Date: Aug 2009
Location: Madison, Wisconsin, US
Posts: 3,002
fizzix is on a distinguished road
Ah the great fuzzy space where simplicity runs up into possibility. I'm a fan of simplicity even if it presents access to some possibilities. Now, I think Derakon's opinion is that it's fine for the game designer to impose such restrictions, but the engine need not do that. And I guess that's ok, but you then do run into the problem of an engine being forced to support all sorts of crazy schemes, many of which, no sane designer should ever choose (i.e. circular dependencies.)

I'm also a little behind on the discussion, so I can't remember whether these things have already been said. Anyway.

All stats can support the following modifiers.

Addition to base stat.
Multiplication to base stat + additions to 1
Addition to stat.

Obviously adding to the base stat is the most important, and that's probably what you'd get with potions. Your final result would be,

(STR + base stat mod) * multiplicative mod + stat addition.

For derived stats it works the same except the initial value is derived from the top tier stats, and then all the base modifiers.

The only difficulty is that the player needs to understand the difference between base modifiers and normal modifiers. If that seems like a subtlety you don't want to require, it's easy to change by forcing all modifiers to be either base modifiers or post-multiplication modifiers.
fizzix is offline   Reply With Quote
Old February 20, 2013, 18:07   #47
Kinematics
Apprentice
 
Join Date: Feb 2013
Posts: 71
Kinematics is on a distinguished road
Ah, ok. fizzix shows two additional use cases for me.


Case 5) A temporary effect that increases a stat by 20%, but only base and gear totals; it doesn't modify or get modified by other temporary effects. This would be well-suited for a tiered system.

Case 6) A temporary effect that increases a stat by a fixed value (eg: str +10), but that isn't affected by other multipliers (either in gear or other temporary effects). This would also be very well suited for a tiered system.

Each of those could be done with a non-tiered queryable system, but it would be a bit of extra work (sort of like the extra work you described for handling my example). The value of the tiering would be in being able to prevent certain types of mods from affecting each other.

The next implied question would be, is the default use case to want to prevent certain mods from affecting each other, or is the default use case that all mods should be treated equally? For either choice, doing the other will be a bit more work, so which approach will likely be less extra work for the majority of designs?


So tiering would allow for

(A + b) * c + d

or even

((A + b) * c + d) * e + f

and so forth.


What I was suggesting would only (by default) allow for

(A + b) * c



So, for example, the Vampire bonus -- supposing its intended design is that the nighttime bonus a vampire gets is outside of any multipliers gear might provide. Having a ring of +20% str would not increase a nighttime bonus from +10 to +12. -That- makes sense for a tiering system.

The primary sticking point still seems to be the multipliers, though. Should multipliers affect values on the same tier, or only tiers below? (Also: can a trigger call produce a multiplier instead of an add? Probably doesn't need to, though, since it's given curVal as a parameter, which -should- include the total from all lower tiers (aside from the possible bug), so any multiplication can be done internally.)

As long as you can define a mod's tier per item/effect/etc, then the designer can enforce a particular type of ordering. Leaving it as is, with multiplies only affecting tiers below, simply means you need to segregate tiers in the same way. If you simply make all adds Type 1 by default, and all multiplies Type 2 by default, then most operations would proceed normally. You could also add a vampire bonus that's Type 2, and thus outside most normal multipliers.


Ok, tiering as a means of restricting circular references didn't make sense, but tiering as a means of ordering arithmatic operations does.

I think the ability to query for mod types (separate from tier name) would still be useful (eg: affect all temporary buffs on tier 1; double all racial bonuses; etc). And the handling of recursive blocking could still be done such that you don't need to enforce a dependency chain.
Kinematics is offline   Reply With Quote
Old February 20, 2013, 18:26   #48
fizzix
Prophet
 
Join Date: Aug 2009
Location: Madison, Wisconsin, US
Posts: 3,002
fizzix is on a distinguished road
Quote:
Originally Posted by Kinematics View Post
Ok, tiering as a means of restricting circular references didn't make sense, but tiering as a means of ordering arithmatic operations does.
These seem to be equivalent to me. Is that what you're trying to say?

When I'm thinking of stat systems, the one thing I'm looking at is game balance. Game balance is much easier if you only have additive values. However, you can get much richer results with both additive and multiplicative bonuses. Unfortunately this makes calculations harder for the game-player as well.

Of course pyrel should support both. But the worry is somewhat mitigated by the fact that these are so damn hard to get right from the design perspective that most designers are likely to only choose additive values.
fizzix is offline   Reply With Quote
Old February 20, 2013, 18:40   #49
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 8,920
Derakon is on a distinguished road
Quote:
Originally Posted by Kinematics View Post
The primary sticking point still seems to be the multipliers, though. Should multipliers affect values on the same tier, or only tiers below?
As written, a given tier can only consider tiers of strictly lower value when calculating itself, since otherwise circular dependencies can result (assuming you don't use some other method to avoid them). As you noted, you can always just stick multiplier mods on a higher tier than additive mods.

For what it's worth, the only reason that additive and multiplier mods exist as separate things from proc-based mods is because I expect that they will be the profound majority of modifiers in the game, to the extent that it's worth having some "syntactic sugar" to support them. You could do everything through Procs, but it would make the data files needlessly wordy. My expectation is that each StatMod instance will only do one of add, multiply, or "trigger" (as you put it).

Quote:
(Also: can a trigger call produce a multiplier instead of an add? Probably doesn't need to, though, since it's given curVal as a parameter, which -should- include the total from all lower tiers (aside from the possible bug), so any multiplication can be done internally.)
Exactly. If you want to produce a multiplier in a proc, then you just calculate what the additive effect of the multiplier would be, and return that instead. Ultimately all stat mods are additive; there's just different rules for how the addition is performed.

Quote:
I think the ability to query for mod types (separate from tier name) would still be useful (eg: affect all temporary buffs on tier 1; double all racial bonuses; etc).
I could see that being potentially helpful, yes. It could be done by having the Stats instance maintain a mapping of categories to lists of stat modifiers. Of course now every stat must have a descriptive category attached to it in addition to a tier, or else the lookup table is useless. But if you're going to co-opt the tiering system to categorize modifiers then you might as well use strings anyway.

I guess my bottom line on all of this is that I'm a bit tired of working on stats (I'm also a bit tired, period -- I didn't sleep well last night). If someone is willing to take on the work to implement a better system (and can convince me that it's truly better) then they're welcome to do so, but I'm not about to tackle it myself; I have bigger fish to fry.
Derakon is offline   Reply With Quote
Old February 21, 2013, 00:59   #50
Kinematics
Apprentice
 
Join Date: Feb 2013
Posts: 71
Kinematics is on a distinguished road
Quote:
Originally Posted by fizzix View Post
Quote:
Originally Posted by Kinematics
Ok, tiering as a means of restricting circular references didn't make sense, but tiering as a means of ordering arithmatic operations does.
These seem to be equivalent to me. Is that what you're trying to say?
No, they're not equivalent. Ordering operations is whether 1 + 2 * 3 is equal to 7 or 9; essentially, the ability to add parentheses to the calculations. Circular references is an algorithmic issue separate of that. Ordering can influence circular references, but circular references have no bearing on arithmatic order.


Quote:
Originally Posted by Derakon
For what it's worth, the only reason that additive and multiplier mods exist as separate things from proc-based mods is because I expect that they will be the profound majority of modifiers in the game, to the extent that it's worth having some "syntactic sugar" to support them. You could do everything through Procs, but it would make the data files needlessly wordy. My expectation is that each StatMod instance will only do one of add, multiply, or "trigger" (as you put it).
Yep, makes sense.

Quote:
I could see that being potentially helpful, yes. It could be done by having the Stats instance maintain a mapping of categories to lists of stat modifiers. Of course now every stat must have a descriptive category attached to it in addition to a tier**, or else the lookup table is useless. But if you're going to co-opt the tiering system to categorize modifiers then you might as well use strings anyway.
** Do you mean stat mod? (though yes, each one would need both a tier and a category)

EG: A ring of +10 Str and a ring of +20% str can have different tiers, correct? They're not forced to the same tier simply because both work on Str, or both are permanent effects, right?

Though going back to your earlier example, it seems like you are still binding tiers to stats, which is why you'd have to create an entire duplicate set of stats to handle multiplication.

If tiers are bound to mods, the filtering is trivial; just perform a list comprehension/filter on a given stat's collection of mods. However if tiers are bound to stats, you'd have to get not only the stat you're working on, but all variants on that stat that were created to handle the artificial tiering.



As an aside, I finally got the whole python environment installed and working, so I'll be able to play around with things a bit more directly, as I have time.
Kinematics is offline   Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Pyrel dungeon generation fizzix Variants 50 December 7, 2012 01:32
Pyrel dev log, part 3 Derakon Variants 108 November 12, 2012 23:30
Affixes in Pyrel Magnate Development 0 October 13, 2012 13:53
Pyrel dev log, part 2 Derakon Variants 126 September 11, 2012 23:03
Pyrel dev log Derakon Variants 64 June 8, 2012 11:58


All times are GMT +1. The time now is 00:04.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.