Introduction
Pixel movement is a feature that is highly demanded and often misunderstood. BYOND's support for it has changed over time and so has the availability and quality of pixel movement demos and libraries. This leaves a lot of questions - what is it? how do you make it? can BYOND handle it? why do you need it?
A while ago (almost a year ago, I think), it became my goal to create a solid pixel movement implementation for BYOND. BYOND had some demos and libraries for pixel movement (here's a list), and they show that it's indeed possible, but they weren't polished enough that people could really use them. Many of those were just executable demos that didn't include code. People weren't implementing it as a feature, they were implementing it as a flasy trick. I wanted to change that - by making a library that anyone can use to make pixel movement, it would no longer be impressive for people to say "hey look, I made something that has pixel movement". People could move on and start making games that use pixel movement.
The result is that I've created two libraries for pixel movement, one for sidescrollers, and one for top-down/isometric games. However, these libraries don't address the confusion and mystery surrounding "pixel movement".
The purpose of this article is to answer some of the questions about pixel movement and to de-mystify the feature. I think it's one of those features that people want because they think it'll improve their games (like isometric maps), but once they have the feature and they find out it's not a magical "make my game awesome" button, they're not sure what to do with it.
"What is 'pixel movement'?"
BYOND's default movement system is tile-based. When you press the right arrow key you move right one tile. When you press the left arrow key you move back to the first tile. You move a tile at a time. "Pixel movement", or "pixel-based movement", is a movement system where the player can move in smaller increments than whole tiles. The next unit of measure smaller than the tile is the pixel, so these finer movements are measured in pixels.
"Do I need pixel movement?"
Maybe! It depends on the kind of game you're making. Pixel movement gives the player finer control over their character. In an action-based game this can be very important. In a turn-based RPG it might make no difference.
Tile-based movement is a rare thing. Even on the NES, where all graphics were tile-based, most games didn't use tile-based movement. Those that did tended to be from a few specific genres. People don't expect games to be tile-based, so even though it's commonly seen as a limitation of BYOND, people who aren't familiar with BYOND won't understand this limitation and will just think the game is bad.
Using pixel movement almost requires a higher framerate. While people see this as a bad thing because it'll "cause more lag", it's actually a good thing (people are too afraid of lag anyway, but more on that later). BYOND's default framerate of 10 frames per second is most likely because BYOND was started back when 56k internet connections were fast. Unfortunately, 10 frames per second isn't enough for animation that's visually appealing. Read Wikipedia's history of cinema, by 1895 technology had advanced past the 10 frames per second mark. Even if you don't use pixel movement, you should strongly consider dropping world.tick_lag to 0.5 (from it's default of 1.0) to get a framerate of 20 fps.
"How does it work? I've heard all this stuff about collision detection..."
A pixel-based movement system augments BYOND's existing tile-based movement system. You can use BYOND's built-in pixel_x and pixel_y variables to change a mob's position by any number of pixels. But that's not all there is to movement, you also have to check for collisions too.
Checking for collisions is easy in BYOND's default movement system. When a dense mob tries to move to a tile, you just have to check if the tile is dense or if it has any dense objects inside of it. If it's clear, the mob moves into the tile. If it's not clear, the mob doesn't move into the tile. With pixel-based movement there are more complicated ways that collisions can happen and more complicated ways that collisions need to be resolved.
Luckily, a pixel movement library will handle all of these things for you. This is similar to how you can use BYOND's default tile-based movement. There are some things you can customize (ex: you can override a turf's Entered() proc). There are also some things that BYOND gives you that you can't override - you don't have to tell BYOND that there's a grid of turfs and you don't have to tell BYOND what it means for a mob to have a loc, it just knows. It handles these low-level details and you don't have to worry about it. This is how my pixel movement libraries work - you can override some things to customize behavior (technically you can override it all), but there's also some messy internal stuff that is better off left alone.
"What are bounding boxes? And what is 'pixel-based collision checking'?"
Bounding boxes can be used to simplify how you check for collisions. You use a simple shape (ex: a rectangle or circle) to approximate the shape of a mob. Then, to check if the mob is inside of a wall, you check if it's bounding box is in the wall. My pixel movement libraries both use rectangles as bounding boxes for all atoms (technically, the sidescroller library uses rectangles, the pixel movement library uses rectangular prisms).
Pixel-based collision checking means that you look at the actual pixels in the icon to see if there's a collision. If the icons of two objects have pixels in the same position on the screen, there's a collision. Unfortunately, this is a stupid feature that people think is necessary (because it sounds impressive), but it's not necessary. In fact, it's often wrong. For example:
Above: Showing why pixel-based collision is actually something you don't want.
On the left side of the picture, the circle cannot move up or right because it's hitting the wall. If we treated the mob as a circle we could realize that the round shape moving upwards would get pushed away from the wall and we could allow the upward movement. Because we just treat it as a collection of pixels and only want to know if things overlap, we'd see a collision and not allow the movement.
On the right side we have a mob that should be able to walk in front of the wall. Because the icons aren't from a strictly top-down perspective they show height, the mob should be able to walk in front of the wall in such a way that the icons overlap but the mob isn't really hitting the wall. If you're using pixel-based collisions, the move wouldn't be allowed because the icons overlap.
"I've heard that BYOND can't handle pixel movement..."
There are a few reasons why people say this:
1. Pixel movement is not a built-in feature of BYOND, it's something you have to create with DM. Luckily, BYOND has all the things you need to create a pixel-based movement system. Some people think "if we were supposed to do it, it would be built in", but this doesn't make sense.
BYOND doesn't have a built-in chat system, it just gives you the ability to get text input from a player and output that text to all other players. The reason it's not a built-in feature of BYOND is because there are lots of ways you might want the chat system to work. By leaving the implementation up to each developer, you're free to customize your chat system however you need to. The same is true for pixel movement. Not every game will use it in the same way. Some games might have the players walking around in 4 directions, some might have the player driving around a car with 360 degree movement, some might be sidescrollers.
2. BYOND is slow. There are a few reasons why BYOND is slow:
2.A. Some people run BYOND on old laptops with poor graphical capabilities. BYOND's graphics aren't impressive by modern standards so they don't look demanding, but refreshing the screen 30 times per second can be too much to ask of a ten year old laptop.
2.B. BYOND used to have a fixed framerate (10 fps) and bad networking code (the server was not efficiently determining what information needed to be sent to clients). Both of these issues have been fixed. You can now use world.tick_lag to make games run faster than 10 frames per second and BYOND's netorking code has been improved so that the server can handle sending more updates per second to every client.
3. BYOND doesn't provide pixel movement and, for a long time, the pixel movement libraries and demos were not very helpful. Because of that, people have gotten used to making games with only tile-based movement. In fact, people have gotten so used to tile-based movement that they don't think pixel movement is necessary.
Of those issues, speed is the only real concern. Luckily, speed is just a temporary issue - computers and internet connections are getting faster all the time and the BYOND software is constantly being worked on by the BYOND staff. Games with pixel movement might experience some performance glitches in BYOND (I've found these two), but in order for the staff to fix these issues we have to first find them. BYOND will only get better and faster.
"Seriously? Pixel movement doesn't lag?"
Well I didn't say that. If you're playing a game over the internet there's going to be lag, it's just a question of how bad the lag is and how willing the player is to accept it. There are a few reasons why BYOND games lag:
1. Latency in communication. The trip from client to server will go through many devices (computers, routers, etc.). If there's one slow device along the way, all messages will be slowed down. You might be able to send messages quickly across the internet (ex: less than 0.1 seconds to get from client to server), but it's never instant.
2. A busy server. If the game has a lot of players the server's CPU or internet connection might be pushed to its limits. This happens in all games whether they use pixel movement or not.
3. Client-side processing. The BYOND game client has to draw the screen and manage the game's interface. If the game has a large viewing area and is displaying lots of objects, the client's computer might not be able to redraw the screen fast enough.
The lag in games that use pixel movement is more of a problem because these games tend to be action games. If you were playing chess, a slow-paced board game, you could tolerate a lot of lag. If you were notified of a move three seconds after your opponent made the move, that'd be ok - you'd still be able to play the game. Suppose you're playing an action-based shooter and you press down to duck for cover, if the server gets your message (the instruction to duck) even a tenth of a second late it could be the difference between dodging a bullet and getting your head blown off. The three second lag that was acceptable for the chess game would be absolutely game-ruining in the action game.
Games that use pixel movement tend to be action games and action games tend to have higher framerates. Pixel movement isn't what causes the lag (or what causes the lag to be a nuisance). A tile-based action game will have lag too.
"Okay, so what's this all mean?
It means that pixel movement is a good thing, an excellent thing. Now, this doesn't mean that you have to use it. Some projects won't benefit from it, this depends on the type of game. A game isn't good just because it uses it or bad just because it doesn't, but, if you're working on a game inspired by Metroid, tile-based movement probably won't cut it.
Lag is an issue, but it almost always is whether you use pixel-based movement or not. That's no reason to avoid pixel movement. Making an action-based game with a higher framerate is more demanding of the server and will limit how many players you can support in a single server (this is also true whether you use pixel movement or not). Instead of having 50-100 players you might have 5-10 players, but this is okay for a couple of reasons:
1. Action games tend to be small-group games. Look at Wikipedia's List of best-selling PC video games. Of the games on that list that even have multiplayer modes, most don't support more than 10 players.
2. The BYOND software is freely available so anyone can download and host your game. You can set up some game servers yourself, but you can also let people download the game and set up their own.
BYOND is an excellent platform for making action games that use pixel movement. If you want to make a game that would benefit from having pixel movement, don't let anything stop you and don't settle for tile-based movement.
