Author Topic: Developing a scripting system  (Read 28890 times)

BirdofPrey

  • Newcomer
  • Posts: 31
  • Karma: +0/-0
    • View Profile
    • Email
Re: Developing a scripting system
« Reply #15 on: August 13, 2008, 02:42:54 AM »
Heh. Well, I did think twice about it, and sat down and tried to plan everything out, and I eventually came to realize that you guys are right. Wayyy too much on my plate for a first-time project. I'm putting the scripting idea on the back-burner for now, I may come back to it later when I actually have something to show for my project right now. *awaits the chorus of 'I told you so's*  :P

Gamer_2k4

  • Rogueliker
  • ***
  • Posts: 86
  • Karma: +0/-0
    • View Profile
Re: Developing a scripting system
« Reply #16 on: August 15, 2008, 03:32:23 PM »
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.
Gamer_2k4

elsairon

  • Newcomer
  • Posts: 7
  • Karma: +0/-0
    • View Profile
Re: Developing a scripting system
« Reply #17 on: October 15, 2008, 08:05:02 PM »
I've implemented loading monsters, keybindings, and maps from external files. That said, I don't use a scripting language, just a strict parser for each data type ( re-using some of the core parser tech and adding on what is needed for each different data type)

Having data in place ouside the code is nice for tweaking without haing to recompile anything.