acleverpun / letsgoonanadventure Goto Github PK

WARP ZONE??!???!?##$

/needs #11

/needs #7

Like an underground passageway, or just a building with multiple doors.

In the latter case, going in the right door of two adjacent doors should mean the player is in front of the right door when the building loads, and the same for exiting. Heh, that's a clever pun.

Right now we're using map.setCollisionBetween(), which is inefficient (at least as I understand it). What we should do instead is figure out which indices to use in the preload step, and call map.setCollision() with them.

We should have all of the functions that interact with Tiled maps be pulled out into a utility module.

And more should be added, like a generic function that parses and normalizes properties. All custom properties in Tiled are strings, but we can and should convert them smartly. Eventually maybe even convert things to our own classes, in addition to primitives.

This should be extended by player and NPCs. It should have things like speed, health (unless kill-able entities should be their own subclass, which they almost certainly should), etc.

WASD and HJKL stopped controlling movement, though the arrow keys still work.

Whether we roll our own (they are very easy) or use an existing one, we should add a simple event system.

Then we could do things like entity.on('spawn', function() {}), instead of using the stupid/ancient entity.onSpawn = function() {} convention.

We're going to have a lot of files like https://github.com/acleverpun/letsgoonanadventure/blob/master/app/entities/index.js, so we should make a (grunt) task that watches files and generates these.

It can just convert filenames to variables. For example, it would convert folders to "foldername", and files to "Filename". Dash-separated files/folders would be converted to camel-case.

Pathfinding should probably either be a mixin or a utility. Or perhaps a mixin that uses a utility?

I have some great ideas for pathfinding. Just so I don't forget:

Entities with pathfinding should have a target (perhaps a selector, outlined in #16), an awareness radius, and a field of view (angle). If a target is within the awareness radius and inside the FOV, we trigger whatever pathfinding algorithm that entity possesses.

Here are some algorithms I thought up:

• One simple algorithm could be to just move toward the (closest) target.
  • This would mean they would get stuck behind objects and scenery they collide with, which is what happens in a lot of Zelda games.
• A more powerful algorithm would be:
  1. If an enemy sees a target, it "memorizes" the position they saw it at
  2. It uses whatever specific pathfinding algorithm it has been assigned to make it's way closer to that spot, like A*.
  3. Repeat steps 1 and 2. This means that even if a target moves outside the awereness radius / FOV, the chasing entity still tries to get to the last spot it remembered, and updates the memorized position if it sees a target again along the way.

Maybe the second one does everything the first does, and we just make it support different cases, and make the specific algorithm it uses for pathfinding just be the direct path. Actually I like that. So maybe in addition to an awarenessRadius, there's also a chaseOrForgetRadius, where an entity stops chasing the target if it gets outside this radius. Then the classic dumb Zelda enemy is supported, as we can make their awarenessRadius === chaseOrForgetRadius, and the pathfinding algorithm that they would use in the second step of the above explanation would be to move in a direct line toward the target. And other entities could use different chasing algorithms, like A*.

I figure it's going to be extremely common to be all:

events: {
    use: function(entity) {
        if (entity.id === 'player') { ... }
    }
}

So instead of having to worry about stuff like that, let's make the event system more powerful. I want it to support a css-ish seletor syntax, and essentially translate it to the above.

An example of some things I want to support:

events: {
    'use#player': function(entity) { ... },
    'enter.enemy': function(entity) { ... },
    'leave.enemy[health<=50]': function(entity) { ... },
    'enter.item, enter[health], enter#player': function(entity) { ... }
}

Entity instances should create a Sprite. If the entity is marked as "visible" in the map, we will add the texture image as well, and make it render on the canvas. Otherwise, we will set as invisible (leaving physics enabled).

Also, in the loop where we create instances if the types are known, we should remove the check for "spawn". Since it's not a known type it won't be created, and thus there's no reason to explicitly blacklist it.

WarpTile instances should register a collision function that does the warping logic, instead of the crappy grid-based collision thing I implemented quickly.

Pew pew.

This will be so much easier and more scalable with states.

In a lot of places we're using objects like the following:

{
    map: 'mapName',
    x: 64,
    y: 32,
    tileX: 4,
    tileY: 2
}

This should be abstracted into a class, which would have sane defaults like setting properties that don't exist from those that do.

This should probably be a mixin.

We can start by just making it add entity.inventory = [], though I can see us eventually wanting to make it a subclass of Array.

/needs #18

When a player crosses map boundaries.

Signs, bushes, pots, etc.

Preferably when they hit boundaries on the viewport, like Zelda and that demo you like.

/needs #9, #1

I think we can benefit from both classes and mixins. We need to come up with a nice implementation for mixins that makes them easy to use, with the requirement that any entity extending another one gets the mixins of the parent.

Right now, exiting buildings spawns the player on the warp tile to enter the building, preventing them from being able to exit. I'm temporarily working around this by making the warp targets go one more tile south, but this is not a real solution.

I suspect this may be fixed (or at least affected) when we migrate to Phaser's collision system instead of a custom one I built from scratch.

https://github.com/crispy1989/inheritz

• wasd
• hjkl
• ,aoe