Changes:
- Re-added support for fractional moves. Previously, calling pixel_move(1.5, 1) would be the same as calling pixel_move(1, 1) because the decimal part would be ignored. Now decimal parts are accumulated so that mobs always have integer coordinates and perform integer moves, but when the fractional moves accumulate enough, the move will be augmented to reflect this. For example, calling pixel_move(1.2, 0) five times will make the mob move a total of 6 pixels, one of the moves will make them move two pixels, the other four just one pixel each.
- Changed some things in pixel-movement.dm to hopefully avoid some division by zero errors. They hadn't been causing problems (at least not that I'd noticed), but seeing runtime errors is always annoying.
- Added the NO_STEPPED_ON flag. Enabling the flag disables the definition of the atom.stepped_on, stepped_off, and stepping_on procs. If you're not using these procs you can enable this flag to improve performance.
The reason this feature is useful is because it gives you finer resolution of the speed that mobs can move at. Without this feature, if you set a mob's move_speed var to 3.5, they'll move 3 pixels per step. The decimal always gets truncated, so this is the same as if their move_speed is just 3.0 to begin with.
The way the feature works is that it only performs integer moves but it accumulates the fractional parts. When you call pixel_move(1.2, 0) it'll usually make the mob move one pixel. Internally the pixel_move proc will truncate the decimal and perform the move (1, 0). But, it accumulates the fractional parts by adding the 0.2 to a separate variable (called _px). When this count goes above 0.5, it adds one to the move (when it goes below -0.5 it subtracts one from the move). You can test it out with a verb like this:
mob/verb/test()
world << "px = [px]"
for(var/i = 1 to 5)
pixel_move(-1.2, 0)
world << "px = [px]"
sleep(world.tick_lag)
world << ""
The output statements will only ever report integer coordinates, but you'll notice that four of the calls to pixel_move will make you move one pixel, one call will make you move two pixels. If you call the verb when you start up the world, it'll be the third move that makes you move two pixels.
Using Pixel Movement
Bravo1 has posted about a new game, called Tanx, just a few days ago. His post two days later includes a video showing the addition of more weapon types. I mention this for a few reasons:
1. It looks neat. It's a simple concept that'll be fun to play. From a game designer's perspective it's not as limited as Darkness and from a game player's perspective the controls are easier than Toy Tanks and it has AI.
2. Based on the dates of the blog posts, it was probably put together in less than a week. Compare this to Chris Gayle's Armored Units project, which he blogged about two months ago, then again 4 days ago and it doesn't look like much progress has been made. For fun, here's my version which took about 20 minutes to make. Also compare it to Oasiscircle's Toy Tanks, which he first blogged about on Feb 18th (though some of the underlying work had been started already) and released about a month later.
3. He's not saying "oh no, BYOND might not be able to support my idea for a 100 player RPG so I'm going to make you think I had an excellent game idea but you'll never know it was actually a terrible idea because the game won't be finished and it's all BYOND's fault." He's actually making the game. Will it be finished? Maybe. Will it be polished (ex: have a title screen)? Maybe. Will it be playable? It already is.
Bravo1 has found some way to use the resources that are available to make more significant progress on games than other people can make in the same amount of time. Either he's a genius coding fiend who doesn't sleep or he finds ways to make the most of his development time. I used the examples that I did because the games are similar and all use pixel movement (and, as far as I know, Tanx is the only one that uses a library for pixel movement). I'm not trying to say that they're bad developers, I could have used anyone for the comparison, these were just the most similar projects. I don't want to sound like I'm saying "you should use my pixel movement library" but:
1. There aren't any alternatives. A while ago I made a list of the alternatives, most aren't any good. My message is "use libraries when they'd help you", but I'm talking about pixel movement and there aren't many alternatives, so I can't help that the message comes out as "use my library".
2. I do think you should use my pixel movement library. I've put a lot of effort into it and it's a very good library and improving all the time. It gets updates once or twice a month and benefits from some new BYOND features (as well as BYOND bug fixes).
So, in the spirit of some other recent blog posts (like this one from CauTi0N and this one from Yusuke13), if you want to get a game done quickly, look around to see what resources are available to help you get it done. Even if it takes a week to find and understand these resources, it could easily cut more than a week off of your game's development time.
Edit:
Other Stuff
I don't have much time to work on BYOND projects, but here are some things I plan to work on.
1. Tiny Heroes. I have enough basic enemy types added for the second dungeon, I just need to make the boss encounters. Speaking of that, I also need a generic way to handle boss fights - making them start/stop/reset, handling victory and defeat conditions with potentially any number of players fighting the boss, difficulty settings, etc.
2. Sidescroller library. Generally, any update for Pixel Movement can be applied to Sidescroller, but the recent optimizations don't really apply. It's always in 2D mode and always needs to call set_flags. There are some other optimizations and I do plan to add the way that PM supports fractional moves to Sidescroller.
3. A while ago I had some game development articles planned, but they're on hold for now. When I don't have a lot of time to spend on BYOND, I prefer to spend it working on my projects. Articles come second.
