Sidescroller

by Forum_account
[Share] [Zip]
ID:112577
 
I always think I'm running out of things to add to the library, then I put together an update and the update notes are even longer than the previous one. Maybe I'm just writing more detailed update notes.

The library has a new demo called "v2.4" which shows what the new features are and how they work (I'm not sure why I didn't think to add a demo for each new version earlier!). If you'd like to just read about it, here are descriptions of the new features in version 2.4:

Camera Control

The update includes many new camera options. The options are contained in the mob's camera var, which is an object of type /Camera. This is a simple object that contains some vars you can use to change how the camera is handled.

mob.camera.px, mob.camera.py

These are used to set the position of the camera. To move the camera up by 96 pixels you can do this:

mob
set_camera()
..()
camera.py += 96


mob.camera.lag

The camera.lag var controls how many pixels the player can move from the camera before the camera will move to follow the player. By default this is zero - every time the player moves the camera will follow.

mob.camera.mode

The camera.mode var can be set to either camera.FOLLOW or camera.SLIDE. The default mode is follow. In this mode the camera moves as fast as the player does to constantly track the player. In the slide mode, the camera will speed up and slow down to follow the player using smoother motions.

mob.camera.minx, mob.camera.maxx, mob.camera.miny, mob.camera.maxy

These vars define a rectangle that the camera will stay inside of. You can use this to create rooms. When the camera scrolls too far it might reveal what's inside the next room and ruin a surprise, this can be used to prevent that. You can also use it to control how the camera scrolls - if miny and maxy are set to the same value, the camera will only scroll horizontally.

In the "v2.4" demo, several areas are created. When you enter an area the camera bounds are changed. This way you just have to define the bounds, place the area on the map, and the library takes care of limiting the camera's movement.

atom.stepped_on, atom.stepped_off, atom.stepping_on

The stepped_on proc has existed for a while now, but in this update it gets a change. Now, the stepped_on proc is called when a mob begins to stand on top of an atom (the mob is the argument to the proc). The stepped_off proc is called when the mob stops standing on the atom. The stepping_on proc is called every tick for as long as the mob is standing on the atom (this is how the stepped_on proc used to work). Also, for stepping_on, there is a second argument which is the number of ticks that the mob has spent standing on the atom. This way, if you want to make a lava floor tile that hurts the player once per second for as long as they're standing on the tile.

Here is the complete list of update notes:
  • Added a demo called "v2.4" which shows how to use the features that are new in this
    version. I used to add examples of new features into whatever existing demos were most
    relevant. I wish I had thought of doing it this way sooner!
  • Added the flags_left, flags_right, flags_top, and flags_bottom vars which behave
    just like atom.flags except they let you define properties for individual sides of
    the atom. The mob's flags are binary ORed with the atom's flags var and the specific
    side's flags var.
  • Added camera.dm which contains the set_camera proc (which was previously in pixel-movement.dm)
    and the /Camera object. A var called "camera" was added for mobs that's an instance of the
    Camera object. This object stores all properties related to the camera.
  • The camera.mode var can be set to camera.FOLLOW or camera.SLIDE to switch between a camera
    that strictly follows the mob and one that speeds up and slows down to smoothly follow the mob.
  • The camera.lag var can be used to specify the number of pixels the mob can move away from
    the camera before the camera will move to follow the mob.
  • The camera.px and camera.py vars can be used to set the camera's position.
  • The camera.minx, camera.maxx, camera.miny, and camera.maxy vars can be used to specify
    bounds on the camera's position. The set_camera proc's default behavior will not move the
    camera outside of these bounds.
  • The camera can still do some weird things when you use EDGE_PERSPECTIVE, so I recommend not
    using it and instead using the minx, maxx, miny, and maxy vars to enforce camera bounds near
    the edge of the map.
  • Added the stepped_off and stepping_on procs and changed how the stepped_on proc works.
    stepped_on is called only once when you first step on an atom, stepped_off is called
    once when you stop standing on an atom. stepping_on is called every tick for the whole
    time you're standing on top of the atom.
  • Updated the reference to include all new vars, procs, and objects.
I played with the library for a while and the largest problem I faced was moving atoms into specific locations or patterns without using vel_x or vel_y. I tried doing this with a variety of the procs the library provided however there were always problems in which the atoms would behave awkwardly by randomly falling through the floor among other things
If you want to teleport a mob you can set its loc (ex: loc = locate(1,2,3)). If you want to make a mob move around (like what you'd achieve using step() or walk() in a tile-based game) you can use pixel_move(), move_to(), or move_towards(). You could also call move(RIGHT) or move(LEFT), you shouldn't need to modify vel_x and vel_y directly.

Edit:
To elaborate on this, calling pixel_move() is like using the step proc, it makes the mob perform a single move. Calling move() is similar to step(), except it enforces the default rules for how mobs speed up and slow down (it modifies vel_x, pixel_move doesn't). If you wanted to create AI for an enemy that moved like a live player you'd call move(), if you wanted to make a moving platform that just moves back and forth, you'd use pixel_move(). move_to() or move_towards() are like walk_to() and walk_towards(), they can cause many moves to be performed over a long period of time to make a mob move towards a destination.
/Edit

There's a simple example in "interaction-demo" that shows how to make mobs that move back and forth across a platform. It's very simple (7 lines).

Falling through the floor sounds like a problem with can_bump() or with the pwidth settings. If you can identify the problematic code and post it on my forum I can help you out.
Those camera controls seem pretty neat. You could probably take the same basic principles and port them over to a regular tile-based movement system.
The camera code just needs the mob to have px and py vars. With tile-based movement you might not have access to precise pixel coordinates because BYOND handles the visual transition between tiles, but at the very least you could set px and py in mob/Move() and slide mode should work.

I'd be curious to see how it works over the network. Lag might screw it up a little, but BYOND's camera control has problems of its own, so this might work out better.
No, I mean you'd be able to set up something similar to EDGE_PERSPECTIVE out in the middle of the map. The camera wouldn't use pixel movement.
Friends. Yes? Friends. We are friends. Good friends.

Forever.

I love you.