Pyrel dev log, part 5

Collapse
X
 
  • Time
  • Show
Clear All
new posts

  • Derakon
    replied
    I've just pushed an initial version of monster memory to the repo. When you hit the '/' key, the game prompts you for creature name, and then searches for a monster with that name. If it can't find one, then it finds the best matches it can and asks you to pick one:



    Then it brings up information on the creature:



    This is based on the monster memory mockup I made awhile back. It's not complete -- most obviously, I don't have spell information up yet because no monsters have spells yet (they need to be copied over from the old data files), but also I have rather anemic drop information (I spent basically zero time on figuring out how to describe LootTemplates), and the melee descriptors look kind of weird. But the basic principle is sound.

    Leave a comment:


  • LostTemplar
    replied
    Finesse and prowess are already main combat stats, so crits, based on them basically adds nothing. Crits may be a good way to make something else to contribute to combat ability. E.g. crits depending on intellect or perception may be fun.

    Leave a comment:


  • Derakon
    replied
    Hm, I was trying to think of a bonus for using the unbiased weapons, since they'll otherwise be strictly inferior for most classes (since their stats will be heavily biased towards either finesse or prowess). But I suspect you're right. The better way to make unbiased weapons more attractive is probably to have the sum of their balance and heft exceed 1. So a Longsword might be a .6/.5 weapon instead of .55/.45, say.

    As for frequency of crits, remember that prowess characters already get very few attacks compared to finesse characters. I think crit frequency and the effects of crits on damage should be the same for both character types. If 10% of your blows do 2x damage, then the finesse character will see regular crits that have a small effect on their total damage while the prowess character will occasionally completely destroy their target with a single blow, and that sounds fine by me.

    Leave a comment:


  • Magnate
    replied
    Originally posted by Derakon
    IIRC the one in v4 ended up meaning that no attacks early on were crits, while every attack later was a crit. Not quite that bad, but the scaling was way off, and I don't think it was fixable (it used something like "if finesse * balance > X, or prowess * heft > Y").

    Also, supercharge systems for crits just plain make sense.
    Yes, I was thinking of the supercharge mechanic in v4, rather than the crit threshold. But while we're on the threshold, I think you have it backwards - I think balanced weapons should critical very rarely, the whole point being that they deliver smooth, steady damage for pretty much any build. Extreme finesse weapons should deliver *lots* of little crits, and extreme prowess weapons should deliver a lower number of vastly bigger crits. That, to me, is the sense of the fin/prow system.

    Leave a comment:


  • Derakon
    replied
    IIRC the one in v4 ended up meaning that no attacks early on were crits, while every attack later was a crit. Not quite that bad, but the scaling was way off, and I don't think it was fixable (it used something like "if finesse * balance > X, or prowess * heft > Y").

    Also, supercharge systems for crits just plain make sense.

    Leave a comment:


  • Magnate
    replied
    Wow - progress! Why did you decide to change the crit system from the one in v4?

    Leave a comment:


  • Derakon
    replied
    They also have those attributes, just like a monster could be a natural evil troll or something.

    I've implemented melee combat for the player. It uses the finesse/prowess system originally implemented in v4. In short, this means:

    * The player has finesse and prowess instead of to-hit and to-dam.
    * Weapons have balance and heft (typically these two values sum to 1)
    * # blows = 1 + balance * finesse / 10
    * Damage multiplier = 1 + heft * prowess / 10
    * Base damage = roll of damage dice per blow

    Slays add onto the damage multiplier, so e.g. if your base multiplier is 3 and you have a flame brand +2, then your multiplier is 5 vs. monsters not resistant to fire.

    Elemental brands deal their extra damage as elemental damage, and can apply (at reduced strength) to resistance monsters. It is still the case that only the most powerful slay or brand takes effect -- and that takes monster resistances into consideration.

    I've implemented a new system for critical hits. We'll see how it plays. It's a supercharge system; as long as the game can pass a 1 in (2 / (heft * prowess)) check, your damage multiplier is increased by 1. For a .5/.5 weapon, the odds of getting a level-1 crit are 1 in 8; for a .25/.75 weapon they're 1 in 10. So "unbiased" weapons tend to get more and better crits, while badly biased weapons get few and worse crits. This doesn't really scale at all through the game though, so crits won't have as much of an impact on endgame damage as they do in Vanilla. I'm not entirely certain about this system. I could change it so that crits multiply the multiplier instead of adding to it; functionally this means that a level-1 crit doubles damage, level-2 triples, etc.

    Messages have been consolidated:
    Code:
    You attack the Filthy street urchin (10) [smite 10]
    You attack the Yellow mold (9) [hit 6, hit 3]
    You attack the Yellow mold (11) [hit! 7, hit 3]
    You attack the Filthy street urchin (14) [miss, burn 14]
    Exclamation points indicate critical hits; the more exclamation points, the better the crit.

    Incidentally, you might think that that "smite" message means I was using a weapon of Slay Evil. Not so! One of the daggers in Debug Town is a Dagger of Slay Townsfolk.

    I regret nothing.

    EDIT: went ahead and changed it to 1.5 / (heft * balance), which means about a 1 in 6 chance for unbiased weapons to 1 in 16 for maximally-biased (.1/.9 split). Also changed it so crit multipliers apply after all other multipliers, so a level-1 crit doubles damage, level-2 triples, etc.
    Last edited by Derakon; May 24, 2013, 06:17.

    Leave a comment:


  • ekolis
    replied
    Why are players a race unto themselves? Shouldn't that be slay human, or slay half-orc, or slay kobold, or whatever race the player actually is?

    Leave a comment:


  • Derakon
    replied
    I started work on implementing proper melee combat -- shouldn't be too hard -- and came to a realization: because the player is now Just Another Creature, a lot of rules that were specific to the player now apply to creatures as well. Most relevantly, items carried by creatures are now subject to being destroyed by elemental attacks (and if creatures were smart enough to equip items, then they could be damaged by acid and disenchantment too).

    I don't know how much of an effect this will have on overall loot availability, but it will mean that mages see fewer items than before, since most of their early attacks are elemental. I suppose there's some interesting tradeoffs here -- want that potion that monster is carrying? Don't use cold attacks on it! -- but handling them properly would require much better messaging of what is in a given monster's inventory.

    Also, my plan for weapons that have slays is to allow slays on any creature category. The player is a creature category. There could (potentially) be weapons of Slay Player.
    Code:
    Lorgan, Chief of the Easterlings smites you. -more-

    Leave a comment:


  • LostTemplar
    replied
    Nice, it now works.

    Leave a comment:


  • Derakon
    replied
    I should clarify: animations were broken; I did the necessary work to fix them (though I haven't verified explosions yet). I also did the work to make the character status sidebar display properly; right now I'm dithering about how much work I want to spend on making things look pretty.

    In general I think we should only have one of the WX or Qt frontends be fully-supported, since they do the same thing (provide a windowed experience). Spending the work on supporting both is silly. Personally I find WX easier to deal with, in part due to experience and in part because of the amount of pain I went through in installing PyQt, but I understand others may feel differently.

    cursesPyrel has gotten zero attention from me thus far, sorry!

    EDIT: pushed my QtPyrel fixes to the repo.
    Last edited by Derakon; May 23, 2013, 19:14.

    Leave a comment:


  • LostTemplar
    replied
    Nice, so it is only my problem.

    Leave a comment:


  • Derakon
    replied
    I finally managed to get Qt installed on my laptop, so I've started working on this. Animations are working okay; right now I'm trying to figure out why text rendering is screwy, though. QtPyrel's writeString() function isn't monospaced, which makes the sidebar and inventory display a bit screwy; however, turning it off makes things look really ugly. Compare:

    Non-monospaced: sidebar, inventory

    Monospaced: sidebar, inventory.

    (That last image was taken after inflating the character dimensions by 1 pixel in X and Y, which is why it's bigger)

    I should note that I don't particularly enjoy working on frontend display stuff, and I'm by far most familiar with the WX frontend (and with WX in general), which is why Qt and curses haven't been getting much attention from me.

    Leave a comment:


  • LostTemplar
    replied
    Hmm, about curses code I cannot understand why it doesn't work.

    However in QT code there were broken link to receiveAnimation, so it were never called, if fixed it starts working allmost. It still shows animation at wrong place (offset from corner of the window, not map) and at wrong time (explosion first, then flying projectile. Maybe due to multiple threaded execution)

    Leave a comment:


  • Derakon
    replied
    Sorry about that; I may have accidentally broken it with recent changes that fixed some lack of thread safety issues. Or it may be that they've never worked properly. I haven't managed to successfully install PyQt4, and I've not yet gotten around to installing the curses libraries either, so my ability to test is necessarily limited.

    I'd suggest comparing the receiveAnimation functions in the respective front-ends; the wxPyrel version should be definitive.

    Leave a comment:

Working...
😀
😂
🥰
😘
🤢
😎
😞
😡
👍
👎