Ok, I have put this of a while because it's a lot to write, this results in it being even more...
Begining from my last post:
quote:
Torak: About skills...
In this game as I have understood it you are not a new Einherjar, but have been there for thousands of years, so no significant skill increase is plausible.
For more general about game design its a good idea, the original Armok game (before DF, whit the horrendous 3D and wonderful main menu) had a more fleshed out version of this system and that is the best skill system I have ever seen
quote:
Gigalith: The most painful part methinks is deciding how to handle tiles. The most obvious ... There's no right way out of this paradox. However, one way is to create a GameObject class which both the tile class and the classes of the things desecend from. Now you can give everybody a GameObject* pointer, and have it both ways!
What I would suggest for maximum modularity is having a world class, an tile class, a item class, and possibly a creature class but the game becomes more consistent if creatures are a kind of objects, or even better many objects*.
Global is only the functions for input/output and a World object (or several world objects for different planes or universes or planets/spaceships outside the scale of tiles etc. but thats not necessary for this game)
the world object contains an array of objects and a 3D array of tiles.
Now comes the important part:
Tiles contain pointers to the items in them, objects contain pointers to their tiles, both contain pointers to the world, objects contain pointers to objects they relate to (for example a backpack contains pointers to the objects in it, and those contain pointers to the backpack, a creatures arm contain a pointer to the upper body* etc.) tiles point to it's neighbors...
Short version: POINTERS EVERYWHERE!
This is why I only program in C++.
*Have creatures not be a single object, but make every bodypart a different object whit a independent position and speed, this might help making a very detailed physics based combat system and is much more realistic and thus result in cool emergent behavior. I have a few other ideas on this to, like having a "soul" object usually contained by the head/brain but in certain situations might be done other things to, and having drawing/input/waiting code be called in this object rather than calling everything else, this might help very much if you want to add for example multiplayer (bad example, you probably wont, but if you wanted whit this system it would be easy) or several pother things (another bad example; time effects).
quote:
There's little advantage in having multiple files for a small project. And the jump is rather large. You should only take it if you think you are ready.
Not true, at least not if you have a decent compiler.
Even it you write all files in notepad, if you use the system I mentioned above at least for files for globals, world, tile, and object might be worthwhile.
quote:
nerdpride: *lots of horribly gamy suggestions about feasting being a power up system for combat, and a mesagelog about a drunk*
These ideas are HORRIBLE!
The feasting should be fun in its own right, imagine a contrast to the combat and a system whit telling stories from the days battle, drunken singing, socializing, and funny description of what other Einherjar say and do when they are drunk.
By the time fighting start again everybody would be relatively sober. And these are all Einherjar so there would be no such thing as a "drunken man" in the game.
Also Einherjar don't get tired, they feel no pain, they never lose their strength.
These are dead, while they still look and act and think as they did in life for the combat you should look more on undead.
About it being to ambitious I think that you can learn as you go, your first game *can* be good if you spend time on it and get lots of advise, and if you aren't afraid to rewrite things when you get better.
The only thing you can realy screw up ids the main arcetectur, and even Toady himself did that by hardcoding vievport size.
For the ASCII library I think taking a look a the Kobold Quest source might be an idea, thats the same system DF uses.
Phew, that was a lot.