It can take more work to begin with to set up a system like this, but it’s well worth it. I find this is a very useful approach when programming give yourself the tools you need to do what you want conveniently.
I made a robust Doodad-placing system that could be given a Doodad name to create, and told what tile types were required both in and around the Doodad. To test them thoroughly, I deliberately made each type of Doodads as dense as possible, ensuring they couldn’t get any wrong-looking placements. Dialogs and Dialog Items, for example, are just. A lot of things in the editor boil down to either Strings or Ints.
#STARCRAFT 2 EDITOR VIEW GALAXY IMPLEMENTATION CODE#
It also means that code isn’t overwritten when changing small things, like the type of a variable. This might all sound rather convoluted, but it was needed to ensure that the planets appear seamlessly with no loading times and no missing terrain. Galaxy solves all these problems by letting you edit the code like you would any other. This process waits for the surrounding Blocks’ terrain to be written, then goes through each Block a second time to place its Doodads. I wanted to improve on this flaw, so for the overhaul of the Doodads system I created the Trailing Doodad process, known as ‘TDoodad’ for short. In previous iterations this made it impossible to have Doodads of more than one tile at the edges of the map. Part of the challenge is that as your ship descends into the planet, not all the terrain is actually decided yet! When the very first Block of terrain is being generated, it’s not yet possible to get information about the tiles in any of the surrounding Blocks. As the map generates, it’s easy to pick a location for the Doodad at random, but ensuring that the location is suitable is more difficult than it might seem. You must also check its surrounding tiles for terrain that would look wrong next to it. To place, say, a large rock, you must first ensure that the terrain under it is of the right ‘Dark rock’ type.