Angband.oook.cz
Angband.oook.cz
AboutVariantsLadderForumCompetitionComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Development

Reply
 
Thread Tools Display Modes
Old October 25, 2010, 15:19   #1
Sirridan
Knight
 
Sirridan's Avatar
 
Join Date: May 2009
Posts: 560
Sirridan is on a distinguished road
pyAngband's thread

http://github.com/Sirridan/pyAngband

More is coming, I really can't work on it as much as I'd like except on Mondays it seems (no work on Monday, Fiancee at school).

Right now I need to put in the docstrings, add some more comments, and do all that other stuff. At the moment, I'm working on a small "test" dungeon floor that is static, has a shop or two to test those out (NYI), and to test out other things which will be added soon.

Hopefully sometime before the end of the month there will be something "playable", not anywhere near a finished game obviously, but hopefully something slightly resembling Angband.

Here are the classes as they stand:

Thing -> Base class for anything that can be on the map, it has a position and an ID which tells exactly what something is. (Think of the ID like a tval)

LivingThing -> Anything alive (or undead ) like a monster or the player

Player -> You (NYI)

Status -> A living thing's current status, it's health, stats, etc.

Stats -> A living things stats, STR, DEX, etc.

Resists -> Container for resistances, vulnerabilities, immunities, etc. Also constants for these things

Effect -> Effects like poison, stunning, and so on

Item -> A thing that can be used, picked up, etc.

EquipableItem -> Something like armor, a weapon, etc.

Weapon -> An equipable item that can be wielded as a weapon

Dungeon (NYI) -> The container for a dungeon level, generates levels, etc.
Sirridan is offline   Reply With Quote
Old October 25, 2010, 17:21   #2
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 7,937
Derakon is on a distinguished road
Haven't taken a look at your code just yet, but I did spend some time thinking about how the dungeon should be set up; here's my take on it:

The Dungeon is, largely, a 2D array of Tiles. Tiles in turn are containers for Creatures (monster/player), Terrain (doors/traps/stairs/etc.), and Items. Everything in a Tile can be interacted with -- for example, if the player chooses the "open" action, then you can look for adjacent Tiles that have closed doors or chests; applying that action to something can mutate it (closed door => open door) or generally change game state (closed chest => open chest and spawn items). Thus each class (Creature, Terrain, Item) needs to have a list of valid interactions that can be performed with it, along with the code to invoke when that interaction is done. A Creature's list could include e.g. Move (if the player moves into a monster, do an attack; if monsters move into each other, either block/swap/destroy depending on the moving monster's flags), Bash, and Target. Each interaction, in turn, has a range specification, which could be either a distance (0 = only current tile, 1 = adjacent tiles, etc.), be everything in LOS, possibly include inventory and equipment, etc.

Anyway, back to work for me, but I hope this proves useful if in no other way than in helping you justify your own design decisions.
Derakon is offline   Reply With Quote
Old October 25, 2010, 17:39   #3
Sirridan
Knight
 
Sirridan's Avatar
 
Join Date: May 2009
Posts: 560
Sirridan is on a distinguished road
I was thinking of something along those lines, either one 2D array with a container holding everything for every cell, or multiple arrays, each holding containers only for their type, such as one for terrain, one for creatures, one for items, etc.

For now, I think I'll do the first one, unless it becomes too cluttered, then I'll separate it out into multiple arrays for cleanliness.
Sirridan is offline   Reply With Quote
Old October 25, 2010, 17:40   #4
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 7,937
Derakon is on a distinguished road
One 2D array that holds containers is functionally identical to multiple 2D arrays that each hold different kinds of objects; however, the first is easier to work with.
Derakon is offline   Reply With Quote
Old October 25, 2010, 18:20   #5
Sirridan
Knight
 
Sirridan's Avatar
 
Join Date: May 2009
Posts: 560
Sirridan is on a distinguished road
Added DungeonCell (container for things), and TerrainFlags (flags for the current terrain object)
Sirridan is offline   Reply With Quote
Old October 26, 2010, 05:55   #6
Pete Mack
Prophet
 
Join Date: Apr 2007
Location: Seattle, WA
Posts: 4,142
Donated: $40
Pete Mack is on a distinguished road
I think you don't want "Thing" as your base object; Object is already available for that.

I think you're going to want:
GridPoints (locations)
Terrain (Traps, Granite, etc)
Item
Monster

Consider the case of a Xorn vs a Horned Reaper. The former has KILL_ITEM, the latter KILL_BODY.
That means you will need two visitor functions, one to delete items from a grid point, the other to delete monsters.
Sure, you can create another base object type, but don't call it Thing--that's just a synonym for Object.

Edit:
I suspect what you are trying to do is abstract from the *.txt file. That means you have a Tuple aka Record aka (yuk) Entity.
It will have an ID, a name, glyph, color, and (possibly) bitmap [both default and user-defined] for the current graphics model. It may (must?) have a description. So call it an AngbandTuple if you're old-school, or an AngbandEntity if you're new-school. Leave "things" and "objects" as part of the language.

The current implementation of the knowledge menu is based entirely on simple visitor methods. It shows just how weakly associated the different types of objects actually are. (There's almost no duplicated code between the various base implementations.) Look at
Code:
typedef struct ... member_funcs
in cmd-know.c. That's pretty much it for a shared object model between the various base classes.

Edit2: More changes for clarity.

Last edited by Pete Mack; October 26, 2010 at 06:22.
Pete Mack is offline   Reply With Quote
Old October 27, 2010, 01:20   #7
Sirridan
Knight
 
Sirridan's Avatar
 
Join Date: May 2009
Posts: 560
Sirridan is on a distinguished road
Quote:
Originally Posted by Pete Mack View Post
I think you don't want "Thing" as your base object; Object is already available for that.
Yeah, for everything that can be on the map, which is why it has the ID, and the x and y coordinates, however I suppose those can be moved into the higher classes and Thing removed.

Quote:
I think you're going to want:
GridPoints (locations)
Terrain (Traps, Granite, etc)
Item
Monster
Pretty much what I'm going for.

Quote:
Consider the case of a Xorn vs a Horned Reaper. The former has KILL_ITEM, the latter KILL_BODY.
That means you will need two visitor functions, one to delete items from a grid point, the other to delete monsters.
This won't be a big problem.

Quote:
Edit:
I suspect what you are trying to do is abstract from the *.txt file. That means you have a Tuple aka Record aka (yuk) Entity.
It will have an ID, a name, glyph, color, and (possibly) bitmap [both default and user-defined] for the current graphics model. It may (must?) have a description. So call it an AngbandTuple if you're old-school, or an AngbandEntity if you're new-school. Leave "things" and "objects" as part of the language.
The ID is unique to each type of thing and keys into data that doesn't change, like item_kind type deal. Color/glyph/bitmap are not defined in the code, the code will not care about any of that. It's all defined by the display, which will be as separate from the main code as possible. Pref-file kinda deal.
Sirridan is offline   Reply With Quote
Old October 27, 2010, 06:21   #8
Pete Mack
Prophet
 
Join Date: Apr 2007
Location: Seattle, WA
Posts: 4,142
Donated: $40
Pete Mack is on a distinguished road
I don't think items have XY coordinates. This is one place where "Soviet Russia" has it right...

Again, consider a generic Item. It can be wielded, in your pack, on the floor, and in a store. As for monsters, they can be on the floor, in the zoo, stuffed on your wall, or written up in the Encyclopedia of Player Knowlege.

Location is definitely an optional hasA, not an isA. ...And since there are potentially a number of things at position XY, you don't have position XY, position XY has you!
Pete Mack is offline   Reply With Quote
Old October 27, 2010, 06:35   #9
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 7,937
Derakon is on a distinguished road
Agreed with Pete. Containers that have XY coordinates may hold items, monsters, etc. Those items/monsters/etc. can then determine their location, if necessary, by asking their container where they are.
Derakon is offline   Reply With Quote
Old October 27, 2010, 16:34   #10
Sirridan
Knight
 
Sirridan's Avatar
 
Join Date: May 2009
Posts: 560
Sirridan is on a distinguished road
So you're saying each point on the map, call it a 'cell', will have the position? Hmm, I guess I like that actually, when monster AI is called, the cell could pass its x,y info to the monster (or whatever) so the monster doesn't really have to care what its x,y is.

So Thing will get dropped in it's entirety, but I'll keep LivingThing so I don't have to rewrite code between Monster and Player that I've already done.
Sirridan 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
Thread ratings Timo Pietilš Oook! 1 September 7, 2010 17:08
Questions That Don't Need Their Own Thread karmatic Vanilla 21 February 4, 2010 20:31
Magnate's thread Magnate Vanilla 7 December 23, 2009 16:53
Another HE Mage Thread Adqam AAR 3 August 11, 2009 04:24
Another 3.10 thread (as if we don't have enough) Jungle_Boy Vanilla 3 January 16, 2009 18:50


All times are GMT +1. The time now is 06:45.


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