Level Performance

Greetings all,

I took quite a bit of a break, but now it's time to get back into it. I've been stressing a lot with school lately, so I haven't gotten as much as I wanted done (Ya, more excuses) but I'll get there eventually.

I've been tweaking the way the engine reads/runs levels created with the editor and I believe I've come up with a suitable execution. There won't be any pretty pictures this time since it's difficult to convey, but I'll try to explain what's going on the best that I can.

First up, keep in mind that although I'm interested in game design, I'm not very familiar with the terminology, so if I say anything wrong, please feel free to correct me.

Creating a level editor and saving each tile into a single file, while time consuming, is simple enough. But there is multiple ways one could go about reading and implementing this file. One way to do it would be to render the entire level as soon as it starts. This is similar to way MMF2 does it by default. One would think this is the best solution, but it's really not. The first issue would be heavily increased load times. While it would greatly depend on the size of the level itself, having to check each position for an existing tile is incredibly cumbersome. The next thought might be to only check positions that you know have a tile there, but that would mean having to make a completely different kind of file. And once it again, the size of the level would matter. Even if you did decide to use one of these two methods, there arises another issue. The size of the screen is only 256x224, but 99% of the time the level is going to be much larger than that. And so, you have active tiles/objects in unnecessary places which will bring down the overall performance.

So the next obvious choice is to only load parts of the level at once. Again, there's multiple ways to approach this but I'll explain my solution. Instead of loading the entire level, the very first thing it does is load the area around your starting position. This is a very small area so load time will not be an issue here. From there, tiles will on spawn/render in the direction that you're moving, and previously rendered tiles that are now off-screen will be deleted. This method is more consistent as the size of the level doesn't matter at all and also helps reduce memory usage. This is not original at all, many tile based games use this or a similar method, especially noticeable in NES games.

On some very basic tests, the peak frame rate on my machine with the old coding was 87 FPS. Using this new method, the peak was 370 FPS. Of course this will vary on different computers but the results overall are clear. There are still tweaks I need to do in other areas though so I can make it more constant.

That's all I got for now. I apologize for the lengthy and likely boring post this week. It'll be nothing but tweaks and bugfixes for quite awhile, but once that's all taken care of I'll be able to give you all something playable =). As always, if you have any questions and/or suggestions feel free to post a comment. If you're interested in this project I encourage that you to follow this blog. Thanks for reading.


  1. So, some sort of level streaming?

  2. Not necessarily, but I guess that's one way to look at it.

  3. looks nice... err i mean, sounds.
    also, i was wondering if you are going to explain music loops and sort, im very unfamiliar in that area, if you are taking request:
    -when you are in an area and go to a diferent one (like on the same level) make the song fade off and make another fade in.
    -make the music silence during cutscenes (dialogues and sort)
    -boss battles and victory.
    -when the maverick is at mid health change the song (like on mmx8)

  4. As of yet there's no option for any music control whatsoever. I'm also unfamiliar in that area, I'll have to do more experimenting and research before I can do anything like that. But I will make a note of your suggestions, thank you very much.