NGPC Platformer Engine - Work in Progress

[winteriscoming]

I am still working on my platformer engine.

I need to get some better animations into it, but overall, its working pretty well for me.  I have a workflow down with Tiled to output usable maps for this engine, so building out levels can be done pretty quickly.

I want to do a little more before posting another demo.

   

[winteriscoming]

I have been redesigning my platformer engine basically from the ground up as I have been learning a lot and figuring out better ways to handle things.  I now have it to where it dynamically handles maps of different sizes.

I have a very quick workflow down for tilesets and maps.  Tilesets can be produced very quickly using a regular graphics editor like GIMP and converting to usable NGPC data with sodthor's image converter.  The same tileset image can be used in Tiled map editor to build out a level, and the output from that is easily converted to usable code.

Once the fundamentals of this engine are in place, swapping in different tiles and levels will be very easy and I could effectively make entire platformer games relatively quickly.

   

[winteriscoming]

   

I am still working on my platformer engine.  I have it a lot more fleshed out than it was over a year ago.

I have successfully implemented:
player projectiles
enemies
enemy projectiles
player health management (hurt by enemies, healed by interacting with healing tile)
player-enemy collision (to hurt player)
player-enemy projectile collision (to hurt player)
player projectile-enemy collision (to hurt enemy)
enemy projectile-enviornment collision
player projectile-environment collision
various enemy behavior states (walking, attacking, dying) with configurable frames of animation
different enemy types (flying, walking, detects edge, pursues player after seeing player)
configurable and randomized item drops per enemy type
player-item collision (to get item)
backgrounds split by hblank to give a parallax effect
mix of VGM and WAV SFX without harming performance
VGM background music configurable per level/room
animated tiles to give life to some of the elements in the level other than enemy sprites

I am really enjoying working within the limitations of the NGPC.  Even though I hit some frustrating limitations sometimes (only 3 colors per sprite... ugh!), it's fun to see what I can accomplish.

[sodthor]

great

[KeiDash]

I think that you are doing a good job. I would like to see how many powerful is this engine.

What are your objectives in short time?

[winteriscoming]

I think that you are doing a good job. I would like to see how many powerful is this engine.

What are your objectives in short time?

Once I have implemented all the features I need, my plan is to build out a full game.

There is work yet to be done including:
-Friendly NPCs
-Dialogue
-Inventory
-Bosses
-Interactive tiles (boss room doors, breakable blocks, etc.)
-Shop
-Saving/loading progress

[KeiDash]

I think that you are doing a good job. I would like to see how many powerful is this engine.

What are your objectives in short time?

Once I have implemented all the features I need, my plan is to build out a full game.

There is work yet to be done including:
-Friendly NPCs
-Dialogue
-Inventory
-Bosses
-Interactive tiles (boss room doors, breakable blocks, etc.)
-Shop
-Saving/loading progress

Sounds great. 

I have a .c file to manipualte the save/load progress to implement direclty in the game. Tell me something if you are interested

[winteriscoming]

I have a .c file to manipualte the save/load progress to implement direclty in the game.  Tell me something if you are interested

I am interested in seeing anything you want to share.  I have seen examples of saving in sodthor's sources, and I read through the thread on ideal methods of saving so as to not cause as much wear on the flash memory.

I think my biggest challenge is going to be figuring out my payload for saved data.  There's a lot that I *could* save, but it might not be feasible.  At a minimum I will have to track player stats, weapons, items, save location and bosses defeated.

[winteriscoming]

As I have been working on my platformer engine, I have a few observations:

1. Allowing the game loop to run asynchronous to the vblank can lead to faster speeds. Any time I have my game loop wait for the next vblank, it ends up feeling too slow. However, running the loop with no period of waiting at the end can lead to inconsistent results, such as a period where you're moving (i.e. processing animations and detecting collision) vs standing still. My compromise for optimal performance is to set an hblank counter to 0 at the beginning of the loop and check that it is is greater than a specific value (60 in my current case) before ending the loop. In this way the loop takes the same amount of time regardless of whether or not it has to do much.

2. No emulator I have tried seems to run my rom the same as real hardware. Emulators run too fast when not waiting for the vblank, and real hardware seems to get bogged down in a way the emulators don't reproduce (i.e. when moving in a large level with sprites nearly maxed out). This means I can't rely on emulation as a sole means of testing, and just about all changes have to be tested on real hardware. I am in progress on optimizing my code to run more efficiently in some of the more frequently used functions to get better performance on real hardware. I have it running pretty well on real hardware at this point.

3. As best I can figure it, there are 2 methods for managing enemy sprites.
1 is to have enemies be persistent in a room, so your enemy limit is limited by the number of spare sprites you have compared to the sprites you need for the desired enemies. With this method, all enemies in a room could chase you to the edges of the room and all be rendered on screen at once. I believe Dark Arms uses a method like this. All enemies in a room seem to be persistent and can (if they're mobile) all move to a specific part of the room and be rendered at the same time (i.e. likely total sprites used in a given room is less than or equal to 64 unless some hblank trickery is employed to make it appear that there are more). I think this is more in line with a Castlevania SOTN style game (with a few exceptions of repeating enemies that come in from the edges of the screen like the medusa heads, or the respawning zombies that come up out of the ground).
2 is to dynamically recycle sprites. To do this you have to somehow limit the number of enemies that can be on screen at once (i.e. maybe the enemies won't jump off of a ledge or they have some barrier separating different groups), and manage reassigning sprites to other enemies at other areas of a room. This could get complicated to manage, depending on how it's done. Metal Slug: 1st Mission, for example, seems to make use of a limited number of enemies on screen at a time. The enemies disappear if they move off screen, and can respawn if the player goes back to their spawn point. I think Sonic Pocket Adventures uses a similar method. No enemies are going to chase you from one side of the map to the other. They have a limit of how far they move before they stop and end up off screen and into oblivion.
I am currently opting for method 1. All enemies are persistent in a room, and they are moving even when off screen, their sprites only rendered when they are on screen. In this way an enemy can be placed at the opposite far edge of the room and, if the player enters and just remains in place, the enemy will eventually makes its way to the player. Leaving and re-entering a room resets it, in Castelvania SOTN fashion, and each enemy starts at its original spawn point. While I haven't implemented any enemies that respawn within the same instance of a room, I may do so.

[winteriscoming]

   

I have been able to get better performance out of hblank effects and have a way to devote a tile row on scroll plane 1 to a static HUD.  No sprites overlap this row because they all get offset until hblank for row 8.  I had previously made use of some sprites for a HUD, but now I can save the sprites.  For the new effect, whenever the scroll plane 1 has to move, and a row or column of new tiles needs to be drawn, the HUD is drawn a few rows higher. It gets moved into the first visible row at vblank, and moved back at hblank row 8.  There is an overall sprite offset for x and y defined at a specific offset in memory, so all sprites can be simultaneously moved by setting them, meaning you don't have to waste time iterating over all sprites.

Another area of interest is with regards to rendering a large boss.  The sprite limit, once you factor in sprites needed for the player character and weapons/projectiles is pretty low.  If I sacrifice a scroll plane and devote it to housing the tiles for a large boss, I can make use of a lot more tiles and animate/manipulate the entire plane in a way that is akin to manipulating sprite chains.  In my screenshot, I am experimenting with a boss that is 80*64 pixels, or 10*8 tiles, which equals 80 tiles, which is more than the sprites available, let alone the sprites I have remaining.  So if I leave scroll plane 1 devoted to my level map, keep its tile count reduced enough, and forego a scrolling background, I can find a spare 80 tiles to draw the boss on scroll plane 2.  I can successfully write each frame of animation to the necessary tiles, and I can manage flipping the tiles on the plane to have the boss change directions.  My testing so far makes me think this is going to be a perfectly viable option, with no noticeable hit to performance.  An added bonus is that I have a decent number of sprites left to play with for boss projectiles and such.  I think the Metal Slug games are likely doing something similar with large bosses.