Angband.oook.cz
Angband.oook.cz
AboutVariantsLadderForumCompetitionComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Variants

Reply
 
Thread Tools Display Modes
Old September 11, 2012, 22:02   #1
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 8,946
Derakon is on a distinguished road
Pyrel dev log, part 3

I've thrown together a to-do list based on my previous post, and put it on the wiki. It's pretty rough but it should give some idea of what important stuff still remains to be done.

Uh...not much else besides that. I think my priorities for the moment should be on enabling as many effects and procs as possible -- porting in all of the effects from Angband itself is a huge task, but fortunately one that can be broken down into hundreds of smaller tasks. In other words, it's an ideal way for people to get their feet wet with Pyrel development.
Derakon is offline   Reply With Quote
Old September 12, 2012, 02:24   #2
ekolis
Knight
 
ekolis's Avatar
 
Join Date: Apr 2007
Location: Cincinnati, OH, USA
Age: 36
Posts: 911
ekolis is on a distinguished road
Send a message via AIM to ekolis Send a message via MSN to ekolis Send a message via Yahoo to ekolis
Regarding character generation, there's no reason to have to create a new character every time you start the game just because there's no way to save the game - you could implement saving just for character objects first!
__________________
You read the scroll labeled NOBIMUS UPSCOTI...
You are surrounded by a stasis field!
The tengu tries to teleport, but fails!
ekolis is offline   Reply With Quote
Old September 12, 2012, 02:33   #3
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 8,946
Derakon is on a distinguished road
Any amount of save/load implementation has to have a fairly significant framework built up first if it's to be done properly. Kind of like how you can't implement spells without having a lot of the effects framework done first -- you can't say "Oh, just implement the spells and leave the rest for later" because you aren't actually saving yourself all that much work.

EDIT: Ekolis's pretty-item-names patch is finally in! And I've also uploaded the first pass at animations. You can throw any item in your inventory to see an animation of it traveling -- it won't actually be thrown, but seeing as combat is basically nonexistent right now I consider that to be a relatively minor problem.

Last edited by Derakon; September 12, 2012 at 07:05.
Derakon is offline   Reply With Quote
Old September 12, 2012, 13:41   #4
ekolis
Knight
 
ekolis's Avatar
 
Join Date: Apr 2007
Location: Cincinnati, OH, USA
Age: 36
Posts: 911
ekolis is on a distinguished road
Send a message via AIM to ekolis Send a message via MSN to ekolis Send a message via Yahoo to ekolis
Well, you could just hack something together with pickle and not worry about versioning...
__________________
You read the scroll labeled NOBIMUS UPSCOTI...
You are surrounded by a stasis field!
The tengu tries to teleport, but fails!
ekolis is offline   Reply With Quote
Old September 13, 2012, 05:21   #5
AnonymousHero
Veteran
 
AnonymousHero's Avatar
 
Join Date: Jun 2007
Posts: 1,367
AnonymousHero is on a distinguished road
You should seriously consider adding automated testing at this point -- I can recommend mock-based testing as that tends to be easiest for developing + testing small bits in isolation. Retrofitting automated tests after all the code is written can be a seriously large undertaking... which means that people don't tend to do it... which means that (esp. in a dynamically type checked language) you'll start to instability start to creep in, getting worse and worse over time.

Having a "standard" way to do tests would probably help contributors out a lot too.
AnonymousHero is offline   Reply With Quote
Old September 13, 2012, 16:22   #6
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 8,946
Derakon is on a distinguished road
I'll be honest, writing tests is not my favorite thing to do in the world, so I'm less than enthusiastic about this. At the same time, I do recognize that tests have value, and you're right, it's easier to get them in sooner rather than later.

That said, they should probably wait until save/load is implemented at least; it'll be far easier to test different scenarios if you can just load an associated savefile that does your setup, rather than having to manually construct all the different objects you want at the start of the test.

So I guess save/load is the next bit I get to tackle.
Derakon is offline   Reply With Quote
Old September 13, 2012, 17:58   #7
Magnate
Angband Devteam member
 
Join Date: May 2007
Location: London, UK
Posts: 5,057
Magnate is on a distinguished road
Send a message via MSN to Magnate Send a message via Yahoo to Magnate
Quote:
Originally Posted by Derakon View Post
I'll be honest, writing tests is not my favorite thing to do in the world, so I'm less than enthusiastic about this. At the same time, I do recognize that tests have value, and you're right, it's easier to get them in sooner rather than later.

That said, they should probably wait until save/load is implemented at least; it'll be far easier to test different scenarios if you can just load an associated savefile that does your setup, rather than having to manually construct all the different objects you want at the start of the test.

So I guess save/load is the next bit I get to tackle.
I'd be willing to tackle tests, if I can get sufficiently up to speed with Python. Will contact you on IRC.
__________________
"3.4 is much better than 3.1, 3.2 or 3.3. It still is easier than 3.0.9, but it is more convenient to play without being ridiculously easy, so it is my new favorite of the versions." - Timo Pietila
Magnate is offline   Reply With Quote
Old September 13, 2012, 20:54   #8
AnonymousHero
Veteran
 
AnonymousHero's Avatar
 
Join Date: Jun 2007
Posts: 1,367
AnonymousHero is on a distinguished road
Quote:
Originally Posted by Derakon View Post
I'll be honest, writing tests is not my favorite thing to do in the world, so I'm less than enthusiastic about this. At the same time, I do recognize that tests have value, and you're right, it's easier to get them in sooner rather than later.

That said, they should probably wait until save/load is implemented at least; it'll be far easier to test different scenarios if you can just load an associated savefile that does your setup, rather than having to manually construct all the different objects you want at the start of the test.

So I guess save/load is the next bit I get to tackle.
Actually, with mock-based testing you can avoid this. Instead of having some sort of large corpus of specially defined loadable test-data, you instead (in each individual test) provide mocks for all dependencies (including data) of the functionality you're testing. (It's kind of hard to explain, the wiki page does a better job!)

The great thing about mock-based testing is that you can tame the combinatorial explosion that often occurs when you're testing full systems using "real" data.
AnonymousHero is offline   Reply With Quote
Old September 18, 2012, 03:01   #9
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 8,946
Derakon is on a distinguished road
As you may have noticed, Pyrel development's slowed down these last couple of weeks. Work suddenly gave me some interesting new problems to tackle, and they've been sucking up all of my spare "programmer time" -- it's not that I'm working longer hours, it's that I don't have the brain to devote to Pyrel when I get home. Hell, I tried to play board games last Friday and frankly was an embarrassment.

Still, I wasted away the weekend playing FTL when I could have been getting useful things done, so there's some missed opportunities there.

Anyway, I need to set my subconscious loose on some problems at work, so let's talk about where Pyrel should go next.

What I think really needs to be worked on isn't so much saving and loading as it is a fully-fleshed out player character. That would be a big enabler for all sorts of subsystems, which would in turn help unblock Pyrel development from requiring my personal involvement. For example, combat really wants a character with STR and DEX stats, while we want a Magic Devices skill for wands/rods/staves/etc. Traps really want to be able to drain stats. And so on. My concern earlier about having to deal with chargen at the start of every play session can be readily worked around by simply tossing the player into a hardcoded race/class combination -- nobody using Pyrel at this stage should be incapable of changing the combination if they need to.

So what defines a character, then? To over-reduce, characters are collections of summations of numbers. For example, the character's magic device skill is a summation of an INT-based modifier (itself being an "internal" stat plus race, class, and equipment bonuses) plus a class-based multiplier times the character's level, plus a racial modifier. Very few of these values are what I would consider to be innate:

* The aforementioned internal stats.
* Current experience total.
* The base d10 hit die.

Everything else, including racial and class-based bonuses, I think are sufficiently subject to change that they should be treated as modifiers on these base stats (or modifiers on 0 when there's no equivalent base stat, e.g. for skill checks).

So how do we represent this internally? By a list of values, of course. Except that those values may be represented by functions (e.g. multiplying level by the skill gain rate), and might become even more complicated in future. So let's abstract things fully by creating a new class, the StatMod. Each stat is represented by a list of StatMods; the sums of their evaluate() methods provides the actual value to use. We gain several things by this:

* Flexibility. We can replace just about anything about the character with something else and the system will seamlessly adapt. Want to change race? Done. Class? Done.
* Effects can affect stats in cleanly-separable ways. An Effect simply inserts a new StatMod into the sequence while it is active, and removes that StatMod when it is done.
* As a net result, handling equipment bonuses isn't a huge nightmare of special-coding. Equipment bonuses have an onEquip proc to add a StatMod and an onUnequip proc to remove it; done and done.

There are however two caveats to this approach:

* Every time we want to get the value for a stat, we must recalculate it. This cost should be minimal most of the time, but it does gall a bit. Values could be cached, but then I imagine a system where e.g. the value of your magic device skill depends on your proximity to a pylon that's sending out magic-disrupting energy waves. Figuring out when the cache is invalid could be aggravating.

* There's potential for circular dependencies here. For example, an amulet that increases your INT based on your magic device skill seems sensible, but your magic device skill is derived from your INT -- so when you go to calculate it, you have a loop that can never complete. The simple answer is "don't do that then"; more complicated would be to have some way to short-circuit calculations when a loop is detected. But that's significantly more complicated -- we're talking about metaprogramming here, assuming that we want to apply bonuses in a fixed order. And if we don't...

* Percentage increases to the stat have a similar problem. If you have an item that gives you a 10% bonus to your stat, when is that 10% applied? Given that e.g. there's no "base" magic device stat (it starts from 0 every time), you can't just apply it to the base. Are we to prioritize the order in which modifiers are applied?

On a side note, similar logic to the above can and should be applied to items. Currently items have two sets of modifiers: an "innate" set (as applied in the item's own record) and an "effective" set (including bonuses from external factors like Rings of Prowess), and they just assume that everyone will do the math correctly. But if we're going to implement this more flexible StatMod approach for the character, and we should, then doing the same for items seems like a no-brainer.
Derakon is offline   Reply With Quote
Old September 18, 2012, 03:42   #10
fizzix
Prophet
 
Join Date: Aug 2009
Location: Madison, Wisconsin, US
Posts: 3,002
fizzix is on a distinguished road
Quote:
Originally Posted by Derakon View Post

* There's potential for circular dependencies here. For example, an amulet that increases your INT based on your magic device skill seems sensible, but your magic device skill is derived from your INT -- so when you go to calculate it, you have a loop that can never complete. The simple answer is "don't do that then"; more complicated would be to have some way to short-circuit calculations when a loop is detected. But that's significantly more complicated -- we're talking about metaprogramming here, assuming that we want to apply bonuses in a fixed order. And if we don't...
I think a hierarchical dependency tree makes sense. Device skill can depend on INT, but INT cannot depend on device skill. The other option is to hard code a way return if the bonus is less than one. Then provided the bonuses decrease with each call you will exit the loop eventually. I much prefer the first approach.

Basically you have the very top level stuff which are the stats. They get derived from XP, racial bonus, class bonus, equipment, effects. On the second level you have the derived stats. These are stuff like prowess, finesse (or just melee), stealth, magic device skill etc. These can depend on all the stuff that the stats depend on, but also on stats. However, stats cannot depend on each other or on any of the derived stats.

I think this also makes intuitive sense.

Quote:
* Percentage increases to the stat have a similar problem. If you have an item that gives you a 10% bonus to your stat, when is that 10% applied? Given that e.g. there's no "base" magic device stat (it starts from 0 every time), you can't just apply it to the base. Are we to prioritize the order in which modifiers are applied?
This one is much harder. In order for percentages to make sense you need a base to calculate off of. The current approach would rule out percentage based stat modifiers. But maybe that's a sacrifice worth making?
fizzix 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 dev log, part 2 Derakon Variants 126 September 11, 2012 23:03
Pyrel dev log Derakon Variants 64 June 8, 2012 11:58
Play FAangband part II Fendell Orcbane AAR 6 November 29, 2010 21:53
JBand progress log. PaulBlay Development 38 June 27, 2009 10:19
Quill, Part II Sirridan AAR 9 June 25, 2009 04:51


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


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