Archived from groups: rec.games.roguelike.development (More info?)
So I was looking at the NetHack code for the first time the other day.
Whew. Looks like it dates back to the time when utilizing
self-descriptive variable names with more than 8 characters was a
cardinal sin. A cursory look revealed that a lot of the actual game
data was saved in tables in .c files. All in all it looks like a piece
of software that has had new functionality bolted on to it every which
way for years and years. Which, of course, it has.
The only other roguelike whose inner workings I've looked at is
Angband, which I noticed used lua scripting for spell effects and maybe
some other things. Maybe more of the game data is saved in text files
too (though I'm not totally sure, it seems that way) On the whole
Angband seems to have more variants than NetHack, possibly because it's
easier to modify given these characteristics.
Which brings me to my question: how important is it to separate game
data from the game engine in a roguelike game? I'm not even focused on
other people making variants of my game right now. I'm in the beginning
phases of implementation and I know that down the road I will have
great ideas for things that I want to put in my game and I want a
design flexible enough to allow this type of modification even at a
late date. Thus it seems that the more I can separate the engine from
the data, the better.
So, roguelike developers, what parts of your game have you separated
out into databases/text files/scripts?
The basic approach that I am taking is that "effects" and "properties"
are coded directly into the engine and then game entities (tiles,
items, monsters, maybe spells) reference these properties. For example,
at the moment I am trying to come up with the best way to support a
tileset of dungeon primitives (floors, walls, water, lava, doors, ect).
I thought I would make a bunch of flags that the engine understands
like: WALKABLE, MISSILE_PASSABLE, SOLID, ISDOOR, ect. Then I would save
the data for each tile as an XML node with the filename of the bitmap
to draw the tile with, and a list of properties. A water tile would
have {MISSILE_PASSABLE} defined, a wooden door could have {ISDOOR,
SOLID}, a jail door with bars could be {ISDOOR, MISSILE_PASSABLE}
I think this approach is very flexible because I can add as many flags
as I want, even late in development.
These are just data files, not scripts. But surely there must be a
place for scripting in a roguelike for NPCs and maybe even dungeon
generation. What do you guys do?
The place where my approach gets fuzzy would be for objects like
fountains in NetHack. It seems like something with so many interactions
should be scripted instead of hardcoded into the engine. I guess the
part that confuses me a little is where datafiles should leave off and
scripting begin.
PS - can anyone recommend a good scripting language for roguelike
interactions that be can integrated in C#? I was thinking of using lua
or C#.
So I was looking at the NetHack code for the first time the other day.
Whew. Looks like it dates back to the time when utilizing
self-descriptive variable names with more than 8 characters was a
cardinal sin. A cursory look revealed that a lot of the actual game
data was saved in tables in .c files. All in all it looks like a piece
of software that has had new functionality bolted on to it every which
way for years and years. Which, of course, it has.
The only other roguelike whose inner workings I've looked at is
Angband, which I noticed used lua scripting for spell effects and maybe
some other things. Maybe more of the game data is saved in text files
too (though I'm not totally sure, it seems that way) On the whole
Angband seems to have more variants than NetHack, possibly because it's
easier to modify given these characteristics.
Which brings me to my question: how important is it to separate game
data from the game engine in a roguelike game? I'm not even focused on
other people making variants of my game right now. I'm in the beginning
phases of implementation and I know that down the road I will have
great ideas for things that I want to put in my game and I want a
design flexible enough to allow this type of modification even at a
late date. Thus it seems that the more I can separate the engine from
the data, the better.
So, roguelike developers, what parts of your game have you separated
out into databases/text files/scripts?
The basic approach that I am taking is that "effects" and "properties"
are coded directly into the engine and then game entities (tiles,
items, monsters, maybe spells) reference these properties. For example,
at the moment I am trying to come up with the best way to support a
tileset of dungeon primitives (floors, walls, water, lava, doors, ect).
I thought I would make a bunch of flags that the engine understands
like: WALKABLE, MISSILE_PASSABLE, SOLID, ISDOOR, ect. Then I would save
the data for each tile as an XML node with the filename of the bitmap
to draw the tile with, and a list of properties. A water tile would
have {MISSILE_PASSABLE} defined, a wooden door could have {ISDOOR,
SOLID}, a jail door with bars could be {ISDOOR, MISSILE_PASSABLE}
I think this approach is very flexible because I can add as many flags
as I want, even late in development.
These are just data files, not scripts. But surely there must be a
place for scripting in a roguelike for NPCs and maybe even dungeon
generation. What do you guys do?
The place where my approach gets fuzzy would be for objects like
fountains in NetHack. It seems like something with so many interactions
should be scripted instead of hardcoded into the engine. I guess the
part that confuses me a little is where datafiles should leave off and
scripting begin.
PS - can anyone recommend a good scripting language for roguelike
interactions that be can integrated in C#? I was thinking of using lua
or C#.
| because they are subtle and quick to anger.
Facebook
Twitter
Instagram