After days o’ not being able to do anything useful, I had a certain programming binge the past day or 2, which involved restarting a 2D platformer game I’d been starting o’er & o’er ’gain since 2014, since I’m anal-retentive. I’d always tell myself I should blog ’bout it, since it’s obvious that this fiddling isn’t going to be useful in any other way, & this is the best opportunity.
This time, rather than my usual anal-retentive strategy o’ carefully crafting complex class & component systems that were elegant, but empty o’ content, I started simple, focusing primarily on getting the player’s physics right, with the only extra tinkering being visuals, since they’re important for seeing reactions to physics (the screen-magnification system, so I don’t have to squint to see everything, & movement animation, so I can better gauge the player’s movements—I don’t know). This is based on a principle I read ’bout called “YAGNI”: “You Ain’t Gonna Need It,” which I read ’bout from some great website full o’ nifty programming tips whose URL I sadly can’t remember anymo’. That’s the perfect time to show off my code so everyone can see what a sloppy mess it is.
This project’s done in C++, the sloppiest o’ programming languages, but 1 I’m strangely better @ understanding than s’posedly “easier” languages, like JavaScript.
The problem is, e’en in only a day, I’ve done so much—& by “done so much,” I mean copied & pasted a lot o’ code I already did from my earlier projects (this experience o’ copying & pasting the good parts from older projects is what taught me that refactoring isn’t nearly as hard as I 1st imagined, which makes YAGNI easier to apply).
-
Master graphics object that holds basic SDL graphical junk, as well as simple spritesheet system for loading graphical files, which can easily be referenced by sprites through simple enums (androgyn, do I love enums).
-
Includes simple magnification system I’ve been copying & pasting since 2014 that simply reads the computer’s resolution & uses that to automatically magnify the 256 x 192 pixel screen to as big as will fit evenly in the monitor, as well as automatically centering it.
-
Simple graphics & movement components for sprites, which are only used by the player. To make things ’specially wasteful & redundant, sprites have a built in simple rendering function & variables that are used if said sprite doesn’t have a graphical component, for blocks, since I didn’t feel like making a graphical component for them, when they probably won’t be sprites later in development, anyway. It’ll take a minute or so to delete the redundant function & variables.
-
Input system that abstracts button presses from actions.
Most o’ the code is crammed into the sprite class, & almost all o’ it is the physics o’ the player & collision with sprites o’ other types. So far, the player can run, jump, & duck as well as I can imagine, & has working collision for solid blocks, those strange blocks that are only solid on top (those cloud platforms from Super Mario World), & ladders (ladders are still somewhat wonky in that the player falls off if she climbs ’bove the ladder & has no climbing graphics).
I have mixed feelings ’bout the collision code. I used to use this simple formula I got from some book years ago, but I found that finicky, so I replaced it with a mo’ complex collision system I borrowed from Sonic games. In this case, the sprite has collision dots for each side & tests whether those dots are within a certain boundary box within the other sprite. The way this is actually done is immensely messy, with many probably-redundant integers; but I’ll worry ’bout cleaning that up later. It does seem to work well: so far I’ve yet to see clipping while walking o’er flat land (bumping into the sides o’ the corners o’ the blocks) or being able to land on the corner o’ a block in a vertical wall, which took far longer than one might expect to fix.
Also, since I kept changing the collision system, the collision class is full o’ redundant variables that’ll need to be cut out later, when I decide which collision method to stick with.
1 problem while trying to research solutions is that I can only find the most basic tutorials on the internet, not any advanced problems, such as handling trying to stand up from a crouch while in a small vertical space, which took almost the whole day fixing, or the best way to handle climbable blocks.
Also, much o’ the advice given is terrible or inaccurate. Don’t get me started on the tutorials I’ve seen that advise creating enemies like Red Koopas by putting invisible blocks solid only to enemies on the edges o’ every platform to keep them from falling off, rather than actually programming the enemies to detect edges. That’s god awful, & one can be assured that no Mario game e’er did something so dreadful.
Other than fixing the ladder quirks & cleaning up my code a bit, I’m not sure what to move onto next. Most likely creating a block system, which’ll ’ventually be a pain in the ass, since it’ll probably require creating tilesets o’ block types, as well as graphical & collision components. ’Gain, I want to keep myself from building too much architecture @ once, so I’ll probably just start with a simple block system.
& after all that, we have a map system, a camera system, & the fun that is a system that reads an array o’ #s & creates blocks in the right places.
I had the idea o’ putting this up on Github, only to realize that that’s based on, duh, Git, & I don’t actually know how to use Git, despite how useful it apparently is. Perhaps I should learn how to do that later. For now, I have just a dumb archive file with all the code. I would’ve also attached a video ‘stead o’ a lame screenshot, but I can’t get my capture software to make videos that don’t look like slideshows.
Download code & see it in all its sloppy glory.
