Script Design Philosophy

When designing a new script, or even rewritting an old one, there are a few things I concider before I even start writting the first script. I want to have a clear idea of what I want the script to do, what commands are going to be available. I want the script to be as usefull to as many people as possible while still remaining easy to use for those without degrees in computing. I also want to use as few resources as possible, there are only a limited number of command slots and upgrade wares. And lastly I want to ensure that any code I write that might be usefull to other scripts is written in a generic fassion to allow it to be easily reused.

Key points to consider

  1. the command should be tools to help you play, not play the game for you.
  2. use as few resources as possible
  3. interface must be simple and logical
  4. reuse existing code if possible
  5. write libraries for code that could be useful elsewhere

Tools to help you play

Scripts are extremely powerfull and can, for the most part, be used to automate anything you normally do in the X-Universe. There are a number of scripts currently available that automate the whole of a process, and these seem to be fairly popular scripts, but for me when you do that it's taking part of the game away. You're no longer involved in that process, it's all do for you. The prime example of this is the Mk3 trader. You turn it on and forget about it while it makes money for you.

A tool, is a script that automates certain aspects of a process, making it easier or more enjoyable, while keeping you involved in it. Keeping in the remote trading examples, the Manual Trade commands provide tools allow you to manually control a universe trader while still keeping you involved in the trading process. You feel like you've actually achieved something when you make money using the Manual Trade commands.

Limited Resources


Although X3 contains nearly twice the number of free command slots than X2, that's still a pitifully small number. The number of free upgrade wares hasn't changed, infact some of them have been used up in new items for X3, leaving maybe a dozen.

This is a tiny number of resourse free for the number of scripters and modders to play with, and if you want your scripts to be used you have to make sure that it's easy for non-scripters to be able to use. That means avoiding resources used by other scripts and mods.

The thing to remember here is that, even if there seems to be a lot of slots free for the moment, they are going to run out eventually. You need to concider very carefully what you want to do and whether you can roll similar commands into one script.

For example, if I want to be able to create a group of ships, rename them, give them all the same homebase and give them all the same command. I could create 4 commands, one for each option, but that's a lot of slots to use (yes it is really). If I look carefully at the commands, chances are I'm going to be wanting to run 2 or 3 of the same time on the same ships. I could do all 4 commands with just one command instead. That's 3 command slots freed up for something completely different, the end user finds it slightly easier by doing everything in one rather than running 3 or 4 commands, and the chances are they wont even notice the little bit of flexibility they've lost by having 1 command instead of 4.

So think about the commands you want. See if there are any that are similar enough to be made up as one command. And that goes for checking existing commands when you have an idea too. It may well be that and existing command could be extended without making it any more complicated.

interface must be simple and logical

This is another bug bear of mine. Using a command should be easy. If it's not, then you're probably trying to make your scipt too complicated. Sure, the interface isn't that easy or intuative to begin with but that's no excuse for making it worse with your scripts.

  1. don't ask for a number if it doesn't relate to anything very obvious.
    • take Egosoft's jump to sector command, asking whether followers should jump. To those that don't understand 1=[TRUE], 0=[FALSE] it has been very confusing.
  2. try not to use commands to configure other commands.
    • There's no easy way to see what you're configuring. Unless you understand the script inside out, chances are it's not going to make a lot of sense to many people.
  3. keep the list of arguments as short as possible
    • its easy to forget what you're trying to do if you have a long list of questions to answer, and you can't go off a check without having to restart at the begining of the list. Also you don't want to be spending a long time configuring a command when you're trying to save a ship under attack.

reuse existing code if possible

Have a look at the scripts that come with X2 or X3. There's a lot of basic stuff there that can be reused. Have a look at other 3rd party scripts as well. There's no point inventing the wheel if you don't have to.

write libraries for code that could be useful elsewhere

Think about the code you're writting. Could it be usefull in other scripts. Is it something generic that might want to be done in more than just this specific situation. It might be an idea to write it as a library instead. It'll save you some time if you find you need it again, and it might save someone else reinventing your wheel.

If you do try to write the code up as a library, try to think of all the different possibly uses for it, then try to make it cover as many of them as possible in the simplest most generic way possible. This may end up with you needing a couple of extra lines in your current project to use the library, but if it saves you time in another project then it's been worth it.
boron