I've started working on my Pixel Movement library again. Its development had always lagged behind my Sidescroller library - I'd add a feature to the sidescroller library, then add it to Pixel Movement. That sounded like a good plan but I didn't keep it up. The pixel movement library had fallen way behind.
For a few reasons I have a renewed interest in the library and started working to get it up to date. Most of the features are very easy to port over, here's what's done so far:
* mob.move_to and mob.move_towards procs
* the mob.camera var (and all the behavior associated with it)
* atom.flags var (and flags_left, flags_right, etc.)
* mob.move_speed and mob.fall_speed vars
* the mob.action proc
I've also added a couple of new things that'll make it easier to use the library.
First, the library tries to manage the player's icon_state, but if it detects that the icon states it's trying to use don't exist, it won't change the mob's icon_state. If you don't know the library will look for "standing", "moving", and "jumping" states and you don't create them, it won't try to use them.
Second, if you don't set a value for pdepth (how tall the tile is) it's set based on the density of the atom. The library treats every turf as being dense, even things like floors, which you'd normally think of as being non-dense. If the floor wasn't dense you'd fall right through it. If you don't understand how this aspect of the library works (or if you don't use jumping, or anything that changes the pz coordinate of mobs) then, without this feature, you'd be confused when you can walk through dense walls.
If you don't set a value for pdepth, the library will set it to 32 if the atom is dense and 0 if it's not. This way if you set an object's density but don't know that you'd need to set its pdepth value, it'll be taken care of and should behave as you'd expect.
There are some things I'd like to add before posting an update. I'd like to add ramps, but it's not likely that they'll be in the next update. I'd like to limit the player's total speed in the x and y directions (currently they're limited separately). I'd also like to add more demos - some would show how to use certain features of the library, some would show how to create new features that you would commonly see in games. If I have time I'll make a Zelda-like demo and maybe a top-down shooter demo. I'm not sure what other top-down games would make use of pixel movement.
I also need to update the documentation (I'm not looking forward to that).
Once the update is posted I'll put together an article about how to use the library. Something like this, but for the pixel movement library.
Now that BYOND v482 has been posted, I'd like to update the library today.
Aside from lots of features I've added a couple of new demos. I'm trying to make some more complete examples to show how you can use the library, not just some toy examples to demonstrate simple features. The first of the more complete demos is a Zelda-like game. It has melee attacks, enemies (that shoot projectiles), and camera control similar to the original Zelda game. The second demo is a top-down shooter. It's still in progress, but I'd like for it to show off more projectiles, more complex maps, and movement in the z direction (jumping, ramps, etc.). The problem is graphics. I used Zelda sprites for the Zelda demo, but I don't have any sprites for the shooter. I'd like for the demos to be more than just blue boxes and gray walls. Does anyone have some mob icons that they wouldn't mind being included in the library? | |
My biggest concern was figuring out what vars would be needed to define a sloped tile. The Sidescroller library lets you define the height of the tile at the left and right sides, but this doesn't really transfer to this library. What I settled on is having two vars, ramp and ramp_dir. ramp_dir is the direction of the incline (ex: NORTH for tiles that get higher towards their north side) and ramp is the amount of height change.