Pyrel dev log, part 2

[Magnate]

You could even go with spells that take varying amounts of time to cast

I implemented this a way back in the 3.1 series - spells now take 100 + slev - clev energy to cast. So a cl50 mage casting magic missile takes 51 energy ...

[ekolis]

Oh, cool, never noticed that before!

edit: wait, 100 + slev - clev? And a move or attack takes 1000 energy, right? Somehow I considered spellcasting to be MORE time consuming than moving and attacking... And you can't cast spells with slev > clev, so even if moving/attacking costs 100 energy, you'll never cast a spell that takes longer...

[LostTemplar]

Moving is 100. Btw same feature was in FAangband for ages, called 'fast casting' specialty, and it caps at no less then 50 energy too.

[Derakon]

Basically, for every level you have beyond the minimum level to cast the spell, casting takes 1% less time.

One thing that I need to contemplate for Pyrel is how to keep the player informed about these mechanics. They're really important for planning out your combat but they also aren't very well messaged at all.

[ekolis]

Have a speed indicator (or energy cost indicator) for each general "speed type" (movement, fighting, shooting, and spellcasting sounds like a good set), then give each weapon/spell a speed modifier (or delay factor) that is displayed with that weapon or spell?

e.g. (the numbers in parentheses are "base" values; the numbers outside parentheses for fighting and shooting take into account current weapons)

PLAYER SPEED
Movement: 120%
Fighting: 99% (90%)
Shooting: 72% (80%)
Spellcasting: 110%

EQUIPMENT
(a) (wielding) a Longsword (2d5) (+2, +1) <110%>
(b) (shooting) a Short Bow (x2) (+0, +0) <90%>
...

SPELLS
(a) (1 mp) Magic Missile (3d4) <165% (150%)>
(b) (6 mp) Fire Bolt (4d6) <110% (100%)>
(c) (24 mp) Explosion (6d9) <66% (60%)>
...

[Derakon]

Okay, basic support for a proper speed system is in place. At the moment, each Command has a hardcoded energy cost (so e.g. looking around costs no energy), and each creature's speed valid is properly heeded. In the future it ought to be straightforward to have separate base speeds and modifiers for various categories of commands, so the Command can derive its energy cost based on the stats of the subject it's being performed by.

Incidentally, this reminds me of an idea I had -- make looking around require energy. The theory being that the stuff the player can see in the normal view window doesn't require any special effort to see, but if you want to check on what kind of dragon that is, or how much health it has, or what's under that suit of armor in that pile of items, then you'll need a more careful examination, which takes (some small amount of) time. I doubt I'd actually implement this though.

Also, for future reference, Pyrel is multithreaded so that Commands can generate and resolve Prompts without having to sacrifice their current execution context. Even this relatively simple level of multithreading has resulted in some hard-to-debug problems. I've done some code tweaks to make the threading more explicit (at the cost of it being slightly more verbose and repetitive), but just remember, if you dive into this section, that it's easy to get tripped up by threads and they can be tricky to debug.

Just for example, I had this code:

    print "Adjusted subject's energy from",self.subject.energy,
    self.subject.energy -= self.energyCost
    print "to",self.subject.energy,"based on",self.energyCost

Guess what it printed?

Adjusted subject's energy from 1.0 to 1.0 based on 1.0

[buzzkill]

Incidentally, this reminds me of an idea I had -- make looking around require energy. The theory being that the stuff the player can see in the normal view window doesn't require any special effort to see, but if you want to check on what kind of dragon that is, or how much health it has, or what's under that suit of armor in that pile of items, then you'll need a more careful examination, which takes (some small amount of) time. I doubt I'd actually implement this though.

Rather that costing time, it could cause a cumulative short term perception penalty, as you are focusing on things not in your immediate area. Chronic scanning of the greater dungeon could cause you to miss traps and secret doors right in front of your nose.

[mtadd]

Also, for future reference, Pyrel is multithreaded so that Commands can generate and resolve Prompts without having to sacrifice their current execution context. Even this relatively simple level of multithreading has resulted in some hard-to-debug problems. I've done some code tweaks to make the threading more explicit (at the cost of it being slightly more verbose and repetitive), but just remember, if you dive into this section, that it's easy to get tripped up by threads and they can be tricky to debug.

I started working on a curses GUI implementation, but hit the snafu in the command execution code due to the multithreading issue. It certainly is necessary to maintain separate execution contexts for the command and ui execution paths, but instead of multithreading, I suggest looking into using the coroutine functionality in Python (available since v2.5). I'm working on a patch now, but you can familiarize yourself with the basics at the following link, and perhaps give it a try yourself:

PEP 342 -- Coroutines via Enhanced Generators

Edit: I sent a pull request to your bitbucket repo with a patch demonstrating this technique.

[Derakon]

Apologies for the lack of recent updates, and for leaving mtadd's coroutine pull request in limbo. Two things are going on: first, I have a major refactoring and code cleanup project at work, which is sucking up most of my spare programming brainpower. Second, I rediscovered videogames, which is sucking up most of my spare time.

(In specific, I'm currently playing Muramasa: The Demon Blade, which feels rather like Devil May Cry in two dimensions, and as of about 4-5 hours in is still quite fun)

Anyway, that explains what's happened to Pyrel development. In any event, even if I did have the time and brainpower to devote to Pyrel, I'm honestly not certain what I would tackle next (aside from the aforementioned pull request). I'm sure there are still "framework-level" (i.e. needed before gameplay can be implemented) problems to tackle, but I don't know what they are. Well, aside from various utility functionality, like missile projection, pathfinding, or, uh...message formatting?

If it wasn't clear before, by the way, I'm desperately hoping that once the Pyrel "game engine" is ready to go, other people will handle getting most of the content working. If only because there's a heck of a lot of it and it should be readily amenable to parallelized efforts.

[ekolis]

I was actually working on message formatting the other day - well, not so much message formatting as just making the %^&* stupid text box fill the message window! Apparently layout is not one of wxPython's strong points...

[Derakon]

It should do that automatically. The MessageFrame window specified in gui/wxPyrel/messageFrame.py creates a ScrolledWindow as its only child, which means that child automatically fills the frame; then a multiline TextCtrl is created as the child of the ScrolledWindow, with the same result -- automatic resizing.

Maybe size events aren't getting propagated, like the problem with propagating keydown events that you handled earlier? What exactly is the behavior you're seeing?

[ekolis]

The panel containing the text box is wide enough to display a few words, and about 2 lines tall... it does not resize with the window at all!

[Derakon]

Try this test app out:

import wx
import random
import threading
import time

class App(wx.App):
    def OnInit(self):
        frame = wx.Frame(parent = None, title = "Scrolling text test")
        panel = wx.ScrolledWindow(parent = frame)
        self.text = wx.TextCtrl(parent = panel, style = wx.TE_MULTILINE)
        frame.Show()
        threading.Thread(target = self.updater).start()
        return True
    def updater(self):
        while True:
            text = []
            for i in xrange(random.randint(4, 10)):
                chars = ''.join([chr(random.randint(65, 90)) for j in xrange(random.randint(4, 16))])
                text.append(chars)
            text = ' '.join(text)
            self.text.SetValue("%s\n%s" % (self.text.GetValue(), text))
            time.sleep(1)
app = App(redirect = False)
app.MainLoop()

It may complain because you're updating the UI in a non-main thread, but it should still work -- it'll make a window just like the MessageFrame does, and then fill it with randomly-generated content.

[Nick]

1. Start Python game engine
2. ???
3. Profit!!

If it wasn't clear before, by the way, I'm desperately hoping that once the Pyrel "game engine" is ready to go, other people will handle getting most of the content working. If only because there's a heck of a lot of it and it should be readily amenable to parallelized efforts.

Yep, I think that fits nicely

[ekolis]

Nope, the text box is still tiny in the test app