So I have done some thinking, what about modability to a degree? Meaning I could take a basic template then modify it by drop down menus that all tie into the experience/penalties as you add or take away things from the class.
It's all a continuous scale, really, and ends up being a trade-off between flexibility and difficulty of implementation and use. So, you're talking there about designing custom classes, but what is
a class? The answer depends on the level of abstraction at which you think about the game - I was trying to look at things on a more fundamental level.
If you strip away all the preconceptions, a role-playing game (just about any game, in fact) is basically some sort of world and a set of rules about how the player is permitted to interact with that world. Fundamentally, some code somewhere needs to be written which enforces these rules, and in a modular system there's always going to be a big question about whether this code goes into the game engine, or the modules.
You seem to be thinking about custom character classes, but what if a module wants to add a custom skill? How would it specify the rules associated with that skill? What if it wanted to specify a new character attribute? Or even a new property of objects in the world? Some module designer out there decides they want objects to be flammable, so objects need a new "flammability" property.
Now this sort of thing is really cool if you can get it working, but it gets very hard if you can't make any assumptions about the world and the objects therein.
That might have been what you were thinking anyway, but I just wanted to try and illustrate the level to which you have to consider these things. As you suggest, I think limited flexibility is the way to go, but the million dollar question is where to draw the line. For example, if the core engine defines attributes and skills, and there's no way for a module to add new ones, then the ability to define custom classes becomes quite easy. You just define a group of skills, feats, or whatever other bonuses you want to offer, and you define how they accrue to the character as they level up.
That's not so hard to implement because the way
in which the player interacts with the world is defined by the engine - they use a pre-defined set of actions that modules can't override. Sure, the module can change which actions the player has available under various circumstances, but it's quite easy to write rules about that - it's a limited problem. However, a magic item which gives the player a skill that didn't previously exist in the game would be very difficult to implement unless you'd carefully considered the ability to do that when designing the engine itself.
Sorry, that was quite a long essay, and I don't feel I've been very clear - hopefully you've picked up on my meaning, though. Also bear in mind that, while I'm a software engineer, I'm not experienced at writing game engines, so it's possible I'm over- or under-emphasizing the difficulty of certain aspects.
Another thing is, what about having the game be able to make more adventures in a game world I (or we) develop? So all the tiles are there and you just do the dungeon layout you want...
Remember that tile-based engines are only one of the approaches, but personally I think it's a good one - they're easier to work with in lots of ways, and roleplayers aren't generally too bothered about hyper-realistic graphics.
So, again, you have a sliding scale of tradeoffs here. NWN used to have a fixed set of tile collections, and you could build levels with those. There was no potential for modules to include their own tilesets. It was possible to add more tilesets to the engine
, but that was a separate issue (and involved a little bit of low-level fiddling, I recall). So, you could take the NWN approach and offer a fixed number of tilesets, or you could allow modules to ship with their own. Or both.
Again, my feeling is some limited amount of flexbility. So, you define a file format which specifies tiles (including graphics, whether tiles are walkable, etc.), and then you can ship some basic sets with the engine, but also allow modules to add their own.
Also, how hard would it be to make a random dungeon filler?
The last time I tried to design one of these I was about 14(!), but I don't remember the code being too hard. Coming up with an algorithm that generated decent dungeons that didn't feel too cookie-cutter, however, was a bit trickier. It's certainly possible, but the way to think about this is an add-on tool which designers can use, I think, rather than as a core part of the game. When considering software problems, you always want to divide and conquer - split the problem into the smallest parts that you can, with well-defined interfaces between them, and then each one becomes a lot more tractable.
Let me know what you think....I love the input so far....wish to god I could program....
Ah, programming's not so hard as long as you're interested enough to stick with it through the frustrations
. You just need to be ruthlessly logical and mind-numbingly pedantic. Hm, doesn't make it sound very appealing, does it? Still, I like problem-solving, and coding has that in bucket-loads. Although I think I've been doing a bit too much of it lately... I was speaking to a non-technical friend of mine, who innocently asked how my day had been - I can't remember exactly what I said, but it ended up along the lines of:
"... So yeah, then I finally realised I'd mixed up the 'next' pointers on the LRU and hash table bucket lists! Sheesh, can you imagine? I felt like
such an idiot. I mean, how can- hey, are you OK? Your eyes look a little glazed...
Much as I like coding, I'm looking forward to the holidays...