Set Discrepancy

is when I plan to release the next version. Unless there are catastrophic errors.

A lesson in game design: Always try to build your program from the simplest possible set of objects, and always try to use the same object for similar purposes. In RPG maker, a set of instructions that makes things happen is called an Event and it's built using the Interpreter event commands. But in this game I made a second type of object called a "Task" which represents actions like firing a weapon. It also contains instructions like animations and sounds, but mainly it handles skill checks and target selection and crap like that. When a Task has to trigger a cinematic scene with dialog, it calls a common event and thus switches to an Interpreter. The Task executor is capable of suspending itself while an Interpreter runs, but not the other way around, which is why tech rolls look kind of weird and clunky when part of Interpreter events: It's because tech rolls were built for Tasks, but the Interpreter isn't capable of mounting a Task object to run the tech roll so I have to make this weird "shell" out of script that barely works.

So far so good, but then there are further, even simpler sets of instructions for what enemies do on their action turns. I got lazy with those and just made them arrays of string values, some of which trigger specific actions, and the rest of which are just evaluated as Ruby commands. And then there are EVEN SIMPLER sets of instructions for small occurrences like enemies dying, and those are just arrays of strings which are ALL evaluated as commands.

THE RESULT IS THAT THERE ARE 4 DIFFERENT TYPES OF EVENT PROGRAMS, WHICH REQUIRE 4 DIFFERENT INTERPRETERS TO BE SUPPORTED IN 4 DIFFERENT PLACES IN THE PROGRAM. So making any changes is hellish and it is very difficult to keep track of how they are all supposed to work together.

This has become particularly troublesome after I made the change to when enemies die. If an enemy took enough damage, they used to just stand there for the rest of the turn and die at the end of the turn, all together. But now I've decided it's better if they die immediately after the task that dished out the mortal damage. The easiest way to do this was to quick append more Task instructions onto the end of the currently running task. BUT ENEMY DEATH INSTRUCTIONS WERE ALL READY BUILT USING THAT SIMPLISTIC STRING ARRAY. THE RESULT IS THAT I HAD TO GIVE EACH ENEMY TWO VERSIONS OF DEATH INSTRuctions, once in the form of the string array and once in the form of a task. THIS IS SO INEFFICIENT THAT I CRY.

SO THE LESSON IS DON'T BE LAZY. MAKE THE EFFORT TO CENTRALIZE ALL SIMILAR PROCESSES IN ONE PLAC. THAT'S WHAT I LEARNED ABOUT GAME DESIGN TODAY.

AND WHAT AN INTERESTING BLOG IT WAS