Untitled Platformer Devlog (finally)

Yes; really. It’s finally here! I’m finally going to do it! I’m finally going to start the platformer I’ve all been bugging you about! :slightly_smiling_face:

Update: 0

I’m going to focus on some very simple player movement, and a very simple little map demo. This game will use the FX library, which I’m super hyped about! I’ll post a little update later when I’ve actually got something to show :slightly_smiling_face:

1 Like

Can only go up from here?

1 Like

Update 0s (from what I’ve seen) are usually the ‘prologues.’

Anyway, this sure is taking a lot more time than I thought :stuck_out_tongue:. Those lectures from Pharap sure are helping though!

1 Like

Update 1:

Finally have a map!

Not this map mind you, this is a display of all the tiles and possible combinations!

List of all (current) tiles:
GroundLeft (ground with a wall to the left)
GroundRight (ground with a wall to the right)
LeftWall (a wall to the left)
RightWall (a wall to the right)
Tube (walls on both sides)
Cap (idk man looks like a plastic bottle cap to me)

Update 2.5 tiles:

PixelBoth (two pixels at each top-corner)
PixelRight (a pixel on the top-right corner)
PixelLeft (a pixel on the top-left corner)
LeftWallRightPixel (left wall with a pixel on the top-right corner)
RightWallLeftPixel (right wall with a pixel on the top-left corner)

The pixel-less corners were not supposed to exist, but I kinda dig the look of it. I also decided to drop the FX library because this is already a huge leap for me in terms of storing data and whatnot, so having another thing to store data in will make it super frustrating I bet.

Update 2.5:

Removed pixel-less corners and added 5 new tiles!

For those of you who are going to scold me for not using drawPixel() or something, these tiles barely made a dent in the flash memory (didn’t even increase it by 1). It’s also a lot more organized since you won’t just be drawing a bunch of random pixels everywhere.

1 Like

I patiently await update 3.14159.

Nobody who knows their onions would.

There are downsides to the approach you’re taking, such as the fact it complicates the map definition and potentially the game logic by introducing extra tile types for what is effectively the same thing (solid ground), and there are other approaches that could avoid that, but each comes with its own caveats and downsides.

Ultimately programming involves a lot of weighing up the benefits and drawbacks of various different approaches and deciding which is the most suitable (or in some cases which is the least terrible).

There’s no silver bullet. The tool must suit the job.

1 Like

Haha, I recognized the 14159 as pi!

They’re just cosmetic, and go under solid tiles. As for the wall + pixel tiles, they could just share the same logic as the wall tiles. I think ultimately though ‘solid’ tiles (the ground, walls, etc) will probably just reset your velocity. Nothing else to really do, right?

Some useless trivia (from Wikipedia), about the versioning of the TeX text formatting system:

Since version 3, TeX has used an idiosyncratic version numbering system, where updates have been indicated by adding an extra digit at the end of the decimal, so that the version number asymptotically approaches π. This is a reflection of the fact that TeX is now very stable, and only minor updates are anticipated. The current version of TeX is 3.141592653; it was last updated in 2021.

An isSolid function will indeed do the job.

I mention the complication of the game logic simply because I don’t know what other things you’re planning to attempt: for some things it won’t really be an issue (beyond having to stuff a few more cases into a switch), but for others it could be.

The alternative I was thinking of was that it’s possible to actually have them all stored as a single TileType::Ground but still have all the different cosmetic variations by having some special rendering logic that selects the appropriate sprite frame based on the types of surrounding tiles.

The advantages are that:

  • Using fewer tile types would allow you to use less progmem to store maps
  • Creating maps is a lot simpler because you don’t have to worry about the right tile variants being used

The disadvantages are that:

  • The rendering becomes a lot more complex, and probably slower

I’m not saying that you should be doing that, I’m just pointing out that there’s more than one way to do it. Either way will get the job done.

1 Like

Update 2.75:

Kinda got the camera controls working. It still needs a lot of fine tuning and clamping but here’s what I have so far:


I’m also going to change the direction of the sprite based on the velocity, rather than the buttons you’re pressing, so that the sprite always looks in the direction it’s moving.
Nvm it looks goofy

Update 2.89:



And yes, @Pharap, I did seperate the camera stuff from the map data :)


The god of separation of concerns will reward you for it.

1 Like

Update 3:

I got a camera system working! It clamps the camera at both ends of the level. I’ve also added friction, which is always applied, though later when I add collision, I’ll change it so that the friction is only applied if the player is on solid ground. I haven’t used any ‘cut off point’ thing too, like I had in my last games.


Still trying to keep the player from going over the center of the screen when the camera is un-clamped but I’m sure I’ll figure it out.


Update 3.14159:

I don’t really have much to say. I’m still alive and working on the collision. Here’s a little sneak peak of the code:


1 Like

I hope that is following the K&R brace style.

1 Like

*Readies the pitchforks.*


Wow! It sure has been a while, hasn’t it! (holy crap 26 days :flushed:)

Update 4 & 5:

Collision has finally been added!!!


Huge thanks to @Pharap , I wouldn’t have been able to do it without them!

Coyote Time has also been added for more fluid platforming! For those who don’t know, Coyote Time is basically the time that you are allowed to jump after not being on the ground anymore. So basically, it allows you to jump when you’ve just cleared the edge, so you don’t have to worry about tricky timing! The Coyote Time limit in the game is currently 10 frames, so 1/6 of a second.


Also, I guess I should mention I added proper jumping, so the player can’t just spam the jump button and fly everywhere.


I take it you read that article on the Pokitto forum?

What . . . ?

I remembered Coyote Time from an FPS Devlog on YouTube from about a year ago, I think, or at least many months.

Edit: I think it was by Codeer or something.

Ah. I thought you’d just found this old thread on your recent visit to the Pokitto forums.

1 Like