Skip to content

Started A New Platformer Prototype

It's been over a half month since I released Fester's Torment and went dark on this blog. But I haven't been idle. I already have a new prototype.

It's a fast paced, momentum based platformer that is a cross between Super Mario World and something like Megaman.

The influence is pretty apparent from the gameplay. Something similar to P-speed affects the height of your jumps. You fall fast when you let go of the button and you're floaty when you hold it down. You can get consecutively higher jumps by chaining jumps together without dropping momentum. It's a lot of stuff like that, where knowing the physics allows you to get that really crazy jump.

Warriors and Wizards

I don't really know what to call this thing. The project started out as a folder GOTY but lately I've been thinking of it in terms of the the skins you saw above.

Two Combatants Enter the Arena of Tiles and Fireballs

Yes, This Game Has Skins

Every player and NPC has four layers of sprites: a base, a body, a head, and an accessory held in the hand. There are four pants variations and 8 variations of each of these: armor, robes, shields, books, helmets, and wizard hats. You can match any of them together.

Player Vs Player?

Not quite.

While it will be a single player game, the fact that you can slap a combination of skins onto the bare shirt player and get a pretty different looking character sprite means that it makes a lot of sense to use the player sprites as enemies and bosses. I like the idea of the player accumulating skins by defeating opponents who wear those skins.

Emphasis on Movement

It might look like this is a game with an incredible battle mechanic and impressive enemy AI, but so far that is not the case. Most of the work I've put in has had to do with platformer physics. I think it's pretty common for developers to get a terrible and unsatisfying jump into their side scrolling game and they're already moving on to level design and other things. A platformer -- or any variation of the side scrolling game -- is only as good as it feels to jump around.

I think I have a pretty good prototype for that. My inspiration mainly comes from my years as a SNES romhacker and playing a lot of mods that push the movement systems of a certain game to the absolute precipice of what is possible. While I don't intend for this game to be a kaizo style game, I do intend to show off movement.

Technical Challenges So Far

Basically just one.

Custom Collision Handling

Defold uses Box2D, a physics simulation, as the default way of handling collisions. It's pretty cool if you need all of its features, but it's very computationally expensive to use in a simple game if you don't.

In my last game, a horde shmup of sorts where the screen is filled up with sprites that all collide with each other as they move toward the player, I discovered the breakdown of this system first hand.

Custom Collision Handling

I knew about DAABBCC, a C++ library by selimanac for detecting AABB overlap. At the time, I didn't even know what that meant! But I knew it could be used to achieve more performant collisions. It was a combination of the docs being somewhat difficult to penetrate for someone who is new to the concept and the fact that I already had a relatively large codebase I'd need to refactor to get it working. I ended up opting to limit collision using enemy AI and work around the problem rather than enable myself to do more collision. But I put this library on the back burner planning to figure it out one day.

I didn't plan at first to use the library for this game, but when I started noticing a persistent wall clipping problem I couldn't eliminate, I kept hearing the conventional wisdom: Don't use a physics simulation for a platformer. While I wasn't using most of its features and was handling all collisions as kinematic objects, I was using the normal calculation it provides and I guess that counts.

So I spent three days bashing my head into the wall.

Setting up the library is a bit intimidating but it's not the hard part. The hard part is that once it's set up, you don't have that normal calculation to correct overlap. You have to find a way to do it yourself. But the library provides everything you need really if you're creative. It's a combination of overlap correction and raycasting.

It's incredibly fast. And I'm pretty sure it's going to enable me to fill the screen with as many projectiles, enemies, and other game objects as I want.