General Category > Game Mechanics

[GHP] Thinwalls now have floors

(1/1)

magic.coding.fairy.peridot:
(This post is about Gearhead Prime, a reimplementation of the Gearhead engine in python. Gearhead Prime is not a playable game. If you're interested in the code, it's at https://github.com/aarchiba/gearhead-prime and other repositories forked from that.)

I've incorporated PlaintextMan's thinwall implementation into my github tree. I also changed things so that thinwalls now have floors underneath them. To do this, I changed thinwalls from "terrain" to "dungeon features", things that are treated as potentially movable objects. In the interest of not exploding the save game files, and maybe even switching from UTF-8 text with hardcoded implementation to a more sensible format, I made some changes to the yaml serialization of maps. Now a map is represented in a yaml file by a rectangular block of characters. Each character represents one type of cell, which is a terrain type and a list of objects contained in that cell. So '@' might represent a floor terrain and the PC, and '-' might represent a floor terrain and a horizontal thinwall. The yaml file contains a description of what each character means.

I should explain: yaml is a generic sort-of markup language for representing objects, sort of like XML. Its format, though, is a lot more like you might use in email: lists are represented by lines starting with dashes, for example, and nesting of lists is represented by further indentation. So while yaml is a fully-specified format that can be read and written by a standard library (which I include because I want to change certain defaults while remaining compatible) it's also fairly human-friendly. My intent is that large amounts of game content should be writable in yaml. In particular, it should be possible to write new levels in yaml. If you want to play with the yaml level representation, then you can try running gamemap.py; it loads a plain text UTF-8 level file, then writes it out as yaml (then reads it back in and writes it out a second time, for testing purposes; the two output files might not be identical but the differences should be cosmetic). My only hesitation about writing content in yaml at this point is that the representation may not quite be finalized. But please feel free to comment on it.

PlaintextMan:
Nice to see the thinwalls having proper floor coverage. Even though it still uses that crappy floor texture :P Oh and recolored walls FTW.

I got swamped with other work and fun lately, so my doors implementation which I almost finished after starting got bogged. I think I'll just scratch most of it and work from the terrain feature stuff you did. Although, at the time of posting I'm not sure whether it would be all that different; haven't checked out your codez yet. I'm quite curious though, but it's getting late once more...

Regarding a map representation in save/content files: when I thought of a more flexible unicode text format, I was thinking that maybe terrain types should be identified by a string name (like "hospital-wall-1", "safe-door-l3"), and that the glyphs used to represent that terrain be reassignable on a map-to-map basis.
Eg: one file defines a bunch of terrain types and their properties, each identified by a string name. Then the map file can have [glyph -> terrain type name] information in its header, and then in its body the usual block of glyphs that define the map. One map might treat # as a rock wall, and another treat it as a metal wall.

I thought of this from a map creators view point only though, so yeah, it all raises the question of how saved maps will be stored. Nothing technically wrong with assigning glyphs down the alphabet to terrain types used in the given map, but perhaps the map-to-file writer could be taught to try using some sensible defaults. Each terrain type may have a default glyph that it 'prefers' would be assigned to it, (so both metal wall and rock wall may define # as their default glyph) but if there is indeed a 'conflict' because two such different-but-similiar terrain types occur in the same map, then it might suffice to simply assign the rarer terrain type some other glyph inside that map's header in the file. Effectively, the characters (glyphs) that make up the map data would function like renamable macros.

If the whole idea would work with YAML, what think you of it?

I definitely think it's a great idea for the game save format to be the same as (or very similiar to) the content creation format, if possible. Maybe Python 'script fragments' could be stored directly in the save format, or stored as seperate files that are referred to by game-world objects and therefore in the save file too (I'm thinking of something like was did with the yellow button of GHAR's Mystery Machine, but making this the default if not only behaviour for scripts).

EDIT: you have named that class in gamemap.py "Feature" which is sensible of course, but I'm just wondering a bit whether that term won't become very ambigious in time. So possibly rename the concept to "MapFeature" or somesuch?

magic.coding.fairy.peridot:

--- Quote from: PlaintextMan on August 05, 2012, 02:07:05 pm ---
Regarding a map representation in save/content files: when I thought of a more flexible unicode text format, I was thinking that maybe terrain types should be identified by a string name (like "hospital-wall-1", "safe-door-l3"), and that the glyphs used to represent that terrain be reassignable on a map-to-map basis.
Eg: one file defines a bunch of terrain types and their properties, each identified by a string name. Then the map file can have [glyph -> terrain type name] information in its header, and then in its body the usual block of glyphs that define the map. One map might treat # as a rock wall, and another treat it as a metal wall.

I thought of this from a map creators view point only though, so yeah, it all raises the question of how saved maps will be stored. Nothing technically wrong with assigning glyphs down the alphabet to terrain types used in the given map, but perhaps the map-to-file writer could be taught to try using some sensible defaults. Each terrain type may have a default glyph that it 'prefers' would be assigned to it, (so both metal wall and rock wall may define # as their default glyph) but if there is indeed a 'conflict' because two such different-but-similiar terrain types occur in the same map, then it might suffice to simply assign the rarer terrain type some other glyph inside that map's header in the file. Effectively, the characters (glyphs) that make up the map data would function like renamable macros.

If the whole idea would work with YAML, what think you of it?

--- End quote ---


This is not really very different from what's in there now. Take a look, it's in gamemap.py, in the Map object's __getstate__ and __setstate__ methods. (Which may seem weird but makes sense since they're how an object customizes its serialization and deserialization.) Simply running python gamemap.py will also give you some example yaml map files to play with.

As it stands, every yaml map file consists of a list of cell types (actually a dict indexed by the character that represents them in the map) and then a UTF-8 literal ASCII-art map. Where possible, a cell is represented by the roguechar corresponding to the topmost object in the cell, or the roguechar corresponding to the terrain if the cell is empty. Right now it just picks a random other printable Unicode character if this initial guess is taken, but there are various ways more sensible suggestions could be provided. Simplest from my point of view would be for each object to provide a list of suggested roguechars, each of which gets tried, before the code just gives up and picks any old (printable) Unicode character. We'll always need the fallback for dungeons that are littered with loot and debris.

(Incidentally, the coverage of the box-drawing and other likely Unicode characters in fonts the user is using is kind of spotty. So there's a risk that if we get too clever with this players will open yaml map files and get great swathes of unhelpful "missing character" glyphs.)


--- Quote from: PlaintextMan on August 05, 2012, 02:07:05 pm ---
I definitely think it's a great idea for the game save format to be the same as (or very similiar to) the content creation format, if possible. Maybe Python 'script fragments' could be stored directly in the save format, or stored as seperate files that are referred to by game-world objects and therefore in the save file too (I'm thinking of something like was did with the yellow button of GHAR's Mystery Machine, but making this the default if not only behaviour for scripts).

--- End quote ---


I'm inclined to wait on the script fragments question until we have a more fleshed-out structure to the game. No point figuring out how to customize default behaviour until we have default behaviour to customize.


--- Quote from: PlaintextMan on August 05, 2012, 02:07:05 pm ---
EDIT: you have named that class in gamemap.py "Feature" which is sensible of course, but I'm just wondering a bit whether that term won't become very ambigious in time. So possibly rename the concept to "MapFeature" or somesuch?

--- End quote ---


I'm personally more inclined to DungeonFeature, in the style of NetHack, even though most of them won't be occurring in dungeons. Not that GH ever had dungeons in the pre-D&D sense of the word.

PlaintextMan:

--- Quote from: Peridot ---
This is not really very different from what's in there now. Take a look, it's in gamemap.py, in the Map object's __getstate__ and __setstate__ methods. (Which may seem weird but makes sense since they're how an object customizes its serialization and deserialization.) Simply running python gamemap.py will also give you some example yaml map files to play with.
--- End quote ---

How did I miss that!

Immediate thought: my doors are each recieving a different glyph. I understand why, but it was kind of funny upon first seeing it.


--- Quote from: Peridot ---
I'm inclined to wait on the script fragments question until we have a more fleshed-out structure to the game. No point figuring out how to customize default behaviour until we have default behaviour to customize.
--- End quote ---

Yeah. The thought crossed my mind though, and I think it would be a viable method once we get there.


--- Quote ---
I'm personally more inclined to DungeonFeature, in the style of NetHack, even though most of them won't be occurring in dungeons. Not that GH ever had dungeons in the pre-D&D sense of the word.
--- End quote ---

Terminology accepted! :P

magic.coding.fairy.peridot:

--- Quote from: PlaintextMan on August 11, 2012, 10:06:07 am ---

--- Quote from: Peridot ---
This is not really very different from what's in there now. Take a look, it's in gamemap.py, in the Map object's __getstate__ and __setstate__ methods. (Which may seem weird but makes sense since they're how an object customizes its serialization and deserialization.) Simply running python gamemap.py will also give you some example yaml map files to play with.
--- End quote ---

How did I miss that!

Immediate thought: my doors are each recieving a different glyph. I understand why, but it was kind of funny upon first seeing it.

--- End quote ---

It's annoying, and it's why I was agonizing over how to deal with objects with state. I think for now I'd say just live with it, though it's going to be kind of a pain for hand-created maps.

Navigation

[0] Message Index