When making a game, one thing you have to decide early on is what you will use as units. Having a game unit allows you to consistently express things like distances and speeds. Below, you can see the units I use for Super Retro Crossover. Since the world is split up into tiles, 1 unit is equal to 1 tile (16 pixels).
Having a unit that makes sense and is easy to wrap your head around is important. For example, if I tell you that Mario’s max walk speed is 5.625 game units per second, can you imagine how fast that will be in your head? With the units I’ve chosen, it’s pretty easy. He’ll move past about 5 and a half tiles every second.
Units shouldn’t always have a direct relation to pixels though. For example, one unit is equal to 16 pixels now, but if I wanted more detailed graphics, one unit might equal 32 pixels or 64 pixels. It’s generally a good idea to think of rendering as separate from the rest of the game engine.
I’m telling you all of these things because I did them wrong in Super Mario Bros. Crossover. In that game, one unit was equal to half a pixel. Look how much more confusing this is!
In this case, Mario’s walk speed would be 180 game units per second. That’s a lot harder to visualize in your head. The point is, keep your game units simple and intuitive!
I implemented sprite flipping in the level editor and game engine. The image above shows flipping on hill. Those are both the same sprite.
I also built the first level of Super Mario Bros. There is a toad there because the story takes place after Mario beats Bowser, so he has freed the toads.
Speaking of that… does anyone have any ideas for how the first level would be different after Mario has beaten Bowser? So far I just have toads hanging around that you can talk to, there are no enemies, and some of the bricks and item blocks have already been hit. I was wondering if there could be anything else different to make it more interesting to go through the level. It’s important for the story that the player goes through the whole level.
I should also mention now that this development log contains spoilers. I don’t really know of any way to avoid that, but I don’t think it is a big deal because this is an experimental fan game. It also allows me to get feedback on stuff before I put it in the game. I won’t intentionally reveal spoilers, but I also don’t see any way around it. I hope that’s okay!
Switched to using one collider per tile to make it quicker to build levels. The sides that are in red are ignored so they still behave properly.
For comparison, this is how colliders looked before. They are bigger, so they’re more efficient, but it takes longer to make them. I’ll probably eventually have something like this auto-generated when a level starts.
I also made some progress on the story and deciding on what content will be in the first release.
I got rotation working. And scaling. I had some problems along the way. And I don’t know what this is.
This is the first post of the Super Retro Crossover development log. More info here. Collision detection currently supports axis aligned bounding boxes only. Basic gravity and movement implemented. Basic animation. This is where things are now.
Jay talks about what’s been happening and demonstrates a work-in-progress port of SMBC to HTML5.