I'm fairly satisfied with the state of my Sidescroller library but there are still lots of things I'd like to add to it. Part of the problem is that the library has a somewhat infinite scope - it's not just enough to provide a sidescroller's movement system, I need to provide ways to help all aspects of developing an action-platform game.
The version 2.1 update includes some basic pathfinding features. It defines the move_to and move_towards procs, which behave like DM's walk_to and walk_towards procs. The update adds a new demo, called "pathing-demo", which demonstrates the use of these procs. Click on a tile to move towards it. Press "1" and "2" to select between the use of move_towards and move_to.
The move_towards proc (which, unlike walk_towards which is global, belongs to the mob) takes a single argument - the destination. After calling this proc, the mob will follow some basic rules to move towards the destination. If the mob is currently to the left of the goal, it'll call move(RIGHT), if it's to the right of the goal, it'll call move(LEFT). If the mob bumps into something it'll call jump() - this makes it able to jump over small obstacles, or jump up stairs.
The move_to proc also belongs to the mob and also takes a single argument, the destination. When you call the proc, the library uses an A* search to identify a path. Then, it follows some basic rules to follow the path. It has a few problems:
1. Path generation is not perfect. It assumes you can only jump 1 tile high (which, in the demo, is all you can do). It also doesn't take into account your movement speed - if you can move fast enough, even with a one-tile-high jump you might be able to leap across a span of 3 or 4 tiles. It doesn't consider your ability to do this.
2. Path following is not perfect. The path is a list of turfs. To follow a path, the mob uses rules similar to the ones for move_towards (there are differences) to move through each turf in the list. The path is a rough estimate of how the mob can move - the actual movements to follow the path can sometimes miss a turf. Usually this isn't a problem, the mob'll just move back to hit the missed tile. If this missed tile was part of a tall drop, the missed tile might be out of reach. The mob will get stuck trying to reach the unreachable tile (though eventually they'll detect being stuck and compute a new path).
3. The path finding and following routines don't take into account ladders, mobs, or turfs that are platforms (turfs you can both walk in front of and stand on top of). I don't see any reason why it's not possible to include support for ladders, but moving platforms and non-turf obstacles might present problems.
Mar 7 2011, 2:46 am
|
|
Kisioj
 |
This is so great :D
|
Kisioj wrote:
This is so great :D Thanks! I figure I should mention the other things I'd like to add to the library. People can offer code or ideas to contribute, or more likely just say what feature they'd like to see next. 1. Better background support. I'd like for the library to make the backgrounds repeat automatically. I'd also like support for multiple backgrounds to exist at the same time. 2. More complete demos. I'd like to have demos that contain many of the features you see in popular sidescrolling games (mario, metroid, etc.). A lot of these features are already covered in demos or are easily implemented, but I think it would be beneficial to offer more complete packaged demos. 3. More graphics. As nice as the blue box and gray walls are, people aren't likely to use those graphics in their game (though, one of the few games made with the library does use them). If BYOND's pixel art community was more active I'd hold a contest for making sidescroller tiles and mobs, but I wouldn't expect this to go well. 4. More AI examples. This could be included as part of #2, or it could be its own demo. I added the pathfinding proc because I've been working on AI for some projects, hopefully I can include more about AI as I develop it. BYOND is lacking quality AI in top-down games, which makes it even more important to have good AI support for this library. 5. Documentation. I updated the reference info contained in the reader but I'd like to generate DM reference pages for all vars and procs. At the very least this'll help me keep things straight. 6. Code organization. The movement proc does too much. I'd like to find a way to split it up so you can override logical parts of it. Overriding the proc means you lose a lot of stuff (which is sometimes what you want), but I think it could be organized better. What I'm leaning towards is creating a new proc (probably called action) that handles the processing of keyboard input and the call to follow_path. This way you can change how a mob behaves without having to make sure you call set_flags, gravity, set_state, and pixel_move. Edit: added this one: 7. Camera control. I'd like to have some way that you can place atoms on the map to define how the camera can move. This would let you easily create Mega Man style levels where some screen only scroll horizontally, some scroll vertically, and some don't scroll at all. My best idea for this requires using areas, which I don't like because developers wouldn't always be able to use this camera control with other features that rely on using areas. | |