Angband.oook.cz
Angband.oook.cz
AboutDownloadVariantsLadderForumCompetitionSpoilersComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Variants

Reply
 
Thread Tools Display Modes
Old July 30, 2012, 15:24   #11
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 5,807
Derakon is on a distinguished road
You could have multiple filter functions even in C, but you'd want a switch statement or something similar to select which one to call. In any event I'm happy to provide a wall to bounce ideas off of.

Even in Pyrel I won't be sticking the actual code into the creature record; the creature record will name the function it wants to use to filter its allocation, and that name will be mapped to the actual code to call.

I haven't coded much more up yet, since I was hung up on how to properly handle filter functions, especially those dealing with creatures before they get allocated. I wanted to leverage the Proc system I had (since Filters are basically Procs that change game flow instead of modifying game state), but Proc functions are self-contained entities that don't actually exist until their associated Thing is created. Using Procs to control creature allocation would thus require me to instantiate one of every creature every time I build an allocation table, just so I can decide if that creature should be usable. That's no good.

I spent some time talking it over with a friend, and he suggested that certain Procs should be "static" (i.e. attached to that class of creatures as a whole, not to a specific one), as determined by their trigger condition (i.e. when they are called). In Pyrel terms this means that the CreatureFactory would have procs associated with it, instead of the Creatures it makes having those Procs. I haven't yet thought of a reason why this couldn't work, so next chance I get I'll be implementing it to see how it flies.
Derakon is online now   Reply With Quote
Old August 2, 2012, 05:13   #12
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 5,807
Derakon is on a distinguished road
Okay, filter functions are in. I've also allowed Procs in general to attach to Creatures, which in hindsight is an obvious requirement for e.g. letting them have unusual effects on their melee hits. Heck, maybe even spellcasting will be handled via Procs; we'll see. More likely AI spellcasting will use the same system I have planned for player spellcasting -- selecting a spell from a container (spellbook). Which implies that AI creatures will be able to use at least some items from their inventories. Ho hum.

Also, I whipped together a little script to generate some basic stats on what the codebase looks like.



This has all been pushed to the Bitbucket repo, though I've a feeling nobody's tried to use that yet besides me. Oh well; it's still coming in handy even so.
Derakon is online now   Reply With Quote
Old August 3, 2012, 05:31   #13
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 5,807
Derakon is on a distinguished road
Okay, time to talk out some more design logic. I decided I wanted to implement the 'l'ook command, and this brought me to the realization that my current "prompt the user for a selection" system is badly-designed. The way this currently works is like follows:

1) Game is waiting for the next command.
2) User presses a key.
3) This is propagated to all Listeners, which then map it to some code to execute, in a gigantic block of if/else code. Some of these bits may return Prompts. Prompts are container classes (almost no associated code) that include a prompt type (e.g. yes/no, list items, select direction), a possible Container of Things associated with the Prompt, a message, and a few other doodads.
4) Returned Prompts are handed to the code that processes input and the code that handles game display.
5) All code dealing with processing and displaying Prompts (and layering, in the event that conclusion of one Prompt requires another Prompt) is external to the Prompts.

Displaying actually is reasonably sensible -- different display layers may want to handle displaying a selection of items differently, for example. The reason I separated out the input handling logic as well was that I was thinking about alternate input modes. For example, an item list might receive a selection via the mouse -- how would the Prompt know how to handle that if it doesn't know how it's being displayed? But I think the right answer here is that Prompts can handle keyboard input on their own just fine -- and I'll deal with mouse input later. More specifically, eventually Pyrel will need a mouse handler, and that handler will of course need to know about what is currently displayed. Mouse events will have to be translated by the handler into conceptual actions, like "select item from container" and "set target to this tile", which will need appropriate functions written for them -- but they're ultimately just more kinds of input, they just have to be handled slightly differently.

In practice, what we want to be doing here is have Prompts occupy a conceptual "layer" that sits on top of the game world. As long as a Prompt is active, it receives all user input (instead of that input going to any Listeners); meanwhile, Prompts are assumed to be drawn on top of everything else, though that can be left up to the display code. So. Here's my proposed new design:

1) Make the Prompt class heirarchical -- each Prompt contains beneath it the Prompt that its answer will assist. For example, if you want to use an item, you get a SelectItemPrompt. You select a spellbook -> the SelectItemPrompt creates another SelectItemPrompt beneath it to let you choose which spell. You select a spell -> the second Prompt creates a SelectTargetPrompt to decide where the spell goes. At any point we can unwind the stack to back out from one of these Prompts.

2) Add a "curPrompt" field to the GameMap. Currently Prompts are stored in the actual GUI window instance (that is, a wxWidgets Frame class), which is frankly pretty stupid and makes it unnecessarily difficult for the inevitable switch to Qt once someone who feels strongly about it gets interested in the project. From the GameMap, they're accessible to all input-handling and display-handling code, so input can be redirected as needed and display can show them on top of the normal stuff.

3) Modify GameMap.onCommand to check for a valid Prompt; if there is one, it gets input instead of the Listeners.

4) When a new Prompt is created, the GameMap is told to set it as the current Prompt. Similarly, when a Prompt is unwound (i.e. cancelled), it sets its parent as the current Prompt -- this may be None if it was the top-level Prompt, in which case input reverts to going to the Listeners.

5) Shunt all the current Prompt-handling code from gui.mainFrame to various subclasses of Prompt, replacing the current "prompt type" field in the base Prompt class. Looks like we'll need YesNoPrompt, ItemListPrompt (select item from container), ItemMapPrompt (used for displaying equipment, where each item gets a special label), FormattedMessagePrompt (for stuff like monster memory or detailed item info), DirectionPrompt (tunneling, disarming, etc.), and TargetPrompt (looking, targeting) to cover the ones that currently exist.

6) Since I'll be vaguely in the area anyway, replace the giant if/else statement in Listener that maps commands to results of commands with a dictionary that maps commands to functions that handle those commands. Functionally similar but more elegant and probably slightly more efficient.
Derakon is online now   Reply With Quote
Old August 8, 2012, 15:29   #14
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 5,807
Derakon is on a distinguished road
I'm still working on the Prompt rewrite, and some discussion with some friends of mine yesterday convinced me I wasn't quite on the right track even with the new system...so it''s gonna be a bit before this is done.

In the meantime, I had an idea for tweaking how Hallucination works. Right now it'd just be a display layer hack, where each tile would have a small random chance of being replaced by a random tile. Instead, I thought it'd be neat to occasionally spawn hallucinatory monsters and items (in the same manner that normal monsters and items are spawned). These things would last until hallucination ran out or you tried to interact with them; they'd be spawned as if they were native to a significantly deeper depth than usual; most importantly, hallucination itself would be an invisible ailment (you wouldn't be told that you were hallucinating) with a long timeout. Of course all the monsters could do is move -- no melee or ranged abilities.

You could also double up on pack monsters that already exist, mixing in hallucinatory ones with the real ones. Fortunately, Pyrel is already capable of handling multiple monsters on the same tile, so other monsters wouldn't have to worry about the fact that the hallucinatory ones don't actually exist.

So eating a Mushroom of Emergency, say, would work better in the short term, but you'd spend a looooong time wondering if those nasty out-of-depth monsters you detected around the corner are real or not, or if it's really worth chasing after that unidentified ring you spotted in a vault.
Derakon is online now   Reply With Quote
Old August 9, 2012, 02:41   #15
buzzkill
Prophet
 
buzzkill's Avatar
 
Join Date: May 2008
Location: Indiana, USA
Posts: 2,908
Donated: $8
buzzkill is on a distinguished road
Quote:
Originally Posted by Derakon View Post
most importantly, hallucination itself would be an invisible ailment (you wouldn't be told that you were hallucinating) with a long timeout.
This piece of the puzzle is brilliant. FYI, DaJ already re-did hallucination with some concepts similar to your own, might be worth peeking into.
__________________
www.mediafire.com/buzzkill - Get your 32x32 tiles here. UT32 now compatible Ironband and Quickband 9/6/2012.
My banding life on Buzzkill's ladder.
buzzkill is offline   Reply With Quote
Old August 9, 2012, 09:03   #16
Magnate
Angband Devteam member
 
Join Date: May 2007
Location: London, UK
Posts: 4,988
Magnate is on a distinguished road
Send a message via MSN to Magnate Send a message via Yahoo to Magnate Send a message via Skype™ to Magnate
Quote:
Originally Posted by Derakon View Post
In the meantime, I had an idea for tweaking how Hallucination works. Right now it'd just be a display layer hack, where each tile would have a small random chance of being replaced by a random tile.
Why a hack? Why not build in the capability for the displayed tile to be different to the "real" tile? This way you take care of mimics by the same mechanism, as long as you can have both fixed and random display tiles. (Admittedly this doesn't provide your feature of additional hallucinatory monsters, which is neat - I'm just quibbling about hack vs. design.)
__________________
"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 August 9, 2012, 10:14   #17
fizzix
Prophet
 
Join Date: Aug 2009
Location: Madison, Wisconsin, US
Posts: 2,597
fizzix is on a distinguished road
Quote:
Originally Posted by Magnate View Post
Why a hack? Why not build in the capability for the displayed tile to be different to the "real" tile? This way you take care of mimics by the same mechanism, as long as you can have both fixed and random display tiles. (Admittedly this doesn't provide your feature of additional hallucinatory monsters, which is neat - I'm just quibbling about hack vs. design.)
And the open door across dungeon "telepathy" bug.
fizzix is offline   Reply With Quote
Old August 9, 2012, 15:21   #18
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 5,807
Derakon is on a distinguished road
That's more an issue of handling player knowledge -- mimics need some kind of "appear to be something else" ability. At first glance I'd probably do that as "actually create the item they're pretending to be, and make the monster absolutely undetectable; then destroy the item and unhide the monster when the player moves onto the space, or the monster gets damaged. As for the doors problem, that's a matter of the game tracking what a tile appeared as when the player last "saw" (detected, etc.) it. Angband doesn't do this, but it could.

The reason I said hallucination as currently in Angband would be a display hack is because that's honestly the simplest and most elegant way to do it. Probably it'd be implemented as "create a hallucinator function; pass it the tiles in LOS and a function; it chooses some of those tiles and calls the function to randomize them."
Derakon is online now   Reply With Quote
Old August 12, 2012, 06:12   #19
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 5,807
Derakon is on a distinguished road
Okay, the Prompt rewrite is done. This turned out to be a bigger hassle than I'd anticipated, but as a pleasant side-benefit, the UI (that is, input to the program, and output to the screen/speakers/etc.) is now basically completely decoupled from the game engine. So if someone wants to make a Qt front-end, or make the game run on Android or whatever, all they have to do is make a new UI layer (the wxWidgets-based one is 418 lines long at the moment), and change one line early in program execution from "gui.setUIMode(gui.WX)" to "gui.setUIMode(gui.ANDROID)", etc.

Also, I wrote a basic Look command, which was the thing that got this all started in the first place.



It doesn't jump to the closest interesting tile yet, and it doesn't let you actually target a tile/creature, but at least you can look at things!

Oh, and monsters are killable now, which means that you can actually extinct unique "races", preventing them from being generated ever again. So I suppose the game is technically winnable, if you feel like wandering down ~100 dungeon levels to find Morgoth and then poking him to death with whatever the best-dice weapon you can find is, one blow at a time, while he wanders at complete random. Not that the game will recognize your accomplishment...
Derakon is online now   Reply With Quote
Old August 12, 2012, 13:00   #20
Nick
FAangband maintainer
 
Nick's Avatar
 
Join Date: Apr 2007
Location: Canberra, Australia
Age: 49
Posts: 4,321
Donated: $60
Nick is on a distinguished road
Quote:
Originally Posted by Derakon View Post
Oh, and monsters are killable now, which means that you can actually extinct unique "races", preventing them from being generated ever again. So I suppose the game is technically winnable, if you feel like wandering down ~100 dungeon levels to find Morgoth and then poking him to death with whatever the best-dice weapon you can find is, one blow at a time, while he wanders at complete random. Not that the game will recognize your accomplishment...
Pretty much ready for a comp, then.
__________________
One Ring to rule them all, One Ring to find them,
One Ring to bring them all and in the darkness bind them.
Nick 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 Derakon Variants 64 June 8, 2012 10:58
Play FAangband part II Fendell Orcbane AAR 6 November 29, 2010 20:53
JBand progress log. PaulBlay Development 38 June 27, 2009 09:19
Quill, Part II Sirridan AAR 9 June 25, 2009 03:51
Angband/65 development log PaulBlay Development 0 April 16, 2009 18:55


All times are GMT +1. The time now is 22:35.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.