Let’s Make a Game: On the Map April 2, 2014Posted by eric22222 in Game Development, General.
We’ve got some graphics! Now before we start stitching together a level, we need to create some sprites. Sprites are pretty simple; they’re the things that will actually move around in our game. Well, they don’t have to move. And actually, some things that do move AREN’T sprites…
Ok, sprites aren’t all that simple after all. For now, let’s just say that most sprites move around and interact with other sprites. A sprite will be used for the player, most enemies, projectiles, and some animation effects. Some will be almost identical in how they work.
For each sprite we make, we need to define states (FacingLeft, FacingRight, Jumping, etc) and set up the rules for how the sprite behaves in the world.
We’re going to start very simple with our states, but we’ll overhaul everything later. For now, we just want two states: one for facing left and one for facing right. We won’t have any walking animations yet, either. Just a single frame sliding around on the ground.
The rule definitions for sprites is a lot better in SGDK2 than it was in version 1. It’s really a sort of pseudocode tree. Almost any basic function you need is available from a drop-down menu, and the parameters will autocomplete to currently available variables.
The state changing functions are easy: if we’re moving left, change our state to the left facing one. We do the same thing for the right. Our jump function checks for us hitting a button, then makes sure we’re also on the ground. The function called “JUMP!” just alters our Y velocity by -10 (the map origin is the upper-right corner, so up is negative).
The others handle easily-forgotten things like gravity, handling movement against solid walls, or even moving the sprite by its current speed. Some of these make sense to do per sprite. Some enemies may fly, so they might not need to react to gravity. Projectiles might be able to pass through walls. But we’ll have some functions down the road that we want to be the same for every enemy. Those sorts of things we’re going to handle with a custom class, but we’ll get to that later.
Now that we have some basic resources to work with, let’s start piecing a level together. SGDK handles levels as objects called “maps.” This object isn’t limited to stages, either. It could be a level select screen, an interface for an item store, or an options menu. Pretty much anything that handles user input (though cinematics could technically be done on a map as well). Maps are made up of layers, which works pretty much how you’d expect. You can have a foreground, background, etc.
First, some setup. We need to decide on some settings for the map. I’m never really quite sure how big to make a map. I can always change it later, but I feel like I need to size the level to fit the map rather than just change the map size when I run out of room. I guess this can just be a test map, so we’ll just start with 100 by 40 tiles.
Let’s touch on the properties of the layer. BackgroundTile is a bit of a misnomer; it’s really just the tile that everything gets initialized to. The default of -1 tells the layer to leave everything as it is (the above screen shot is after I already created the layer, normally the default is 0). Tileset is the group of tiles this layer will use. Each layer can only pull from one tileset. BytesPerTile determines the file size of our layer, so we want the smallest we can afford. One byte gets us a maximum of 256 different kinds of tiles we can use on the layer. ZIndex tells the engine which order to draw layers in. I just chose 5 to give me some room behind for plenty of background layers.
The ScrollRate is where we can start getting fancy with some parallax scrolling for depth. If we set it to a value less than 1 (but greater than 0), the layer goes by slower. Higher than 1 scrolls faster. Imagine staring out a car window on the freeway. The trees and hills in the distance seem to creep by, but the telephone poles and road signs zip by in a flash. That’s pretty much how scrolling can do depth.
Now we’ll just lay down some tiles to test…
Ew. Redoing the graphics is slowly gaining rank in the to-do list, and I only just drew them. We’ll put up with it for now, but I don’t like how it looks. Still, we’ve got some solid ground to work with now. We’ll just place our character on the map, cross our fingers, and…
Ha. It turns out we DON’T have any solid ground to work with. Although we told our sprite to react to solid tiles, we never actually told the engine which tiles are solid and which are not, so our rabbit falls straight out of the map. Luckily this is a quick fix.
Hooray! While we’re on the subject of solidity, I do want to mention something I found while peeking around in the code for solid tiles:
I just love this. It’d be a little out of place in many programs, but when dealing with drawing to screen, ASCII art comments can make it easy to see what you’re dealing with at just a glance.