Dr. Teranta's 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.

Remember in that post I made celebrating the squashing of that particularly infuriating bug when I said that thing about how the new secondary hit box perfectly follows its creator Anti wherever it goes, even through nanotubes?

"Each Anti creates its own secondary hit box, and each hit box stays perfectly centered over the Anti that created it regardless of where it moves (even through nanotubes.)"

Yeah, that. Well, it was true AT THE TIME.

While I was capturing video of that nanotube level to show off the new effects I added, I ran it once or twice just for the heck of it. (I cut those runs because they weren't really what I was showing and they just made the video longer.) I distinctly remembered from testing this level before that there were certain arrow placements that would cause the anti to hit the reg and trigger a failure, but that didn't seem to be the case anymore.

It sure looked like they were having an impossibly close call, though, and I began to suspect something was happening to the anti's hit box. I set up arrows to deliberately direct them into a full-on collision, and...nothing. They passed right through each other.

I tried a different level, and the collision worked fine. For some reason, it seemed the secondary hit boxes suddenly decided not to play nice with the nanotubes anymore. I turned on the red boxes again so I could try and see what exactly was happening. The anti had its red box going into the tube, zapped over to the exit, and the box was gone. Not stuck, not offset some arbitrary amount from the anti, just gone!

For once I have good news. I pulled up the code for the secondary hit boxes and *immediately* spotted the problem. To make sure the box gets destroyed along with the parent anti when it gets collected, I did something that was- in hindsight- very lazy and stupid. Since the box is always supposed to be centered over an anti, I basically just told it "if you ever stop detecting collision with an anti, delete yourself."

That way, when the anti gets destroyed after being counted and collected, the box would no longer detect collision with it, and remove itself. I didn't want the boxes hanging around and potentially causing other issues down the line. Especially because when the anti does get destroyed and no longer has coordinate info for the box to follow, the box tends to bug out and jump to different tiles around the collector.

But guess WHAT ELSE causes a 1-frame break in contact between the anti and its hit box? Yeah. Going through a nanotube. Because doing that instantly sets the anti's coordinates to those of the tube's exit. Normally the hit box would catch right up as if nothing happened, but under my stupid new code that single frame was enough of a lapse in the collision detection for the hit box to notice and take itself out.

I fiddled around with a few different ways to either fix the box's jumping around when the anti gets removed, or adjust the code that destroys the box so teleporting wouldn't set it off.

I was over-complicating it. Like a lot. I just made the "destroy the hit box" code trigger when the anti goes into the "gotcha" state. (That's what I named the state for an anti having entered a collector and playing out its little animation before it is destroyed and counted by the tracker.)

Basically, the box gets destroyed as soon as the anti enters the collector, rather than waiting for the anti itself to be destroyed. This actually solves both problems. Since the box gets destroyed before the anti, it won't stick around or jump to random tiles.

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.

More animation updates!

(Can you TELL how excited I am to get back to working on the fun stuff after finally fixing that damned turning bug?)

Just like the Antis entering the collectors, I'd always planned to eventually add some kind of quick little animation or something for returning the arrow panels to the tray. The instant teleporting was functional enough for development and testing purposes, but a little extra something was on the to-do list from moment I got it working. (Just very low on it.)

First I tried making them fly back to the tray, but it was extremely buggy and either worked, partially worked, or didn't work at all depending on how far the panel actually was from its starting position. They would frequently overshoot and over-correct trying to get back to the exact pixel, never actually managing to hit it and ending up stuck in a loop.

Even setting the speed to 1 (moving 1 pixel per frame) didn't work 100% of the time. (It also made the panels move agonizingly slow, so even if that DID fix the problem, there was no way I was going to keep it like that.)

I fiddled around with various numbers and code, but never found a setup that worked. So I switched gears.

The "teleport" worked. It consistently returned a panel to its exact starting position no matter where it was on the board. Why don't I just make an animation of the panel disappearing from the board, execute the teleport while it's invisible, and have another animation show it reappearing?

My first idea was to have it flip over like the tile is on a hinge, but I couldn't quite get it to look right. There's also the fact that the board's pattern would require two versions of this animation (one for flipping a blue tile and one for a purple tile) , and some way for the panel to know which one it's on so it can play the right one.

Thinking back, I MIGHT have been able to make it work with a single animation by making careful use of different opacity levels similar to what I did in the animation I ultimately went forward with. Maybe I'll experiment with the idea a little more.

Instead of trying to flip over the tile, I decided to make it appear as though the tile is pulled down with the panel on it, and a new tile closes over it.

So now when you right-click a panel (or use the "reset all" button), it plays this animation, teleports back to its starting position in the tray, and plays the animation in reverse.

I think I might try adjusting the timing a little bit so it waits a frame or two before teleporting, and do something different for the reset button since it looks a little strange when they all reappear at the same time. Maybe have a little shutter close over the tray and open after the panels return.

Real updates and not just bug fixes this time

Well, some of them involve *minor* bug fixes, but they're mostly incidental. As you can see in the screenshot, there is now a screen that displays the level number and name of the level IN the level.

It occurred to me that the only place the player actually sees the level names and numbers is in the level selection screen. If the player goes directly to the next level after completing the current one (which they are given the option to do), they won't know what it's called.

Since some of the level names might include subtle hints about how to complete them (and it's generally nice to have an idea how how far along you are in the game), I thought it might be a good idea to include that information somewhere in the interface.

I've also implemented one very minor but very noticeable graphical tweak. I've offset some of the sprite animation cycles by random amounts, so now they won't all perfectly sync up.

I noticed this as a side effect when working on the level maker. Because an object starts animating as soon as it is created, their animation cycles all de-synchronize simply by being created at different times. This wouldn't normally happen in the game because the levels are built in the room editor, so all objects are created and start animating on the first frame of the room loading, and thus always sync up perfectly.

I really liked how the de-synced animations made everything feel just a bit more natural and less stiff, so I wanted to make that happen in the actual game. It was very easy.

I just added a single line in each object's creation event that told it to start animating on a random frame of its cycle, instead of starting at frame 0.

Minor fixes:

Finally figured out why text alignment was so janky and fixed it.

NO BUT FOR REALS THIS TIME

The turning bug is ACTUALLY fixed this time and I can throw that whole hit point epiphany right in the garbage because that was NOT the answer at all.

It MOSTLY worked. It fixed the turning bug, and as far as I could tell also prevented the player from bypassing collisions by directing Antis and Regs into each other.

MOSTLY. The new code for triggering a failure required the Reg and Anti hit boxes to be in contact for 3 frames, rather than triggering the instant they touched. The problem is that SOMETIMES- and ONLY sometimes- Antis and Regs could still pass through each other because I GUESS the timing of their movement ended up putting them in contact for less than 3 frames!

I ran so many tests and it was consistent. There were always particular tiles where placing the arrow would cause the Anti and Reg to pass through each other, but moving the arrow to an adjacent tile would cause them to correctly collide. (On the plus side, I learned a lot of useful debugging tricks in the process of trying to figure this whole mess out.)

I put the project down again for a few months and waited for another random brainwave to hit me. Which happened last night at around 1 in the morning.

The PROBLEM is basically only happening because of the size of the particles' hit boxes. I can't change the size of their hit boxes because doing that caused problems with wall and arrow collision detection. Sometimes particles would pass right over an arrow without changing direction, or get bumped into the wrong row or column instead of following the arrow. (They also tended to bounce off walls before turning if the hit boxes were too small, but as far as I could tell this bug was purely cosmetic.)

So I can't change the hit boxes...

I can't...permanently...change the hit boxes...

Can I TEMPORARILY change them?

Long story short, the answer is probably "yes," but I didn't actually end up having to go quite that far. Rather than trying to adjust the Anti's hit box on the fly, I thought "Why can't I just make a separate object and have it ACT like a hit box?"

I can make this secondary hit box ONLY check for collisions with Regs, which means I CAN adjust its size without breaking anything!

It took a fair bit more experimenting than I expected, but I eventually got it all sorted out. Each Anti creates its own secondary hit box, and each hit box stays perfectly centered over the Anti that created it regardless of where it moves (even through nanotubes.)

From there it was a simple matter of removing any code related to Reg collision from the Antis (including the remnants of the I-frame and HP attempted fixes), and telling the Regs to trigger the fail state if they collide with an Anti's secondary hit box rather than the Anti itself!

After extensive testing, I have not been able to force the turning bug to happen again, so I think I've actually got it this time!

Intro Scenes

Seeing as I've just overcome another major technical problem, it's time to have some more fun with the creative stuff.

And by "have fun" I mean "take this opportunity to mess with certain people known for getting unreasonably angry and hostile when a video game so much as acknowledges the existence of demographics beyond their own."

Your answer to this question in the intro scene will change absolutely nothing in the game. Dr. Terranta will only refer to the player with some variation of "my new assistant" in any of the few scenes where he isn't addressing the player directly.

Unless you happen to pick that last option, that is. If you are indeed offended by "wokeness," (or just a curious gamer wanting to see if anything happens), you will get a short bad ending. The scene will cut to a few weeks later with the player still not having heard back about their application. It's safe to assume they didn't get the job. The game will then close.

There are quite a few games on my Steam wish list that I would likely never have heard about if not for so many troglodytes directing so much indignant noise at the developers for daring to so much as suggest that in their games' universes, people exist. I'm sure I'm not the only one who looks at "anti-woke" Steam curator lists to see what games they're attacking and add a couple good looking ones to my wish list.

So if a brigade of moronic, hateful twats REALLY want to put me in my place for adding pronoun options... Oh no! Please! Don't! I don't know if I could take it if hundreds of people suddenly became aware of my woke little single-dev indie game that relies almost entirely on word of mouth marketing because I have no budget to speak of...

That would be an absolute tragedy.

Just the worst.

I MIGHT have just fixed that problem I've been talking about for the past few posts. Still have to do more testing and make sure my fix didn't blow up something else where, but it's looking promising!

I was trying to figure out how to give the Antis a few frames of invulnerability after they change direction so the brief overlap with the Regs' hit boxes wouldn't trigger the fail state just because they happened to be following too closely behind.

This worked, but I later discovered had an unintended side effect of allowing the player to bypass the collision entirely by simply directing Antis INTO Regs. Since the whole concept of the game is "DON'T DO THAT," it meant I had basically traded one problem with close-following Regs for another.

I spent half the day trying to figure out how to get the Anti to detect if a Reg was directly behind it, thinking I could work that into the I-frame setup somehow. I did figure that first part out, but realized it was a complete waste of time because the "turning bug" only happens when the Anti, you know, TURNS.

If the Anti is moving UP, it is looking DOWN for an Reg and will detect it. But if it then turns LEFT, it instantly stops looking DOWN and begins looking RIGHT for the Reg. Since the Reg hasn't made that turn yet, it is still DOWN from the Anti, but the Anti isn't looking DOWN anymore because it is going LEFT, which means "behind" is RIGHT.

I had closed down Game Maker because I was ready to call it done for today, and sat there in my chair for a couple more minutes processing everything when I suddenly said a very specific phrase in my head:

"The collision has to actually happen first or the other part doesn't work... "

"The collision has to happen first..."

I was putting all this effort into figuring out a way to selectively stop or delay the collision from happening because the collision alone was the trigger for the fail state.

"The collision has to happen..."

But it doesn't have to trigger the fail state!

What if the initial collision instead triggered some kind of secondary process that could be interrupted or reset before actually activating the fail state? Like a countdown that starts the instant an Anti makes contact with a Reg, but resets if they break it before it hits zero? That could give the Anti enough time to complete a turn and move out of contact with the Reg behind it, but should no longer allow it to bypass the Reg by running directly into it!

ALL I HAD TO DO WAS GIVE THE ANTIS HIT POINTS.

Basically, an Anti has 3 HP, it ticks down by 1 for each frame the Anti is in hitbox contact with a Reg, and as soon as contact is broken it instantly regenerates to full. HP hitting zero is now the final trigger for the fail state.

This does make Anti/Reg collision a bit more forgiving all across the board, though. I may have to come up with some tighter level designs to compensate.

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?

Adding something new breaks something else.

It occurred to me that adding an animation for the particles entering the collector would extend the time between the last particle of a level being collected and the "win" condition triggering because the counter doesn't update until the last particle object is actually "destroyed", which now happens at the end of that animation. And because the win trigger is also responsible for pausing the Regs' movement, they can continue move for a brief moment while the animation for the last Anti plays out.

I thought, "What if a Reg was directly following the last Anti and collided with the collector while the Anti was still in its animation before being destroyed and counted to trigger the win?"

The answer? Exactly what I was afraid of. You would fail the level even if you technically won.

The EASY thing to do would be to simply design levels where this scenario doesn't happen. All I would need to do is make sure Regs are always at least one full tile away from the Antis, but I don't want to limit potential level designs.

So I actually fixed it. I just gave the Regs a couple more lines of code that check if there's only one Anti left, and if that Anti is in its "being collected" state, then immediately set the Reg's speed to 0.

Problem solved.

EXCEPT NOT REALLY BECAUSE APPARENTLY I *STILL* CAN'T HAVE THEM FOLLOW ANTIS TOO CLOSELY.

I can't BELIEVE in all the time I've spent finagling the hit boxes that I never thought to test if they'd overlap while making a bloody turn! So yeah, turns out if a Reg IS directly following an Anti, and the Anti makes a turn (either by going over an arrow or bumping into a wall), their hit boxes overlap and trigger a level fail.

I'm really happy with how this animation turned out, and a little annoyed that I rushed to capture that video before fixing the bug that was keeping it from playing properly.

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.

Done:

Added the ability to skip the intro animation for the title screen by pressing the spacebar.

The invisible menu buttons that appear in the top left corner of the intro animation are disabled until they become visible.

Adjusted the placement of some text objects to better line up with graphics behind them.

Need to do:

Noticed that the zap effect for nanotubes is now appearing beneath the nanotubes instead of on top of them as intended. Need to figure out why this suddenly started happening.

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!

(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.

Yes, I'm procrastinating again. I was never 100% committed to the current title screen, so I've begun the process of redoing it. I do like the pixel Dr. T. I made for it, so I'd like to keep at least that. Thinking about putting him on the big screen there, but I was also thinking about putting the buttons on it, so I dunno.

This is just the render I plan to pixel over and add more details and animated bits. I like the idea of the bright screen glowing with darker, more dramatic lighting, but I'm not sure that will really fit with the brighter tone I've been going for.

I AM making (slow) progress on the levels, and I added a tutorial/hint system for the 5 I've got done. They're basically just the tutorial levels, so they explain the basic mechanics along with level elements as they are introduced, and also some less obvious tricks the player will need to make use of as the game progresses.