You are browsing as a guest. Sign up (or log in) to start making projects!

Unnamed Platformer

  • 10 Devlogs
  • 59 Total hours

A game where you play as a square in space, and there are 5 sets of 6 levels. For each set you begin after the first, you unlock a powerup and go to a new planet. set 2 gives you the circle power up which lets you accelerate faster, set 3 makes you a triangle and you can teleport a short distance forward to phase through walls, set 4 makes you an octagon and lets you ground pound, set 5 makes you a hexagon and you can double jump. This game was coded using C++ and the Simple and Fast Multimedia Library (SFML).

Open comments for this post

7h 7m 59s logged

Unnamed Platformer - Devlog 10

I’m tired 😭

What I did: I ported the rest of my entities over to SAT collision. Every tile that can be collided with now uses SAT. I refactored some of my functions to handle the new logic properly across the board, and got rid of the old standalone AABB collision code for ground tiles. I also decided to make pushable blocks hybrid for simplicity: aside from general environment collisions which use SAT, I didn’t change much of the old AABB code.

I also added an O(1) center/radius projection for circles to fix random micro-stutters, and updated drawdebug() so it stops drawing every vertex and instead renders one dynamic vector targeting the nearest tile vertex. (Circles in SFML are actually 30-sided polygons, so earlier the collision checks were looking at 15 different axes + all those axes were being drawn in the debug overlay.)

Challenges: Thankfully most of the porting to SAT stuff was easy, I only had a couple of minor setbacks here and there.

However, the harder part was getting the circle center-to-vertex collision logic down. I had to find out how to do it + add completely new logic to my function + add checks in my collision code to determine if the shape was a circle + rewrite my drawdebug() code. It took a while and a lot of my sanity but I got it done in the end

AI used, if any: Used AI to help debug the updated circle collision detection system + its separate debug overlay code.

Plans for next time: I’m going to work on rolling physics for real. I hope it goes well 👍

K bye guys

0
0
5
Open comments for this post

9h 3m 19s logged

Unnamed Platformer - Devlog 9

I was “busy” watching the World Cup bronze/final matches over the weekend. No way we got a 10 goal third place game while everyone started throwing hands at the end of the final😭

What I did: I finally got started on SAT collision like I said I would, and it’s actually working! Mostly. I built all the fundamentals so far: vertex extraction, edge normal calculation, projection ranges, minimum translation vector (MTV) calculation, etc etc. I hooked it into checkCollisions for ground tiles, and the MTV push resolution actually stops shapes from clipping through geometry now, and it’s also sign-corrected and whatnot so it always pushes the right direction. I also made a debug overlay that draws vertices and axis normals directly in the game window, which saved my sanity countless times and looks pretty cool too.

On top of collision math I had to go back and fix 3 out of my 5 characters’ movement code because switching to SAT caused bugs in features that worked just fine under the old AABB system, aside from all the general bugs I had to deal with. The hexagon’s double jump stopped working entirely, circle’s acceleration started randomly resetting mid-sprint, and octagon’s wall jump turned into an absolute mess (more on that below). The main thing was that my old flags for checking wall collisions were set with assumptions that crumble once you switch from checking 4 fixed direction to a bunch of axes.

Challenges: Oh boy… The wall jump bug was hella frustrating: after switching to SAT, the octagon would do exactly one wall jump and then just slide down the second, no matter how many times I hit jump. It took me forever to figure out it was a chain of three separate bugs stacked on top of each other: wall contact flags getting cleared before the function ever read them, my walljumped flag never resetting between wall touches so it permanently locked my horizontal movement, and then once THAT was fixed, SAT was re-zeroing my wall-jump velocity on the same frame it fired because the player was technically still overlapping the wall geometry. So I fixed those and immediately got a NEW bug where wall jumping turned into a pogo stick that spam-bounced me up the wall, because a vertical MTV was getting misread as “landed on the ground,” which reset the wall jump lock and let it refire every single frame.

Also spent quite a bit of time before realizing this one line I had, if (grounded) velocity.y = 0, worked fine with AABB but not so much with SAT’s own grounding logic, since my SAT function sets grounded = true when it sees downward velocity, and that line was zeroing velocity before SAT checked it. Removed it and a lot of my bugs disappeared.

AI used, if any: SAT math I mostly figured out myself, after reading through a ton of Stack Overflow threads, articles, watching a lot of YT videos, etc. on my own time. I did use AI to clarify/debug a couple of parts though. However, I ended up needing it a lot more for debugging the problems that stemmed from it, i.e. the octagon, hexagon and circle issues.

Plans for next time: SAT works for ground tiles but I’ve still got all my other entities on the old AABB system so I gotta port those over. Although, probably the biggest thing is trying to make my code more efficient because sometimes the game randomly slows down/freezes and makes random clips occur. If this isn’t lag (which it might not be, I could just be stupid) I’ll still have to look into whats happening. Then, once ground collision is 100% finished: rolling physics, aka the reason I made this change in the first place. Gonna have to look into the math/physics behind that, but it should be pretty easy since I already got this down. Once this is done, the shapes should be tipping and rolling around instead of just sliding around like ice cubes. We’ll see how that goes.

K bye guys

0
0
7
Open comments for this post

6h 51m 9s logged

Unnamed Platformer - Devlog 8

Bro idk

What I did: I finally wrapped up the character roster by implementing and debugging the last two shapes: the hexagon and the octagon. The biggest milestone was completely overhauling and fixing the wall jump implementation for the octagon (which took me like 1.5 hrs out of which 50 minutes worth of changes were discarded). I ended up shifting all the wall-jump physics directly into the jump event handler, rather than splitting the logic between two different functions (my jump and updatepos functions). This allowed me to make it so I can properly maintain and destroy momentum for wall bounces

On top of physics stuff, I built the level progression system. When you touch the exit tile, the game increases your level index and loads the next stage. It’s finally starting to feel like a real game! Although, not really, since every level after the second is the exact same weird ahh testing level cuz I needed to make sure my system worked.

Challenges: The real nightmare was the octagon’s wall jump. I spent about 50 minutes writing changes because the physics wouldn’t cooperate, only to discard them because I got too confused 🥀I had half of the wall jump math in jump() and the other half in updatepos() and it was making the normal movement code immediately overwrite/neutralize the walljump code the very next frame. Another thing was making it so you couldnt just hold down the w or up key and automatically bounce up forever. I had to add an input debounce check so you have to release+re-tap the key to jump again. Everything else was honestly smooth sailing and any other bugs took maybe <15 mins to solve.

AI used, if any: I didn’t use much AI, since the two big features I added were pretty easy to implement/debug, but I did ask it to help me a bit with wall jump logic since I was pretty fried.

Plans for next time: Now that the physics is working, I’ve decided I want to get rid of it all.

Sliding shapes feel hella unnatural (also the hitboxes are pretty weird), so I’ve decided on making the shapes roll around/have accurate hitboxes using SAT (Separating Axis Theorem) vector math. I asked Gemini how long it would take and it literally told me to avoid it if I can 😭 so we’ll see how many hairs I lose over the course of trying to implement SAT. It’ll probably be all I do from now until around the start of August when I’ll be going on vacation

K bye guys

0
0
2
Open comments for this post

6h 28m 5s logged

Unnamed Platformer - Devlog 7

I typed words into a code editor and made shapes move around :shocked:

What I did: I finally took on the shape-switching system and got it working! I had to completely change how the player class worked, so I made it into a pure virtual class to handle polymorphism (which lets me switch between different shapes) and replaced the old static player setup with a dynamic shape-switching state w/ unique pointers. For shapes so far I implemented the circle with rolling physics and friction, and the triangle which can teleport forward a short distance. Also, keeping source code in header files was causing circular include errors, so I reorganized all the player class code into a brand new players.cpp file. And finally I made it so falling below the screen kills the player, which is a pretty small feature but still.

Pretty much what was happening was that I needed to access my tilesettings.h file in my players.h class for movement-related checks, but tilesettings.h also needed players.h for hitbox/collision stuff. So I had to take out my code from my player header file and move it to player.cpp, which was lowkey a nightmare since I ran into a bunch of compiler and linker errors that took me an hour to fix😭 Anyway, Gemini helped rescue me (since my Claude 5-hour limit somehow ended after the first question I asked it today), so thanks Gemini.

Challenges: Pretty chill today, since today was more designing and testing new features that were easy to implement; however the real nightmare was splitting my files. Moving code to players.cpp broke everything with a bunch of “multiple definition” linker errors. I didn’t define my global variables as inline at first, but since they were getting defined across many files I had mark them as inline. Also, the triangle’s teleport mechanic let you phase into solid tiles at first, so I made a position prediction system using swept AABB bounds. In fact, creating this swept check was the feature that needed me to call tilesettings.h in players.h in the first place, which led to my cortisol spiking when the compiler stopped working for an hour

AI used, if any: Used Gemini to help me figure out why the compiler+linker were throwing errors, and some basic debugging in my other features.

Plans for next time: I’m gonna design my other two shapes now (octagon and hexagon), then start making this into an actual game with multiple levels, progressing to the next level when you reach the finish, etc etc. Also, I feel like the sliding movement is kinda unnatural, but idk if I’m going to change it because I already have a whole system down and starting from scratch would be a chore. Anyway, I’ll think about it.

K bye guys

0
0
6
Open comments for this post

4h 38m 26s logged

Unnamed Platformer - Devlog 6

Guess what? More block physics issues! I’m gonna lose my mind!

What I did: Implemented logic with the buttons and doors; now, being on a button opens a corresponding door. Also fixed EVEN MORE BUGS with block pushing logic. I also resolved block-block vertical clipping and horizontal stacking bugs. I replaced the ground collision function I had made with a manual check for blocks landing on other blocks; groundCollide (that function) was not accounting for if a block landed on top of the player. This fixes vertical clipping through players and blocks and unintentional behavior with horizontally stacked blocks.

Additionally, I added a system to make sure you can’t get crushed by a door too. When I first discovered that could happen, I implemented a half baked system, but it didn’t work since it pretty much made the block/player fall through the door even if the button hadn’t been pressed prior. I replaced the old block-crush prevention logic with a new system. Now the button class has another variable, presscheck, which acts like sticky keys (idk how else to put it) even after you’re not on the button. It checks for if a player or block is within the closed door’s hitbox and if so props the door open until they leave, but it can only register that after you push the button.

Challenges: Buttons not changing color; color change logic was in my constructor and not the draw function so it never updated. Other than that, general implementation was also tricky to plan out because I had to decide how they were gonna work (how buttons would be linked to doors; decided on an ID system) and then how to implement that (using dynamic casts just as my button class uses). And then the block clipping glitch was another nightmare, though it did take me less than an hour which is nice. Also, it took me a while to think of how I would figure out how to make doors not close on players/blocks, but I thought up a solution pretty quickly which is nice 👍

AI used, if any: Used Claude to help me figure out the part that stops the block from falling through the player (I was genuinely™ too exhausted with dealing with bugs to try to solve it myself 😭😭) + used Gemini and a bit of Claude for general debugging.

Plans for next time: I’ll polish up some visual stuff, but I think I’ll leave block-related bugs alone for now. As you can see there are some clipping issues still with the door, but idk if I want to tackle those right now. Either way my main focus for next time (and like all of the next week or two) will be getting the shape-switching system down. I’ll also try to create some map layouts that force the player to utilize block placement on buttons to navigate doors, because it would be a shame for me to have spent all my sanity on a feature only like 5 levels use.

K bye guys
P.S. Last time, when I said I spent all weekend working on button-related stuff, I meant the pushable blocks too (since those can activate the buttons)

0
0
8
Open comments for this post

4h 59m 58s logged

Unnamed Platformer - Devlog 5

I pretty much spent the last weekend working entirely on button-related stuff. Turns out there were a lot of bugs and other physics-related issues I had to address. Anyway I think they’re all good now.

What I did: Day 1: I fixed a bug where nested loops using the same name (pos) caused only the first pushable block to register collisions. I also implemented a side-detection fix so the player doesn’t accidentally push blocks when standing on top of them + added a border/outline to pushable blocks for visual clarity. I also started work on button and door tile classes.

Day 2: I made it so you can push blocks vertically in zero-gravity. A really big fix was a global physics bug. I had been using a gravity called blockgravity for block physics, but since it was a global variable, one block’s position dictated all the other’s physics. E.g. one block in a zero-g tile meant everything else was now unable to fall. I moved blockgravity into the block class and now a block entering a zero-g zone floats without shutting off gravity for every other block on the map. I also decided on two new features: a button that can be stood upon/have a block placed on it, and a door that opens when its button is pushed. I added each one’s sprite and loaded them into my map. Also, I made another big change to my plans: having spend so much time on block physics, I’ve decided they’ll become a core feature of the game and not just a small gimmick of the triangle shape.

Challenges: The hardest problem (by miles) was the block push collision. the issue turned out to be one loop variable shadowing another, which meant only the first block in the list was ever processed. Another tricky bug was zerogactive being reset before the block push loop ran, meaning zero-g vertical pushing never triggered. Ironically I ended up removing the zero-g check because if you’re going to push a block vertically, you’re not going to be on solid ground anyway. Also I accidentally mismatched curly brackets so that made life a lot harder. Also, I faced a bunch of other bugs while trying to polish up collision.

Imma be honest, about an hour or so from this devlog was useless cuz it was me trying to implement a solution, confusing myself, and just discarding all my changes😭💔 Also, I spent like 20 minutes trying to get the button looking good (it’s supposed to be an octagon, but the sides are uneven).

AI used, if any: I used Claude for debugging my physics code, as well as helping me figure out why the upwards/downwards block push wasn’t working.

Plans for next time: I’m going to try and begin implementing the 5 player shapes and their power-ups. I’ll start with the circle probably, since it seems the simplest (just get faster over time). Also, I’m going to make it so that each button actually is linked to a door, since right now they’re just visuals.

K bye guys

0
0
3
Open comments for this post

8h 34m 22s logged

Unnamed Platformer - Devlog 4

I hate AABB with a passion. I spent 8.5 hours over 2 days (hardest lock in yet 🔥) on 2 features and Im pretty sure there are still bugs in each.

What I did: On day 1 I added collision detection for pretty much all my objects, added some custom physics (e.g. water and zero g now have custom physics), and implemented AABB collision. Since I got it working yesterday(mostly), I deleted the initial ground class I had for testing SFML and most features, as well as any related functions like the check ground function in the player class.

On day 2 I spent 4 hours trying to get the block to push. It took me a while cuz I initially tried to just copy the groundcollide() function and tweak whatever I needed to. However that didn’t work, so after hitting up Stack Overflow + Claude I realized I had to change up a LOT of my pre existing code. I added a master entity class for anything that is affected by physics (all players + the block + more features in the future probably) then added more functions and commands in my checkCollisions function in order to get my block mechanic mostly working. I also ended up adding many more features to my block class(velocity, gravity, and a grounded check) since it has to react to physics and the environment. Overall the introduction of an entity class that everything else inherits from was a big help in getting the game to work properly.

Challenges: my game crashed when I attempted to put the check collision function in main.cpp; then, implementing water and zero-g was a lot of trial and error not only to find physics that felt fluid but also because there were a lot of bugs in the logic as well as bugs that stopped the game from running at all. Also, it took me a while to wrap my head around AABB collision; I literally had to draw it out on a piece of paper and ask Claude to grasp the concept 😭

During bug fixes, I ended up breaking a bunch of stuff/realizing a bunch of stuff was still broken and spending a bunch of time fixing it. For example, while trying to fix collision, I ended up discovering a bug in my water/zero-g physics, and then while trying to fix that I broke my spring logic too. And creating the logic for pushing the block is a whole other can of worms. It took me 4 hours of implementing different strategies and adding different functions only to have a half baked block-pushing function. 😭 It does kind of work, but you can only push one block: any other blocks act like normal ground tiles.

AI used, if any: I asked Claude for help on how to tackle block pushing logic, as well as helping me understand AABB collision.

Plans for next time: I’m going to try and hopefully get all the block-pushing logic done without any issues, then fix up any collision-based bugs and work on implementing the rest of my player shapes.

K bye guys

0
0
2
Open comments for this post

4h 21m 52s logged

Unnamed Platformer - Devlog 3

My game is kind of coming together! It’ll still be many weeks, but I did something!

What I did: finished my tile map parser (I decided to use a unique pointer to parse through each tile type and draw the according one, after a bit of thought). I also started working on collision detection. I created a basic checkCollisions function and added getGlobalBounds to every tile class. Before I did that though I had to do some research on Axis-Aligned Bounding Box collision, and how to implement it in SFML. I’m still far from done, but that’s tomorrow’s problem.

Challenges: implementing the map drawing functions (couldn’t figure out how to get the draw functions in the classes to match up with the main class), and after that I was having a lot of trouble with the pointer logic I had implemented (had to use std::move, also there were errors in my file importing structure); then after I got that to work, and implemented the parser into main.cpp, it ended up causing my entire program to crash when I ran build 😭Ended up asking Claude for help for how to fix it; it turned out to be how I had formatted my levels and my level-parsing loop for assigning tile types to tilemap characters. Then lava, water, and zero-g block weren’t drawing properly either. After spending like an hour trying to decode why, I realized sf::Color’s transparency had to be an 8-bit integer rather than a decimal between 0 and 1. Also my doublespike was not drawing properly, so I made it 2 separate convexShape’s rather than 1. Apparently you can’t have mere points holding a single convexShape together, which kind of sucks.

AI used, if any: Like I mentioned, I asked Claude for help on how to fix my level loading feature (it ended up being like 3 minute details) and also used it when debugging my initial collision functions (I ended up replacing <10 lines total by its suggestion).

Plans for next time: I’m going to try to finish collision. That’s my entire goal, since I still don’t know entirely how I’m gonna deal with every collision possible and it might end up taking me a long time depending on the number of mistakes I make/bugs that pop up.

K bye guys

(btw the music in the background is because I was listening to music while I was working on this)

0
0
4
Open comments for this post

3h 59m 23s logged

Unnamed Platformer - Devlog 2

I was a little busy yesterday but we’re back on track now.

What I did: I think I got a solid amount done today and for a bit of time yesterday: I added a camera feature that scrolls with the player, created the tile map and tile types, and designed the first part of the tile map parser; also changed the background slightly and researched more on building tilemap loaders in SFML (YouTube videos + looking at Github repos and articles).

Challenges: For a zero-gravity section I’m thinking of adding, I wanted to put thin gray stripes in those sections. I couldn’t figure out how to do that, so I just decided to depict it as a translucent white block. Also determining the coordinates of the spring pad in the game took a while too. Overall, my other challenges were mostly small bugs and didnt stand out too much.

AI used, if any: Used Claude for debugging the switch case for my tile map parser. Also, not AI, but my camera system was more or less entirely designed using a YouTube video that I’ll credit in my readme later.

Plans for next time: I want to finish my tile map parser and get an actual level loaded. I’m also going to start deciding what the UI will look like for the main menu, level selects, and pause menu.

K bye guys

0
0
7
Open comments for this post

3h 23m 49s logged

Unnamed Platformer - Devlog 1

It’s finally time for me to lock in. This is gonna be a big project to which I hope to add a lot of content, and I’m hoping I can accumulate a lot of good hours from this project.

What I did: I set up SFML (the library I’m using to code this game), set up the required files, watched a lot of YouTube videos to get more familiar with SFML, and coded a basic thing where you control a square and jump around.

Challenges: This is like my second time using SFML (I used it once for a small project a while ago), so I’m not that familiar with it. No worries though, as it’s nothing a bunch of YouTube videos can’t fix. Also, today was kind of a refresher for my barely existent SFML skills.

AI used, if any: I used Claude for learning how to set up SFML and asking it for help on how to fix my jump button not working.
(I was missing two characters. :\)

Plans for next time: I’ll try to add actual platforms, maybe working obstacles as well. I’ll focus on adding a menu some other time, and actual styling will come much later so the game is gonna look ahh for now.

All my devlogs will pretty much follow the format of this one(accomplishments, challenges, plans, additional notes) so that I can lazily copy-paste the same template when I don’t feel like writing a whole new devlog each devlog will feel connected/cohesive and make it easier for readers to follow along on my journey.

0
0
2

Delete project?

Are you sure you want to permanently delete this project? This action cannot be undone.

All devlogs, followers, and associated data will be removed.

Followers

Loading…