Update: new mechanic added!
Buttons now allow nanotube entrances to be activated or deactivated.
A button will trigger when either type of particle passes over it.
Green buttons are single use. They will switch the state of their target nanotubes one time. (If it is on, it will turn off, and vice versa.)
Yellow buttons can be pressed an unlimited number of times, and will switch the state of the target tube each time.
Nanotube entrance/exit pairing code has been heavily revised for better control when building levels.
Nanotube entrance and exits now properly match up according to developer-assigned IDs, rather than relying on those previously designated by creation order.
This same revised pairing system was also used to pair buttons with intended target nanotubes.
A new level element? This far into development!? YES. That is in fact exactly what just happened because I've had a lot of ideas for level designs that end up being unusable because they're mostly variations of "what if one particle could go here but another one couldn't?"
I considered a few different features to try and make some of these ideas workable. Maybe more different types of nanotubes? One type that only Antis can go through, and one that only Regs can use? Or just some kind of gate that lets one pass but not the other?
And I COULD do either or both of those, but it would kind of break the narrative reason for playing the game in the first place. The idea was that Dr. Teranta's machine wasn't able to sort out the regular matter from the antimatter, so he developed this system to simulate different filter configurations and turn them into puzzles for the player to solve. You are only playing the game because these features aren't present.
And let's be honest here. Whoever heard of a science-themed puzzle game without giant shiny buttons? So that's it. Buttons. You send an Anti or Reg running over one, it turns a nanotube in the level on or off. Green ones are single use, and you can press the yellow ones as many times as you want. This simple feature opens up a whole world of puzzle design possibilities, and I'm a lot less worried about figuring out how to get 40 interesting levels out of the mechanics I have.
Speaking of the nanotubes, remember how proud I was of getting that code working to match up the entrances to the exits? Well, I kind of had to rewrite like 2/3 of it because it turned out it wasn't really doing as much as I thought it was, and the way it was doing things definitely would've proven to be a bit of a pain in the neck when the time came to actually make proper levels with more elaborate nanotube setups.
See, the original code was INTENDED to assign an ID variable to each entrance and exit pair, and match them up after building an array of all the exits. I THOUGHT it was doing this, but what was really happening was slightly more annoying. It was matching entrances to exits based on their creation order, not the numbers I was assigning to them. This isn't horribly game breaking, but for more complex nanotube levels I'm definitely going to need tighter control over which entrances go to which exits, and running the whole game to see where they go every time I want to set up more than one pair is not going to cut it. Defeats the purpose of designing the level maker.
The revised matching code works. Basically it goes through the array of exit instances line by line checking their "exit_id" variable until it finds one that matches the "entrance_id," then assigns that exit as the entrance's target. I guarantee it is inefficient and a half decent professional would probably tear their eyes out if they took one look at it, but I got it to do what I need it to do, and I used this same method to pair buttons to their target nanotube entrances.
So now an entrance with "entrance_id 1" will send particles to the exit with "exit_id 1" and so on.
With this, I am 99.99% sure I won't be adding any more new game mechanics. It's all polish, cutscenes, and level designs from here on out.









