Contents  Introduction  Explanation  Command Blocks  Improvements  Printable version     The Series  Storing/Reading  Doing Something  Control Structures

What About Command Blocks?

In the first part of this series, I made it clear that all 'command's must be contained in blocks. But, I never explained why. I can now begin to discuss the reasoning. In your game, you need some way of determining WHICH command(s) to execute WHEN. No commands will need to simply be called arbitrarily, without something that causes it to be called: an event. Whether this event is having the player move onto a specific tile, or when the player responds a certain way to an NPC's statement or question, it all requires something to happen, usually caused by the player's actions directly. So, you need some way of associating an event with a command (or commands).

Here is where the naming of command blocks, and having different types of blocks, comes in. A command block is almost always associated with a specific event by it's name and type. You could, for example, have a type of command block called "PlayerMoved", and for each tile/coordinate that you need a scripting command executed, write a block named by, say, the coordinates like so:

*Block* PlayerMoved 0514
  Foo (Bar)
*EndBlock*

When the player moves, your game would check whether there exists a command block of type PlayerMoved named with the coordinates (in the example's case, 5,14), and call this block.

For speed and simplicity's sake, you may want to have your actual command block variable array split up into groups of special types. This would allow your game engine to locate blocks such as those in the above example much faster, without having to go through all the other different command block types mixed in there as well. There are all sorts of possible optimizations that you could add onto this general scripting structure; all it takes is some thought!

Next : Improvements