listen to me shout into the abyss

7/5/25 - my quest to become a medicore programmer and game dev: first entry of my devlog

for about a few months i've been on and off working on a game using my pixel art guys. i've decided to log my progress here. i don't know how often i'll update this, but it probably won't be very consistently unfortunately since i barely update this site. but i mainly wanted to make this because i wanted a place to put my little progress videos. but i may use this page to write whatever i'm feeling so it's basically a public diary.

the godot phase

so i first started making the game in godot. i started it somewhere around last april i think. it was supposed to be a sort of remake of a unity class project of mine with extra features. basic retro style action/beat 'em up game with platforming elements. i use beat 'em up loosely as this is based off of stuff like kung fu master and trojan for the arcades. earlier beat 'em up style stuff. you can only go left or right like you would expect from a platformer. no combos or anything just basic attack, jump, and crouch. but in this version i improved the state machine a lot instead of using a bunch of if else statements and switches. made it relatively easier to add states like dashing, sprinting, and walking backwards. i also added 3 jump heights: short hop (tap jump), regular jump (hold jump), and super jump (down and jump). on top of that, it was designed to be versitle so that it can handle the input of an ai controlled character. this meant that i could theoretically make every enemy playable since every character used the same state machine system. i was probably getting a bit too ambitious. i wanted to take inspiration from fighting game design. and i shortly learned that those are deceptively hard to make.

after beginning on collsion detection, i ran into some problems with godot's physics engine. i wanted to prevent players from running through enemies, but still be able to push them around. i also wanted to prevent players from standing on the heads of enemies since their collision boxes were squares. now, i could have used a diamond shaped collision box, but then that would require me to add an additional one for platforming. i had to figure out how to do soft collsions, but i didn't really understand godot's physics engine very well and realized it is way more complicated than it needed to be for the kind of game i was trying to make. there's also this small thing that really bugged me about detecting collisions of an intangable area for my hit and hurt boxes. they are registered 2 frames late because of how godot's signal system work. i'm sure there are work around for it. i've seen other fighting games and stuff made with godot. but i really didn't feel like figuring it out. is it a bit obsessive to focus on this tiny detail? maybe. but those 33.3333333 miliseconds matter to me so i abandoned this project.

but then i had an awful idea. what if i made a game engine? i took a single class for c++ a couple of years ago so i'm sure nothing will go wrong.

so i started making a game engine and nothing went wrong

for about a month or so i've been inconsistently working on the new game engine. it was a struggle to even figure out how to render graphics onto a window. had to find a bunch of youtube tutorials. but hey, i managed. sdl made things a bit easier for me.

after i got that figured out i started with a bunch of boring stuff like basic input detection rendering png files, window resolution, and probably some other stuff not worth mentioning like relearning how c++ works. i wanted to lock the framerate of the game to 60 fps. turns out i have been calculating it wrong since pretty much the beginning of the project but i just didn't notice because i've mostly been using delta time for all of the things so far. all i had to do to fix it is flip the numerator and denominator in the equation. though i am honestly not sure if my calculations are completeley accurate still based on some testing. i need to look into it more. i'm not sure if i necessarily need to cap the frame rate either if i'm just using delta time. originally, i was going to count animations and attack lengths and stuff in frames but i could probably just calculate the timing in terms of delta time instead of having to cap the whole game. i also just thought it would make the game run better, but i'm not entirely sure if that is true or if it would make much of a difference. i'm not planning to make any huge games with this engine. probably going to be limited to 2d retro style stuff.

my game engine also needed to be capable of very basic, simplified physics. that meant i had to touch up on physics to invent gravity and simulate velocity and acceleration. i still have to tune velocity and acceleration a bit since i haven't really figured out how to do linear interpolation properly yet. not sure if you are able to notice in the later movement test videos, but when the player character goes into idle state, the deceleration sometimes does not work properly and instead of coming to a complete stop at 0 velocity, he just moves in very tiny increments back and forth. probably because of some rounding error. i'm not sure why this happens yet because the code does round the velocity after it is calculated, but i am still looking into it. i also am just still rusty on physics calcuations.

some other notable things i've been working on is the general structure of my systems and translating the state machine from godot to c++. it was originally programmed in c# so it wasn't too bad of a conversion, but i did utilize godot's node system, so i had to replace it with a system of my own. fortunately, i was able to salvage the capability of switching out input systems so that any character is playable as long as a player input component is passed through it. basically, the input system is am abstract class that carries variables representing each button press and directional input. both the player input handler and npc ai scripts are derived from it. i like to think of these scripts as the strings that each puppeteer uses to control their little guys. and since the state machine reads the input from a npc ai script or a button press in the same way, both options are interchangable when controlling a character and performing an action. there is this really weird bug with the ai right now though where it initializes holding down the right input by default. i have no idea why this happens because the constructor specifically sets it to no direction input. weirdly enough though this did help me find a different bug where if a character starts in the falling state while holding right or left, they will immediately move horizontally at their max horizontal velocity instead of it incrementing like intended.

also if you're wondering why the ai in the video below is just running around in circles, it's because it doesn't recognize the character i'm using as the player. i literally just swapped the inputs in the code to test if i can control the npc.

daydreaming about game deving

i really want to make a beat 'em up fighting game platformer hybrid at some point. that is my end goal here after learning all the fundemental programming stuff i think. i want to learn from a lot of different games. there are some weird cases i like to look at such as double dragon on the zeebo. i doubt anyone reading this knows what that thing is. i don't either. but it has a pretty solid port of double dragon on it. it has juggle mechanics. every enemy and boss is playable too, which kinda made me want to do something like that. there is a boss character that does not appear anywhere else in the series to my knowledge. but to be fair i don't follow the series that closely. it's kinda funny how out of place that boss feels too since the series is supposed to take place in a mad max style apocalyptic setting and suddenly you have to fight this katana wielding white haired anime girl in a fur coat.

mortal kombat mythologies: sub zero is also an interesting case to me. it has a really bad reputation, but the novelty of combining fighting games and platformers isn't something i see in a lot of games. the turn around button is a very wacky choice to me that i find really funny. that's why in my original godot game i had a button you can hold for walking backwards. it was originally going to double as a block button. i probably would have added an option to make it a toggle instead of having to hold it down if i kept working on that. it also kinda comes from being able to walk backwards in castlevania rondo of blood by holding down the whip button. castlevania (and a little bit of bloodstained) in general has been a big inspriation for this if you couldn't tell by me basically ripping off its art style. as much as i do like the metroidvania ones, there is something about the methodical combat of the old games that is so satisfying to me. makes me want to reimagine it as a beat 'em up, kinda like the 3d ones but if it stuck to its classic 2d roots. the combat already has that emphasis on spacing and timing your attacks properly so you don't get smacked for missing. kinda like fencing almost. but if your opponent was trying to back you up into a death pit.

what am i doing with this thing

so it probably isn't wise to jump straight into designing a whole beat 'em up/fighting game combat system with my game engine. even though i kinda structured it to accommodate for something like that. i've been wanting to make something simpler just to help me ease into making games a bit more maybe. what i had in mind is a simple arcade platformer. what i have so far in my engine definitely is overkill for something like that. i could just use a switch statement for the state machine instead of the whole class system i have going on right now. i've been looking at games like annalynn by cruise elroy and darkula by locomalito as inspiration. i obviously also have been looking at some 80s arcade games as well but i wanted to point those two out specifically because i really liked them and think they are charming. i'd recommend giving them a shot. i want to use those cute chibi versions of my characters for my simple game. after i refine the movement system of my engine a bit, i need to work on actual collision detection and tile mapping. i hope those won't be too difficult for me to figure out. i also really need to figure out animations. i think i have somewhat of an idea on how to do that though.

back to top