Welcome to the first Deepvelopment Monthly blog post, this time covering March 2015:
Ultra Friction: -Content
Remember way back in that first video of Deep, one of the first Microchips I showed off was called Ultra Friction? It’s still a pretty important one in the game, it allows your robot to climb up walls by pushing up against them. Falling off edges though was hard, because sometimes you’d want to just fall normally and sometimes you want to attach yourself to the side of the cliff and walk down the wall. You can now choose! Fall normally just by walking off, or hold the down key as you walk off the side to attach yourself. You can even do it on thin platforms, check it out:
You can also jump while on walls now! Obviously you detach yourself and don’t get to keep climbing the wall but I coded in some specific physics and momentum stuff for if you jump while attached so it feels really clean and smooth. Jumping while on the underside of a thin platform lets you do a little hop back up on top, which I think is pretty intuitive.
It’s worth mentioning that while I was trying to get all of this to work, the sloped terrain detection subsequently broke and fixed itself about 30 thousand times.
Ultra Friction… Bugs: -Glitches
However, I spent a LONG time dealing with this very irritating and inexplicable bug where if you walked off the right side of a cliff, the game would magically snap you back up into the wall and you’d just casually get sucked away into the wall.
So yeah that was cool. It works now though.
Zipping: -Programming -Glitches
There’s a cool physics thing that a lot of platformers, especially older ones on the NES, are known for doing called Zipping. This is where the game will detect if your player character is stuck inside of a wall and automatically push you a set distance away from the wall each frame until you’re no longer stuck. This was also accidentally very helpful for Mega Man speedrunners, who abuse it to rocket Mega Man off towards the end of a level at ridiculous speeds! Obviously being in the wall to begin with should never happen, and I’m fairly certain there’s no way to do it in Deep, but the Ultra Friction glitch I showed above got me thinking that I should code something as a failsafe to catch corner-cases like the above (no pun intended). I’ve found in development it’s always just smart to assume that basically anything you don’t think is possible in your engine probably is and you should code something to subvert it in case it happens. Now, after some very silly testing period bugs where just landing on a platform would make your robot vibrate all over the place because the game was worried you were inside the floor, I have a pretty solid zipping system! If you’re inside of terrain at all, the game checks all corners and sides of the robot to see which is closest to NOT being stuck each frame, and moves the robot a small amount in that distance each frame!
Outlined Objects: -Visual
Remember in old cartoons like Tom & Jerry where you could tell which parts of the set were going to be interactive and move and do stuff, because they had that really distinct brighter colouring and thicker, sharper black outline? I always thought that was really cool and I’ve implemented something kind of similar in Deep’s graphics engine!
I think it looks pretty cool! All objects that can dynamically move around have this effect applied to them, including projectiles and collectable items as well.
Debug Tools: -Programming
This is fairly simple, but very helpful and cool (and something I should have done a long time ago!). The game now has incredibly precise debugging tools for me to use, which let me pause EVERYTHING in the game and advance the engine one frame at a time, and control exactly what keyboard input I’m using on every single frame. This has sped up the process of figuring out what causes glitches by about x1000, since I can see exactly what frame something happens on, and exactly which input on the player’s end causes it to happen. If you’re making a game and haven’t done something like this, do something like this. Man.
Entire Engine Rework: -Programming
Alright… This is going to be a long one! This is a huge project that’s technically been underway since late February, and it’s something that I’ve needed to do since the game began. Early on I didn’t REALLY know what I was doing and the way I programmed a lot of important stuff in the engine, like how the game kept track of multiple enemies and projectiles, meant that lots and lots of unnecessary RAM was going into keeping Deep running, and made it really hard to program additional features for the engine. I’ll try and keep it simple and interesting: Basically, the game had this big (but not infinite) list of enemies, list of projectiles, list of graphical effects, so on so forth. Every time one of those things was spawned, it would take up a slot on the appropriate list. The game automatically keeps track of how much ‘stuff’ was on each list, and every frame it would go through all the lists and perform each required action (like applying gravity to the enemies, checking to see which projectiles were hitting something, etc). This seems like a good idea on the whole, but there are some major issues. The main one being that EVERY SLOT ON THE LIST has the same amount of RAM (or memory) allocated to it, even if it isn’t occupied by anything. Programs need to know how much RAM they might have to use, so any slot on the list that might have, say, an enemy in it, would have to be big enough to hold an enemy’s data. But I’d rarely (honestly never) need to use the entire list of slots, because there would never ever be that many objects in the game at once, so I’m essentially using this big chunk of the computer’s RAM for nothing! It’s also good to never assume that something is entirely impossible in your game’s engine, in case some player finds a way to abuse it. If you don’t code around that, then you’ll get all kinds of crashes or freezes or worse! So even though I don’t think those lists would ever have been 100% fill-able, the game wouldn’t have known what to do at ALL if someone did manage to spawn too many projectiles or something. The lists were a set size and couldn’t have coped with any extra stuff being spawned if they were full.
So! After a few very stressful days of doing basically nothing but code, and an entire week almost of Deep being entirely unplayable because the engine was only half-there, I’ve recoded ALL of how spawning, maintaining and working with objects in the game works! Using some clever tricks, the game now dynamically allocates only the necessary amount of RAM to take care of all the objects that are currently actually in the game (look up ‘container classes’, if you’re a beginner programmer who is interested in seeing how this is accomplished!). But wait, we’re not done yet!
Until now, because all the different kinds of objects in the game (projectiles, enemies, the player) are… well, different objects, I have had to code each of their basic functions (friction, movement, collision, hitbox interaction, etc) separately. This means when I coded in something new, say, sloped terrain, which I did just a few months ago, I had to basically write code for the same thing for each of those types of objects. Since I was rewriting half the game anyway, I took the opportunity to subvert this issue. Now at the core of the game, there is just one very simple type of object, called an ACTOR, which is essentially a single collide-able physical object of any size in the game. What I do now is that everything more complex, like an enemy or projectile, just has an ACTOR inside of it to do all of the physics stuff. Then all I have to do is code that universal physics and collision stuff into the ACTOR object type, and suddenly all the other things in the game have access to those same functions! With me only having to write them all once! Here’s my diagram from when I was working on this setup, to help explain (click to expand):