Pyrel dev log, part 3

[fizzix]

I think we probably need to think about handling nested containers. It's always hugely irritated me when games have arbitrary limitations on this. Yes it's variant territory (you can't put anything inside anything else in V, apart from stuff in the quiver/backpack), but you've already mentioned dealing with bulk (as distinct from weight) in a previous thread so would be good to design it in. I think having volume as the limiting factor is a better determinant than any more arcane rationalisation.

I sort of agree with your last sentence but not necessarily the first. I think we should only really allow nesting 1 deep for item searches. backpack->container->item and no further. If you put a container into another container you have to remove it first to get the items in it.

I think we should also make use of "it doesn't fit" in order to determine what goes where. that should be the error for putting a halberd into your quiver. Or a large chest into a small one.

If I was to redesign inventory from scratch it would probably look very very different. I think it could be supported based on your design outline but I'll describe it anyway and see whether it's worthwhile to be supportable.

Player gets limited inventory slots (probably a lot lower than now) which can only hold single items. There should be an "allow stacking" parameter, the backpack has it disallowed. Slots should be variable throughout the game, you can imagine a cloak that gives you 2 extra inventory slots for example. Each inventory slot can include a single item or a larger container. Examples of containers are "spellbooks", "scroll cases," "wand cases," "quivers," "food sacks," "potion cases" and so on. Quivers would allow stacking as would potion cases (items are indistinguishable), but perhaps not wand cases. There are various different types of cases that offer smaller/larger capacities and elemental protection benefits.

Common commands for interacting with containers are "Put into container," "Remove from container," "Transfer between containers," and "Reorder container." Picking up an item automatically places it into an appropriate container if there is room and if it's the only container option that can accept it. Otherwise it prompts with "which container?" Using an item automatically brings up all items in appropriate containers.

Spellbooks are worth special notice. Spellbooks are blank and the player reads spells into them. Each book has a capacity value and also possibly includes elemental properties. Just like other containers elemental damage may not destroy the entire container but may destroy several spells. (books should provide significantly larger values than currently to account for the players possible desire to include key spells several times.) You put a spell into the spellbook by transcribing it from another spellbook or from a scroll (spellscroll perhaps?). Removing a spell from a book erases it, as does transcribing it into a different spellbook.

[emulord]

For a fun bulk based system try Castle of the winds.

I'd say that bags of holding should be rare, but fairly unrestricted. Maybe count weight but not bulk, so you're still limited by Strength.
Taking something out of a container should take a certain amount of time, with the exception of quickly prepared things, like scabbard, bow, torch, wands in belt (like CotW), etc. Taking something out of a chest out of your backpack should take even more time.

[Derakon]

Clearly there are dozens of possible inventory mechanics that could be implemented. For now I want to focus on re-implementing Angband's system, because Pyrel is after all meant to be Angband, in Python. As I said before I'm not going to hew exactly to it, mostly because a) I want quivers, spellbooks, and chests to all use the same code, and b) I want a flexible UI. But I really think that changing the inventory system too much would cause us to end up with a game that just didn't play like Angband, since so much of the game's tactics relies on what the player has in their backpack.

That said, Fizzix's suggestions would definitely be implementable under Pyrel's current system without much grief; you'd need to make some code changes but they wouldn't be drastic. Adding time costs for interacting with containers (per emulord) would also be a straightforward change. So basically, once Pyrel's done if you want to change the inventory mechanics, you're welcome to do so.

In short, while there's plenty of fun to be had in discussing alternate inventory game mechanics, we should probably do it in a different thread. Inventory discussion here should mostly stay limited to how to implement it code-wise and how to interact with it.

[Magnate]

Clearly there are dozens of possible inventory mechanics that could be implemented. For now I want to focus on re-implementing Angband's system, because Pyrel is after all meant to be Angband, in Python. As I said before I'm not going to hew exactly to it, mostly because a) I want quivers, spellbooks, and chests to all use the same code, and b) I want a flexible UI. But I really think that changing the inventory system too much would cause us to end up with a game that just didn't play like Angband, since so much of the game's tactics relies on what the player has in their backpack.

I love how easily I agree with you. I hadn't realised you had envisaged multiple quivers limited to 40 ammo (but presumably with no type or stacking restrictions so you can have 40 different arrows?), but it doesn't strike me as a heinous change (bearing in mind that the quiver is still a recent and fairly controversial addition to V).

That said, Fizzix's suggestions would definitely be implementable under Pyrel's current system without much grief; you'd need to make some code changes but they wouldn't be drastic. Adding time costs for interacting with containers (per emulord) would also be a straightforward change. So basically, once Pyrel's done if you want to change the inventory mechanics, you're welcome to do so.

Fine with this too, and I actually have a possibly helpful coding suggestion. Instead of hard-coding the rules in different classes/methods, how about an "inventoryRules" class that contains all the rules in one place (canStack, canContain, canEquip, numberAllowed, whatever). Then people can simply add energyToExtract or whatever other rules they want.

I'm sure you've already thought of this, and either have a better idea or at the very least a better way of expressing it ;-)

[Derakon]

I love how easily I agree with you. I hadn't realised you had envisaged multiple quivers limited to 40 ammo (but presumably with no type or stacking restrictions so you can have 40 different arrows?), but it doesn't strike me as a heinous change (bearing in mind that the quiver is still a recent and fairly controversial addition to V).

The main reason to have multiple quivers is to do away with the weird elastic effect of the current quiver, where equipping items to it magically sucks up space from the backpack. I can't think of any way to do this cleanly; it's a huge hack pretty much no matter what you do. It's also pretty unintuitive.

And yes, I didn't plan on having any limits on exactly how many types of ammo you decided to stick into a single quiver, so if you wanted 40 stacks of 1 arrow each, you could do that. Obviously the inventory system will need to be paginated to handle extremely long lists.

On a side note, thinking about it more it's probably worth considering adding a quiver slot to the equipment, and only items in that quiver could be fired. The slot could accept either a quiver container or a single stack of ammo (so that young characters could still use missile combat without needing to find/buy a quiver first). Ammo in the backpack, or in quivers in the backpack, would be inaccessible -- you'd have to spend a turn to equip it first. The net result here is that you equip the quiver that has the ammo you want to use at the time, and if you run out of ammo then you have to spend a turn swapping quivers around before you can start firing again. I dunno, I think it sounds neat.

Fine with this too, and I actually have a possibly helpful coding suggestion. Instead of hard-coding the rules in different classes/methods, how about an "inventoryRules" class that contains all the rules in one place (canStack, canContain, canEquip, numberAllowed, whatever). Then people can simply add energyToExtract or whatever other rules they want.

I'm sure you've already thought of this, and either have a better idea or at the very least a better way of expressing it ;-)

Mm, we have to strike a balance here. We could, theoretically, try to anticipate all sorts of different ways in which one would want to modify the inventory system, and then code in support so that those ways can be done easily. Extrapolate this and you basically end up with "We will write your variant for you (but we aren't actually going to use all that code we wrote), so all you have to do is flip some switches to enable it." In other words, the bulk of the work in adding extra inventory modalities is in coding the support for them, but if we aren't going to use those modalities, why are we implementing them?

The guiding rule here should be that we write enough to support our use case, and we leave the door open so that the system can be extended to support other use cases, but we stop there. The current system (by which I mean the one that sits half-implemented on my home computer) could be extended to support all kinds of modalities if someone wants to write the code, and it wouldn't even be very hard. But I don't think the code should be written until there's a clear plan to use it.

[ekolis]

On a side note, thinking about it more it's probably worth considering adding a quiver slot to the equipment, and only items in that quiver could be fired. The slot could accept either a quiver container or a single stack of ammo (so that young characters could still use missile combat without needing to find/buy a quiver first). Ammo in the backpack, or in quivers in the backpack, would be inaccessible -- you'd have to spend a turn to equip it first. The net result here is that you equip the quiver that has the ammo you want to use at the time, and if you run out of ammo then you have to spend a turn swapping quivers around before you can start firing again. I dunno, I think it sounds neat.

After reading some of your earlier posts, I actually thought of a similar idea, though it's a bit less Angbandish than yours - instead of a separate quiver slot, quivers could be equipped in the shield slot! After all, how many archers go around using a shield, anyway? The shield slot could then be considered more of an "offhand" or "ready" slot... hmm, maybe you could let players equip wands and such in that slot, too, which would let them use said items faster or with a lower failure rate!

edit: actually, the system you proposed is almost like that used by ToME4, though in ToME4, quivers aren't containers; they actually provide unlimited ammo, but you have to spend a few turns to reload every so often!

[Derakon]

ekolis: that sounds like a sensible approach if you want characters who are going to do almost all of their combat via archery, without significant amounts of power invested in the individual missiles they launch (much like the Amazon character in Diablo 2). Then you don't want to be forced to deal with running out of ammo, since it brings gameplay to a screeching halt.

In Angband, of course, we do want ammo to be potentially powerful (and thus limited), and no class relies solely or even heavily on archery as their source of damage.

As for replacing the shield slot with an offhand slot, what about the other hands the player has for their weapon, bow, and torch? Anyway, mucking about with the available slots is variant territory as far as I'm concerned.

Anyway, I've pushed a first pass at containers to the repository. Items can have inventories now, you can put items into and out of other items, and their contents display can be turned on or off. Actions that interact with the inventory don't recurse through items, though, and when a container is "closed" you can't interact with the items in it, only with the container itself. Also, I've a feeling that containers are going to generate a lot of UI edge cases, and just generally make dealing with items more complicated...but they're still worth doing.

[ekolis]

OK, I thought it might be fun to get back into Pyrel development a bit (famous last words! ) so I was thinking maybe something useful to add would be showing game messages in a section of the main window (as opposed to in a subwindow, which doesn't even seem to be visible anymore, so I can't even see the messages).

However I'm not entirely sure how to start on this - looks like (at least in the wx frontend) there is a panel in the MainFrame which has all the ASCII symbols you're drawing, but I'm not entirely sure where they're being drawn from.

Also, it seems like there's still a lot of duplication between the various frontends... did the frontend refactoring never get finished? It would be nice if you could say "Artist, go draw these tiles on this frame!" and the artist would do so, without having to have a special type of artist for each frontend. But I guess then you'd need some sort of "tile model view" data structure which represents something that can be drawn in the space of a tile (either a graphical tile or an ASCII symbol, with the tile falling back on ASCII if we're not in a graphical frontend). Do you have anything like that?

Oh, and finally, how do I switch between frontends so I can try them all out?

[Magnate]

OK, I thought it might be fun to get back into Pyrel development a bit (famous last words! ) so I was thinking maybe something useful to add would be showing game messages in a section of the main window (as opposed to in a subwindow, which doesn't even seem to be visible anymore, so I can't even see the messages).

However I'm not entirely sure how to start on this - looks like (at least in the wx frontend) there is a panel in the MainFrame which has all the ASCII symbols you're drawing, but I'm not entirely sure where they're being drawn from.

Also, it seems like there's still a lot of duplication between the various frontends... did the frontend refactoring never get finished? It would be nice if you could say "Artist, go draw these tiles on this frame!" and the artist would do so, without having to have a special type of artist for each frontend. But I guess then you'd need some sort of "tile model view" data structure which represents something that can be drawn in the space of a tile (either a graphical tile or an ASCII symbol, with the tile falling back on ASCII if we're not in a graphical frontend). Do you have anything like that?

Oh, and finally, how do I switch between frontends so I can try them all out?

You start the game with --ui=FRONTEND if you want to use CURSES or QT. Without that you get wx.

I think frontend refactoring would be a great contribution - the sooner it's done the better.

[ekolis]

You start the game with --ui=FRONTEND if you want to use CURSES or QT. Without that you get wx.

I think frontend refactoring would be a great contribution - the sooner it's done the better.

Cool, thanks!

Not sure if I should be the one doing the frontend refactoring though - if I mess something up, it would break all the frontends at once! Maybe it would be better for someone more familiar with the code to do it?

On the other hand, someone more familiar with the code would be more prone to say "aww, it still works, it's OK!" and not refactor as mercilessly... and refactoring someone else's code is a great way to get familiar with it!

[ekolis]

Hmm, looks like you already have a base Artist class which all the frontend Artist classes inherit from, so this won't be as hard as it looked initially! Just need to put that view-model layer in there... but we'll need to leave flexibility for drawing things that cross tile boundaries, too (at least for the graphical frontends) - such as any beams, bolts, explosions, and particle effects! (I know Derakon was talking about those a while back! )

[Derakon]

I thought that the UI was in pretty good shape, actually. We spent a lot of time on cleaning it up, so now there's very little code that's actually identical across frontends. Of course there's plenty of code that's similar but not actually identical, but that's because the UIs do similar things in different ways due to the libraries they work with. Still, if you can find improvements then go ahead!

As far as displaying messages in the main window, that was one of those things I always figured would be an option down the road. Personally I like having a separate message window that doubles as a message history; this way the messages don't cover over the action and there's no need to have -more- prompts. Of course I recognize that not everyone feels the same way -- hence why this would be an option.

[ekolis]

Well, right now the message window doesn't even appear

[Derakon]

Well, that's not good. Does it appear if you launch with "-ui=QT"? That will use the QT frontend instead of the WX one.

The WX one launches the windows with hardcoded positions, and the message frame starts at (840, 200). I suppose if your display only had 800 pixels of horizontal resolution then you wouldn't be able to see it at all. The default positions should be changed since I'm guessing not everyone has a gigantic display to work with.

...in fact, let's go ahead and fix that. The main window now defaults (in WX) to (50, 50), and the message window defaults to immediately below the main window. That should keep it visible for everyone.

EDIT: er, this will be fixed next time I push, anyway. In the meantime you can change this trivially by modifying gui/wxPyrel/mainFrame.py:

         # Make us big enough for an 80x24 view, by default.
         self.SetClientSize((width * 80, height * 24))
-        self.SetPosition((200, 200))
-        messageFrame.makeWindow(self, (840, 200))
+        self.SetPosition((50, 50))
+        messageFrame.makeWindow(self, (50, 50 + self.GetRect()[3]))

[AnonymousHero]

Just wondering... Would you accept patches adding nose tests and test cases for some of the pure logic modules at this point?

(Not making any big promises, but I though that I could at least contribute some basic tests for the grammar module. I'd mark all the known failures as "ignored" and and the ones that we expect to succeed with the current implementation would just be normal tests. It woudl be a sort of todo-list for the module.)