kxcrl / foundryvtt-retro Goto Github PK

Context

The sprites we were testing with don't clearly demonstrate all of the different valid sprite styles. We need to add some that make everything more clear.

Context

Currently, sprite movement is based on a hardcoded timer that starts when movement starts and ends at a predetermined time. This causes the sprite to pause before moving again if the player moves multiple times in a row.

Instead, run the movement animation until the token has reached the specified position. Once all movement has stopped, then the animation can stop.

Context

Currently, tokens only have sprites added if they are dragged onto the scene. Sprites need to be initialized for any tokens existing within the scene at load/refresh time as well.

Currently the only valid sprite tiles are 64px x 64px. They should be set to the same size as the grid.

Context

It is possible that someone will want to have a very high fidelity walking animation, or an idle animation that needs to play a bit faster to look correct. In either case, they should have the ability in the module config to adjust the current play speed.

It will be important to note in the settings that they are not adjusting FPS. Since we are using JavaScript, every frame is always played. This only adjusts the speed at which the stack is flipped through, so it will have to be adjusted and checked.

Context

It's useful to be able to set an image for a given Actor so that it can have a graphic in the UI. However, we only want to render the Actor's sprite once it's dragged onto the canvas.

Notes

Instead, maybe override the default token image to be whatever is at 0,0 (or some other setting) on the sprite sheet.
Or maybe have an option to override/hide/etc default images in the global module settings.

Context

#13 Will add support for front facing sprites, switching to them by default. The code for top-down controls is still in place. Add a setting in the module config to switch between them.

Feature

Enable a switch for Top-down Sprites, default to False

Context

This is for sprites that use the Final Fantasy or Chrono Trigger style, rather than the classic Rogue style. While these still have a defined base (usually 1x1), the image overflows upward onto the tile above. The contents of the above tile sit behind the sprite, giving the illusion of depth.

Feature

Assume that sprite sheets that are multiples of TILE_SIZE greater than 4 have offsets. Use the bottom tile as the base and overflow everything else upward.

tilePosition should more or less make this trivial, since it can just be set to a larger multiple of TILE_SIZE (instead of the current * 0, * -1, etc)

Context

Very few Roguelike games use art that is truly top down, where you see the top of the character's head and they face in whatever direction you're moving. Most use a forward facing art style, where you see the whole front of the character and they only change direction if they turn around.

Feature

Default to front facing sprites.

Context

Currently, the module only handles a single sprite sheet. This should instead be set as the idle animation, and a new sprite sheet should be added for walking animations.

Feature

Add a walking animation sprite sheet. As soon as a movement key is pressed, play the corresponding walk animation, then return to idle.

Note

Alternatively, this could just be part of the same sheet.

Allow people to add arbitrary events and then jump to an arbitrary Y position and animate across the X axis when the events fire.

Options:

1. Play once before returning
   • A sprite facing to the right at y=1 may have a walking forward animation at y=5. In this case, when moving to the right, it should play the animation at y=5 and then return to y=1 while idle.
2. Play continuously
   • A sprite may have an alternative animation for its current idle state at some other y value that it switches to as the result of an event.
3. Play once and stop
   • A sprite may have a dying animation that it plays once through, halting at the end and no longer animating

Context

Currently, path movement does not engage the animation system at all.

Context

The spriteControls function is currently global, affecting all sprites that belong to the player. While they can still be globally listened to, the sprite tiling should only happen to whatever token or tokens are currently selected.

Context

Movement animations may have more frames than idle. The number of frames for a given animation block should be able to be set, rather than defaulting to the entire sprite sheet width.

Tile every sprite at its current Y position across the X axis to create an animation.

const frameCount = 0;

function animateSprites(sceneSprites) {
  sceneSprites.forEach((sprite) {
    if (spriteSheetWidth == 100px) {
      return;
    }

    if (atEdgeOfSpriteSheet(sprite)) {
      sprite.tilePosition.x = 0;
    } else {
      sprite.tilePosition.x += 100;
    }
  })
}

canvas.app.ticker.add(() => {
  if (frameCount % FRAME_RATE == 0) {
    animateSprites(sceneSprites);
  }
})

Context

While moving tokens via keyboard works fine, tiles cannot be selected and moved by mouse without throwing errors.

Context

Now that we're setting flags that don't get persisted to the db, we need to make sure they don't stick around between scene loads. They shouldn't, but it would be wise to double check.

If they do, add a function to onInit to clear them.

Context

It's not technically a problem to have them face upward by default, it's just probably the least likely first pose that anyone would want.

Context

If a sprite has no x value beyond TILE_SIZE, then it shouldn't have tickAnimation added as it will never animate and only return false.
If a sprite has no y value beyond TILE_SIZE, then it shouldn't have spriteControls added as it will never change directions and only return false.

Context

Right now, selecting a token places a large, unsightly orange square right over the top of it. At the very least, this square should have a lower z-index than the sprite so that the top wraps behind it. It might be even better to have it just be the corners of the square, or maybe [ ] or something. It would be even better if it animated slightly, slowly scaling up and down in a gentle LFO rhythm.

If it does animate, it should probably be possible to turn the animation off in the settings.

Context

Change expected sprite sheet order to Down, Left, Up, Right

Context

In order to give the illusion of depth, 2D sprites that are lower on the Y axis should be in front of those that are higher up.

Context

The FilePicker code comes from referencing an old module. There is now a handlebars FilePicker helper that should be used instead.

let renderedConfig = await renderTemplate('../templates/config.hbs')

{{filePicker type="image" target="img"}}

See the handlebars helper docs