#antimatterator

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.

Yet more graphical stuff!

Remember when I said I wanted to try to do a screen shaking effect for when the shutter closes, but I wasn't sure I would be able to make it work? Well, it turns out those concerns were totally unfounded.

I bound it to a key so I could test it while working on it, and I'm honestly debating whether or not to actually remove that, or just leave it in for funsies. Silly little easter egg that serves no purpose.

Oh yeah, I also did the little dust puff I talked about before. Knew that would be easy. And it was. Interestingly, I think this is the first actual dust/smoke/explosion effect I've ever made. Effects like that are always so far down on the list of priorities, and I've never actually made enough progress on any project to get that far.

Graphics and sound update!

(And a few technical touch-ups that aren't actually visible.)

Reverted level control buttons back to the rounded designs and made some minor adjustments.

Level name display is now created by the control panel object, avoiding the need to manually add it to every single level in the future.

Added a shutter animation for the "clear all arrows" button.

Arrows will no longer play their reset animations if they are already in their starting positions.

Player can no longer press the start button again while a run is already in progress.

Added sound effect for pressing the start button, picking up/placing an arrow, pressing the start button, and level transition/restart.

I did say I thought it looked kind of weird when you reset all the arrows and they play their animations simultaneously like that. I thought it would be fun to give the process a little more flair, and I have some ideas for how to push it just a tiny bit further. Thinking about some slight screen shake and a little dust puff when it closes. Dust puff is easy enough, but I'm not sure if I can make screen shake work with how I've got the level rooms set up. Gonna have to look into it.

I also feel super clever for figuring out a way to add the level name display to every level without having to actually go into each one and manually place it. Pretty sure I just saved myself at least an hour of work with that neat trick that only took a few minutes to implement.

Good news! I fixed that issue from the last post! The one where Regs following Antis too closely could unintentionally collide while making turns!

I had considered adding some kind of timer on the Antis to disable collision detection for a few frames immediately after touching an object that causes the direction to change. But I was worried that doing this would cause issues in certain situations. Such as going over one arrow that points directly into another arrow. Disabling collision after hitting the first arrow would cause it to ignore the next one. Or if an arrow was just too near a wall, the particle might end up going out of bounds!

Fortunately, a friend suggested a more targeted approach. Rather than disable collision entirely, I could set up a state that would specifically disable the fail trigger code of an Anti colliding with a Reg.

So now when an Anti goes over an arrow or bumps into a wall, it enters an invulnerability state for 5 frames, after which the state is turned back off and normal behavior resumes. And Regs now only trigger the fail state if they collide with an Anti AND that Anti is not in its invul state. This allows an Anti to make turns in any direction even while being directly followed by a Reg.

Unfortunately, it also allows for this:

Yeah. Somehow didn't account for that possibility.

The big question NOW is...

Do I try to fix this?

I'm starting to run out of excuses to not make the rest of the levels and call this blasted thing done already.

Added explanations for the tutorial levels. They only show up when the player enters the level and will not reappear after resetting a run.

Got another tracker working, so it can now tell if the player completed a level using fewer panels than provided. ("Less panels! Yay!" is just a placeholder and visual indicator that it's working properly.)

The counter for the related achievement will not actually update during the tutorial levels. (Because literally the first one demonstrates that it is possible.)

Fixed a bunch of layering issues.

Finally got an animation to play (mostly) correctly when an AM particle enters a collector.

Yeah, I've been wanting to have some kind of quick animation play when the particles enter a collector so they don't just blip out of existence, but for some reason that turned out to be annoyingly hard to figure out. I think it's partly because I was trying to give the animation to the collector object, and because it already had its "end of level" animation too, things got messy trying to add more to the mix.

Then, while I was doing those layering adjustments, it occurred to me that I could just do for the blue particles entering a collector what I did for red ones getting sucked into black holes. I even had four open frames on their sprite sheet because the antis don't have a "get sucked into a black hole" animation.

Then I ran into some issues getting the sprites to actually line up on the right spot while the animation played, but I eventually got that sorted. There's still some minor wonkiness that I THINK is happening because an anti enters a collector near the end of its animation loop, and the "gotcha" animation is starting at that same point in its animation. So I just need to find some way to make sure the whole animation plays every time, and not just sometimes.

I really am hoping to work on this game more consistently.

I'm thinking of implementing a totally in-game achievement system to make 100% sure all the trackers are working correctly, and have everything all set up for when I'm finally ready to pull the final lever and launch this thing onto Steam.

(Yes, it *is* version 3 if you count the scribbly, MSPaint-y placeholder as version 1. Did I ever show that one? I think I've mentioned it, but I don't know if it ever actually appeared in any of the videos I posted.)

Yep. Pretty much done at least as far as the actual pixel art goes. Looking forward to learning how Game Maker 2's sequence thing works, because it *looks* like it should make stuff like cutscenes and other animated bits a lot easier to make by not having to code so much.

That's a big thing I was worried about for future projects. I figured out how to make a basic dialogue system that works great for mostly static cutscenes, but I have no idea how well it would work for scenes where characters actually do things.

That being said, a simple camera movement from the top of this screen to the bottom, the monitor turning on, the title appearing across the top, and the buttons popping up somewhere. Should be complex enough to be good practice with the sequence editor, while simple enough to actually be easily doable.

First of all, I have an actual video update again. That hasn't happened in a while! Second: Game Maker Studio 2's sequence editor is an absolute (and LITERAL) game changer. This would have taken me HOURS to do with code, and definitely wouldn't have turned out half as good.

I mean, it still took me a good couple of hours because I had to figure out the sequence editor workflow, but now that I've got a handle on it I'm sure I could have put this together in maybe 20 minutes. It's basically the same animation timeline setup as After Effects or Blender, so it's pretty intuitive. It looks like there's a LOT you can do with it, and I've only just scratched the surface. While I look forward to unlocking the full power of the sequence editor in future projects, that surface scratching is really all I need for Antimatterator.

I may make some minor adjustments to this new title screen, but this is definitely the final version.

Oh yeah, I mentioned the original placeholder title "art" I used before making an actual title screen? And how I don't think it ever showed up in any of my update posts?

Here you go! Version 1!