I started posting a development log on Twitter. Here’s a consolidated version.
I started posting a development log on Twitter. You can see related tweets by using #ExplodingDevLog. I’ll be posting consolidations of the devlogs on this site as well. Here’s the first one!
Started working on the sprite editor, but all you can do right now is look at a sprite sheet and drag it around. Not too exciting yet.
Added an assets panel that displays all files in the project instead of having a separate sprites panel. Also added very basic sprite slicing. Slices lines are drawn with Unity’s GL class.
Wrote the basics of the 💥Exploding Data file format (why is everything exploding with me?). It uses JSON because it’s easy to work with and is human readable. I also set up saving and loading of these files.
Added right click to assets panel to allow simple creation of entities, sprites, and animations. Also got basics of properties panel working.
Added grid overlay for sprite sheets. The cell size can be set in the inspector panel. Benefits of grid-based sheets and how they work with Exploding Editor will be shown later.
Early on, you should decide on a game unit that is simple and intuitive.
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!
Sprites can now be flipped!
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.
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 got rotation working.
I had some problems along the way.
And I don’t know what this is.
Collision detection currently supports axis aligned bounding boxes only. Basic gravity and movement implemented. Basic animation. This is from an unfinished project.