Hi all! I'm glad I found this place! I'm a month or 2 into development of a roguelike. Programming it with C++ using SDL and SDL_TTF. My overall vision is a game that combines what I consider the best parts of my favorite roguelikes (mostly ADOM and nethack), with many unique additions of my own. I've already scoured the articles on Roguebasin but real dialogue is always nice.
...
Here's where the topic comes in: I have my heart set on a highly flexible scripting system to be used in the external data files in the game. If things work out properly, I would want to have almost everything except for the most basic game engine details to be defined in external files rather than hard-coded. Everything from random map parameters, specific maps, quests, items, monsters and monster AI, skills, effects, etc.
You sound like me five years ago. =P
I always wanted to have a customizable game, but then I realized something: At some point, I'm going to want certain elements of the game hard-coded. If the player doesn't have access to data about the boss monster, or certain quests, or artifact properties, they'll be able to play the game as it was designed, instead of going through quickly and easily because they know how everything works.
The next step in this thought process was the realization that if there is going to be customizable content, it will be implemented and added after the real game is made. What's the point in customizing if the game isn't done and ready to accept those customizations? Therefore, since we know that we're going to hard code the actual game anyway, and that user-defined content is irrelevant until there IS an actual game, it only makes sense to not worry about scripting until much later in the development process.
Is this an excuse for poor and limited game design? Of course not. Luckily, there's a pretty substantial difference between "flexible" and "can handle everything", the main one being that the first is achievable. When you start by hardcoding a game, you add features as they become needed, rather than the scripting approach, which says, "The player MIGHT want to do this or MIGHT want to do that, so I'd better include it."
My suggestion (if it wasn't clear by now) is to write the game as you want it, then later add scripting as an additional interface to editing content (the first being changing the source code). You'll actually make tangible progress, and tangible progress is what keeps a developer interested in his own project.
