🎮 Game Dev Adventures 🎮

Decided to make good on my interest in video games and program one myself. I've tried to make it happen before but I believe if I put my progress onto the website then having that there as a reminder will force me to be more productive. Anyway, the game is going to be a beat-em-up because that's what I seem to be aching to program. At present, the game is very no-frills, there's no actual combat but a lot of important functionality has been implemented already; the characters themselves are sprites moving on top of the tiny section near the feet, and the black squares are keeping the characters on the bottom of the screen much like a proper beat-em-up. The rectangles near the bottom are placeholders for collision detection: the idea is the hitboxes/hurtboxes I'm going to implement cannot register on a character unless both of those rectangles are intersecting.

This wound up being a profoundly unlucky week for getting work done on this project for reasons I'll get into on the blog tomorrow. The biggest thing of note is that I've made progress! in this case, I've concluded the player character of the game is going to be a hockey player (I know he looks like a guy in Mega Man cosplay right now, you'll just have to believe me on this one), and I've been using clips from Shoresy to influence how their character should move and behave. I managed to draw and implement an overhead punch (the red particle in the dude's midsection is supposed to be a hit spark). However, this is yet another classic instance of me trying to put the cart before the horse because I'm not even through the prototyping phase and I'm already trying to move on to sprite work. I've concluded that what needs to happen next is to get some free assets to act as placeholder animations for characters, AND to get a stronger grip on how the animations ought to move so that the game feels good to play.

The project continues, but sluggishly. Making animations work in this program is simple, but getting the willpower to properly set everything up while also juggling an insurance claim and recent dental work (to say nothing of getting absorbed into Hades II) has proven a whole mountain to climb by itself. I hope by next week to at least have something I can put into a GIF file that looks like something akin to a video game. The only other thing of note at present is the Clickteam Fusion program having a preprogrammed "8 Directions" player movement that has been invaluable for prototyping but also includes extreme acceleration and deceleration that's at odds with how beat em up movement works in general, and so that will be something that will need to be patched out of alpha sooner rather than later.

Everything in my adrenal gland says to berate myself for the relative slow progress I've been getting, but I'm going to fight that urge because I'm thrilled to report that I made it to the first 'checkpoint', to use the McFunkypants method, and take pride that what I have here is technically playable. You move around, punch a guy, he falls down, gets back up. It's a gameplay loop! You can't say it isn't! That all said, with more progress comes more problems, and one specific problem I'm wanting to focus on this coming week is how to integrate variables into the current loop. Part of some of the current jank, like the player character walking in place and the hitspark occuring multiple times in a row, is due to the code relying on the animation frames to tell the program when to terminate a process. That means for every power jab the PC does to the NPC, a hitspark happens for all six frames of animation. That's not even getting into animation based code making any smooth walking/stopped transitions possible, but that's a headache even in programs like Unity so I don't hold that against Clickteam. At any rate, the goal now is to get into variables that alter how enemies take punches, how many hitsparks play, all that good stuff!

Mostly mechanical work on this go-around. I've successfully implemented a flag that prevents the Power Jab animation from causing a point of damage for every frame run, so now it runs more like a proper beat-em-up: that is to say, punch a dude three times for a knockdown. They get back up and the punch counter resets. However, I've run into a pretty major snag in the sense that I have no way to make the punch counter lower over time. I've tried timer events but the issue there is the timer event won't actually stop and just keeps firing off no matter what, and a fastloop isn't the solution either because the fastloop has the same problem where it doesn't actually stop running when I need the loop to be done. But! Using this platform to talk about it, it hit me what the solution here is: timers as progress bars! I still need to implement health bars anyway, so I think what I'll do is implement a bar that fills up to max when a hit lands on the enemy, and whenever the bar drops to 0, the punch counter resets to 0 as well! Full steam ahead!

Very little done this week, I have implemented a health bar/death condition for an enemy having their health bar depleted. I've pretty much hit the extent of how far I can push the current build without an enemy that poses a threat; I will have to spend this coming week figuring out how to make moving and punching work on the enemy.

The current build has an enemy that follows the player on the X axis but not the Y axis; I have yet to implement the enemy attacking because the first time I tried ended up making multiple things break, including the player animation and the punch counter I'm so proud of. I'm also on the tail end of finally being done with my car situation, so that's been eating up a lot of my attention. Still, this has plenty of promise so far, and now that the player-following behavior has parameters set in, I can start thinking about how a typical enemy will approach the player in a beat-em-up, because I could just have them zoom right to the player's location but then that's just a bullet heaven enemy. I'm thinking of the possibility of a cone of vision to implement, some kind of way for the enemy to have character variables, such as more cowardly guys only moving in when your back is turned.

I hate to admit this, but I can't deny it any longer - coding AI for beat-em-up enemies is a little too advanced for where I am right now. So, until then, I'm going to focus my attention on something a little less complex like a horizontal shooter. Right now I have a system that randomly generates enemies coming from the right, though nothing beyond that. I also have a tiny little bit of progress of something brewing in RPG Maker 2003. It might become something, though it might not. I have no idea.

Progress is going smoothly on the shooting game! I have a background, two enemies - one moves straight and one goes in a sine wave - and I have the setup in place to program the levels based on the timer. Of course, it's not all going smooth, as the sine wave enemy keeps going further and further up with each wave. Oridinarily I'd just attach an object to the enemy that stays in place so the sine wave formula has a stable X axis to work with, but I'm not in Unity anymore. (Also when I tried that here, the result of the enemy being shot positively broke the game). It's a very basic setup and I absolutely need more stuff in here to make this a game, but I'm wondering just whether it's possible to make something cool with just what I have right now, without any other major additions.

As a response to my own question last entry on whether i can make something without other additions: I can, but the result is a little on the bland side. The main problem is that my hat guys - the main 'popcorn' enemy of this shump as it currently stands - simply moves forward in a straight line, no fancy movements or guesswork involved with the player. It's obvious to me that I'll need at least two other enemies to round out the early game roster, a fast enemy that makes use of the Path movement set included in Clickteam Fusion (this will be a learning experience for me) and an enemy that moves straight but fires bullets at certain intervals. The enemy placement so far is about 10 seconds in length, and I feel confident in saying a typical shump level is about two minutes before reaching a boss. My line of thinking is to try and perform it like a song - not throwing tons of new patterns at the player but having specific patterns repeat like a chorus and then the next to last enemy pattern is the bridge and acts as the most challenging/memorable part. We'll see what happens! The only other addition to the game is a powerup that increases your shots from 1 to 2, which mainly is there to clear out any enemies coming from the front. Not sure on if I'll be getting 'options' as a powerup but it feels like a fair extension of what's percolating here.

I'm at a loss. I have even looking at this project lately. I hate even looking at Clickteam lately. I don't understand why these mechanically simple games are so frustrating to actually make. Gut instinct is to stay the course on this shump concept because I can't just keep making tiny prototypes and expect that to get anywhere, I have to buckle down a little bit. I'm considering how much being alone doing this is impacting my ability to do anything, so I feel that my next course of action is to get in some kind of Discord, either for shump makers or Clickteam specialists. I don't really have any other plans beyond that.

Alright, decent progress this week, there would have been more but the Doom + Doom II Nightdive remaster came out this week, and, well, yeah. At least it's a fun reason instead of the sad-sack reason from last week. Anyway, I finally introduced enemies that fire at you - at present, it's just a straight line but it requires the player to prune the enemies before their bullets overtake the screen. I also introduced a shield that causes the players' bullets to bounce right back at them! I'm thinking these will be how the player has to strategically fight in boss battles by using these shields to avoid getting shot by their own fire. I have to be careful, though, because at present this game is completely different from the average shump in that firing the gun doesn't feel empowering so much as a necessity. But I'm okay with that! Once the first level is complete, I'm going to see about graphical updates and maybe leaning into the aesthetic that play style implies.

Alright, so I think I'm at a point where the game is almost presentable as far as gameplay is concerned - the level is 60 seconds in length, which was not what I predicted would be the length but my gut instinct says to put a boss after the minute is up because it feels right. Only real situation now is creating a boss that has a health bar and enough pattern trickery to get some mileage out of the current gameplay loop. I also introduced a new sprite to replace the default triangle so now it at least feels more like a video game. My plan for the boss is to have it be a giant ship that takes up the screen, made up of several individual sprites that you explode over time. My goal there is to have more of a Raptor: Call of the Shadows gameplay by introducing bigger ships and possibly space debris to shoot through, just little touches to make the game more fun.

We have a boss battle! It's not nearly the flashy looking boss encounter I had pictured in my mind, but it's totally acceptable as far as a starting level boss goes! This means that all that's left is to have a Level Clear sign, and a menu screen, and this game is officially past the first major checkpoint in production! Of course, once that's all said and done, the real work of keeping up momentum will begin. I already have a list of things I want to learn and improve at for the second level, but for now I've earned a pat on the back :)

So, with the first level basically looking how it's going to look, it's time to figure out how to make this feel more like a video game. The first major change was to alter the bullets and how enemies absorb damage. Before, the yellow shots coming from the player destroyed the enemy in question automatically, but hitting the button every time you want to shoot is a chore. So, now we have a spray of Raptor: Call of the Shadows style bullets that not only take a certain amount of health off of each enemy but make a lovely arc whenever you serpentine across the play area. I've also added a rudimentary homing bullet, shown here. They don't turn to face the player and they give up pretty much after getting past the player's position on the X axis, so they're more like heat-seeking missles at this point. I'm thinking my next plan of attack is to make some kind of options function and trying to get at least the first ten seconds of level 2's gameplay figured out.

I have a terrible habit of dropping a project altogether whenever I hit a wall or don't know what to do - "you're not doing this right, so just give up". I run into a single problem where I realize I have no idea how to make homing bullets work and as a result, it took me two weeks to get back on the horse. Thankfully, I did enough preliminary work looking up trigonomotry to understand the problem was that I needed an Atan2 function to lock onto the player. Special thanks to ptiseignuer for basically gift-wrapping the code necessary to make this design work: https://community.clickteam.com/forum/thread/80293-angle-atan2/. So, I have at least cleared a hurdle - if only the design for this next level didn't feel like 'draw the rest of the fucking owl' to me. Oh well!