Tile vs pixel movement

ID:1034500
 
Oct 30 2012, 1:29 pm
Well I am making a game and I am now thinking of using either pixel movement or tile movement. In the long term which would be better?
Oct 30 2012, 3:03 pm
It all depends on what type of game you'd like to make. NEStalgia works well with tile-based movement while a game like Casual Quest wouldn't.
Oct 30 2012, 3:15 pm
In response to Calus CoRPS
He's right, it really depends of your game.
Oct 30 2012, 3:16 pm
well the game is a fast paced game highly based on combat. It also involved strategic dungeon solving and such. Basically lots of movement involved in the game. Any specific downsides or upsides to pixel movement or tiled movement?
Oct 30 2012, 6:34 pm
The biggest downfall to tile movement is the fact that people are haters.

Personally, I prefer it. Not sure why everybody hates on it.
Oct 30 2012, 6:45 pm
In response to Dj dovis
Dj dovis wrote:
well the game is a fast paced game highly based on combat. It also involved strategic dungeon solving and such. Basically lots of movement involved in the game. Any specific downsides or upsides to pixel movement or tiled movement?


The upside of pixel movement is that it just feels much better, from the player's perspective, for fast paced game.

I mentioned this in another thread: pixel movement will require more collision checks when compared to a tile-based game. Of course, if programmed efficiently, as Fugsnarf mentioned in a thread, you'll obviously will be able to accomplish more. Nonetheless, once you start reaching a certain movable atom amount moving simultaneously, then you'll start to visually notice the lag.

Mind expanding on what you plan on making? Based upon your estimates, about how many mobs and objs may be moving at once? How many players do you expect to be on one server?
Oct 31 2012, 3:42 am
Well on my estimates id say around 50 players per server. I wouldnt really know how man objects would be moving at one time but if id have to guess the number wouldnt be too big. I plan on making a game an RPG adventure game in which combat is a really important. Other than combat there would be quests,dungeons and temples to solve. Id tell ya more but I dont want to give away the game.
Oct 31 2012, 8:18 am
Movement speed is way more appreciated in a pixel-movement game than a tile movement game, a tile movement game would make reaching the fastest movement speed easier to reach, as an a pixel-movement it'll take more time and slows and speed would make more sense.
Nov 6 2012, 9:21 am
I personally prefer the tile/glide based movement. There are ways to make it support a variety of movement speeds and other smooth looking stuff. It all comes down to timing (preventing movement from one tile to the next while the current glide_size is gliding). And modifying that glide_size with a speed variable equation. It also uses less bandwidth, as the server and client only need to communicate the difference between a tile as opposed to the difference between a pixel. The client is doing a little bit of processing there to move the atoms along while gliding (ie: server tells client "move fireball down one tile" and then client executes this)

I personally cannot stand pixel movement games with tile environments. Every time there's a single tile entry way, I get stuck on the corners.
Nov 26 2012, 2:42 pm
LOL Fireking you hit the nail right on the head with getting stuck on the map! Gahd just make the bounding box a little smaller than one tile!

NEStalgia is highly based on combat, but it's all turn based and doesn't happen on the map :P

All I will say is, if you do use pixel movement please do not force the player to use the numpad for diagonal movement! Learn about bitflags!
Nov 26 2012, 3:59 pm
In response to Magicsofa
Magicsofa wrote:
LOL Fireking you hit the nail right on the head with getting stuck on the map! Gahd just make the bounding box a little smaller than one tile!

NEStalgia is highly based on combat, but it's all turn based and doesn't happen on the map :P

All I will say is, if you do use pixel movement please do not force the player to use the numpad for diagonal movement! Learn about bitflags!

In my tile based movement system, I account for glide time and allow button combination moves (w and d moves you north east) as well as allowing all possible steps (if you're holding north east along a wall to your east, you'll move north). Not sure why this wasn't built in to byond in the first place because this is the type of behavior I'd expect, but at least we have the means to write our own and overwrite default behavior.
Nov 26 2012, 4:09 pm
In response to FIREking
At some point they did have support for holding multiple keys at once. It was awful and they removed it.

Forum_account's Keyboard library handles it well:
client/keys = list("w", "s", "d", "a")

//  mob per tick
var dx = client.keys["d"] - client.keys["a"]
var dy = client.keys["w"] - client.keys["s"]
var new_dir = offset2dir(dx, dy)
if(dx) step(src, new_dir & 12, abs(dx))
if(dy) step(src, new_dir &  3, abs(dy))
dir = new_dir
Nov 26 2012, 5:17 pm (Edited on Nov 26 2012, 5:38 pm)
I don't know why people say they prefer grid based movement over pixel movement or even the other way around. It is completely relative to the game.

Games made up with tiles of any size (that would be every BYOND game at its core) have two choices. They can either use the grid of tiles to be nothing more than visual, or use it in the gameplay. The former is pixel movement, the latter is tiled or grid movement. Depending on the game, either one will make or break the gameplay. A good example of the former would be Megaman. A stage in the NES Megaman is made up of 16x16 tiles, but the gameplay doesn't care about that. The only thing that the grid does is display the stage; movement, shooting, jumping, dying, colliding, collecting items and power-ups, enemy movement and shooting and jumping, and everything else I didn't even think of completely ignores the grid. On the other hand, a game like Final Fantasy is dependent on the grid for everything. Your characters and the NPCs -only- move tile by tile. You only interact with things one tile in front of you -- not 1/2 a tile, not 1 1/64 of a tile, only 1.

The distinct difference between these two games, and consequently the two styles of gameplay in general, is that Megaman is an action side-scrolling shooter and Final Fantasy only has action displayed on a battle screen where no movement or actions occur except menu options. Megaman makes the movement a key part of your goal because tight, responsive controls are essential to that game. Final Fantasy makes movement about getting from point A to point B and interacting with things in-between, with all action taking place in the battle screen. With your control over the character less important, grid movement is used.

So ask yourself this question: How much control do you want to give your player? If you want the precise controls of something like Megaman, Metroid, Zelda, Sonic, and anything in-between, you need pixel movement for the game to feel like it's running on anything made in this decade. If movement isn't as big of a deal, you just need your character to move but not with the precision accuracy you might need in order to swing a sword or shoot a gun, go with moving along the grid tile-by-tile. It still feels good, you just need the right game for it.

There are exceptions to both of these where people have not followed these suggestions. Often times, taking a game which deserves the pixel movement and making it tiled just doesn't work out as well. Taking a game that probably should use grid movement and making it pixel movement would still work out just fine, on the other hand. Either one can work, but the former just plain, more often than not, doesn't.
Nov 28 2012, 1:28 pm
In response to Kaiochao
Kaiochao wrote:

Forum_account's Keyboard library handles it well:

Wow...that's so slim and sexy!
Nov 28 2012, 3:57 pm
In response to Kaiochao
Kaiochao wrote:
At some point they did have support for holding multiple keys at once. It was awful and they removed it.

Forum_account's Keyboard library handles it well:
> client/keys = list("w", "s", "d", "a")
>
> //  mob per tick
> var dx = client.keys["d"] - client.keys["a"]
> var dy = client.keys["w"] - client.keys["s"]
> var new_dir = offset2dir(dx, dy)
> if(dx) step(src, new_dir & 12, abs(dx))
> if(dy) step(src, new_dir &  3, abs(dy))
> dir = new_dir
>


This is how I do it, I could just get rid of the four variables and use the keys but I like the extra buffer for puzzles and other tricks (where you want to still keep the actual key value but cut off or change what that value means).

player
    var/tmp
        north = 0
        south = 0
        east = 0
        west = 0

    proc/move_loop()
        while(src)
            update_move()
            sleep(world.tick_lag )

    proc/update_move()
        var/dirs = (src.north && NORTH) | (src.south && SOUTH) | (src.east && EAST) | (src.west && WEST)
        if(!dirs) return
        if(!step(src, dirs) && dirs & (dirs - 1)) //try diagonal
            if(!step(src, dirs & (NORTH | SOUTH))) // if diagonal and step failed, try vertical
                step(src, dirs & (EAST | WEST)) // if vertical failed, try horizontal