What I learned from v1.1
Where to begin?
The entry gate area, the logic of requiring and splitting two players is fairly straight forward, but what caused pain (real pain) were the gates themselves. If you’ve tried building levels then you will know all about the glue and what a pain it can be. Well, whenever I tweaked anything on the entry gate area (or the things connected to it), the entry gates would invariably get stuck to there runners rendering the whole thing inoperative requiring me to take it apart and piece it back together.
Similar things occured elsewhere, so what I learned was to suspend different sections such that they were disconnected (by a single small grid square). That way, glueing one wouldn’t stick parts of the others together.
As for fixing stuff, I started out using big lumps of dark matter, but then I figured I could suspend things using hidden rods of dark matter. Small cylinders (1 small grid square in size) dropped into the body of the thing you want to fix in place and hey presto… it stays where its put.
Always think ahead and try to minimise the number of pistons etc. that you use. As an example, I’ll use some of the cell selection logic. There are 9 cells, and each used a set of logic like this to decide whether a player had it selected or not.
]<---->[ ]<->[*] [ ]------------------/D\ ]>-<[ ]<->[*] [
The first piston on each channel is used to select player 1 or 2. They are both fed by the same signal, but one of them is reversed. The second piston on each channel is driven by each players rotary selector. So, when player 1 is up, their magnet is within reach of the switch. If both players have cell 1 selected, it looks like this:-
]<---->[ ]<---->[*][ ]------------------/D\ ]>-<[ ]<---->[*] [
This is fine, but it wastes pistons. With a little careful thought, the 18 player 1/2 pistons can be replaced with a lot less. I’ll cover more on this topic in the section covering the development of version 2.0.
When I originally posted my hints, I advocated keeping logic thin so that if you need to you can pack 4 layers into the same screen area… what a mistake! I found that over time, as I was working on developing the game, the thin elements could slip behind or in front. Pistons that were stiff seemed to shift positions and I ended up with jammed mechanics. As a result, I have rebuilt practically all the control logic for the game using thicker materials and they seem to handle it. This also allows some other techniques to be used that help with reducing piston couns. As stated above, I’ll cover more on this in the section covering the development of version 2.0.
The general layout of the level was fine, apart from the fact that it required players to make a couple of leaps of faith. First on the entry gate and second when exiting the level. The entry gate area wasn’t too bad because they were held back by blocks of disolving material, but it was still possible to kill your opponent… at which point, they were locked out of the level by the now closed entry gates. The leap of faith on the exit was however a bigger problem. Several times during testing, one of us died as a result of being left behind. In short, it wasn’t good and did draw one or two complaints from the friends who helped me test the level.
Always test the level right before you publish it. I seem to remember I published with glued up entry gates which rendered the level useless. And, always test the different paths or outcomes. We had 16 games checking each win combination for each player, during which we did other tests as well, such as jumping on the place buttons when it wasn’t our turn, standing on the place buttons after we’d placed, checking that we couldn’t select two cell’s simultaneously, jumping on one of the reset buttons to make sure it didn’t clear the board.
In short, be thorough… think about what can happen. There is nothing more embarrassing than publishing a level which doesn’t work because of a simple error.