rosshadden / mmorpgkthx Goto Github PK

Self explanatory.

The user should probably remain in the center of the viewport at all times.

Right now buildings are in the following format:

{
    "type": "building",
    "src":  "img/pokemon.png",
    "where": {
        "x":    6,
        "y":    4
    },
    "x":    0,
    "y":    0,
    "w":    82,
    "h":    70,
    "dw":   75,
    "dh":   70,
    "door": {
        "map": {
            "x":    1,
            "y":    1
        },
        "instance": {
            "x":    7,
            "y":    6
        },
        "at": {
            "x":    7,
            "y":    6
        },
        "to": {
            "x":    12,
            "y":    15
        }
    }
}

items are in this format:

{
    "type": "item",
    "src":  "img/zelda.png",
    "where": {
        "x":    14,
        "y":    14
    },
    "x":    102,
    "y":    659,
    "w":    16,
    "h":    16,
    "dw":   25,
    "dh":   25,
    "data": {
        "contents": [{
            "id":       4,
            "amount":   2
        }]
    }
}

and structures are in this format:

{
    "type": "structure",
    "src":  "img/wall.jpg",
    "where": {
        "x":    23,
        "y":    1
    },
    "x":    0,
    "y":    0,
    "w":    154,
    "h":    154,
    "dw":   25,
    "dh":   25,
    "repeatY":  13,
    "except": [{
        "x":    23,
        "y":    2
    }]
}

In order for objects to be partially drawn, the format needs to be changed to something that contains a list of tiles the object contains. Something like this (for buildings):

{
    "type": "building",
    "src":  "img/zelda.png",
    "where": {
        "x":    6,
        "y":    9
    },
    "x":    106,
    "y":    303,
    "w":    96,
    "h":    64,
    "tiles":[{
        "x":    6,
        "y":    9
    },{
        "x":    7,
        "y":    9
    },{
        "x":    8,
        "y":    9
    },{
        "x":    6,
        "y":    10
    },{
        "x":    7,
        "y":    10
    },{
        "x":    8,
        "y":    10
    }],
    "door": {
        "map": {
            "x":    1,
            "y":    1
        },
        "instance": {
            "x":    7,
            "y":    10
        },
        "at": {
            "x":    7,
            "y":    10
        },
        "to": {
            "x":    12,
            "y":    15
        }
    }
}

Add a chat module.

Possibly with tabs, for public, party, pm, et cetera.

Needs to either be unintrusive or not exist at all.

Login information to be moved to menu. This will allow for more viewport real estate, as well as greater willing suspension of disbelief.

Users will have to open the menu to sign out.

When changing maps, users on the map the player is changing from are still shown on the new map.

When these users move, however, they do not actually move on the player's screen (which is the desired result).

Seriously. I dunno if it's viewport.center() or what, but if you move somewhere and refresh the page it becomes bjorked.

The position objects are very clunky and unorganized.

Implement the ability for users to choose their own username, perhaps prefilled with the username from the account they signed in with.

In favor of faster development, players were given public properties and methods. This needs to be changed before release.

A map editor should be created for easy creation/changing of maps. The map format may well change over time, so the map editor should be able to adapt to these arbitrary changes.

This is a commented example of a building with a door (JSON does not allow for comments, or I would comment one of the map files):

{
    "type": "building",         //  Type of object.  Currently 'building', 'structure', and 'item'.
    "src":  "img/pokemon.png",  //  Source of the sprite sheet file.
    "where": {                  //  Location (in grid coordinates) where the object should be in the map.
        "x":    6,
        "y":    4
    },
    "x":    0,                  //  Location of the object IN THE SPRITE SHEET.
    "y":    0,
    "w":    82,                 //  Dimensions of the object IN THE SPRITE SHEET.
    "h":    70,
    "dw":   75,                 //  Dimensions of the object in-game.
    "dh":   70,
    "door": {                   //  Object containing info about the door.
        "map": {                //  Which map the door points to.
            "x":    1,
            "y":    1
        },
        "instance": {           //  Which instance the door points to inside the given map (typically the same as the location of the door).
            "x":    7,
            "y":    6
        },
        "at": {                 //  Location of the door.
            "x":    7,
            "y":    6
        },
        "to": {                 //  Which grid tile the door takes players to, inside the given map and instance.
            "x":    3,
            "y":    7
        }
    }
}

This is a commented example of an item:

{
    "type": "item",             //  Type of object.  Currently 'building', 'structure', and 'item'.
    "src":  "img/zelda.png",    //  Source of the sprite sheet file.
    "where": {                  //  Location (in grid coordinates) where the object should be in the map.
        "x":    14,
        "y":    14
    },
    "x":    102,                //  Location of the object IN THE SPRITE SHEET.
    "y":    659,
    "w":    16,                 //  Dimensions of the object IN THE SPRITE SHEET.
    "h":    16,
    "dw":   25,                 //  Dimensions of the object in-game.
    "dh":   25,
    "data": {                   //  Meta-data for the object.
        "contents": [{          //  Contents of the item (chest, in this case), in array form so that chests may contain multiple items.
            "id":       4,      //  Chest contains item with an id of 4.
            "amount":   2       //  Chest contains two of these items.
        }]
    }
}

Aaaaand this is an example of a structure (a wall):

{
    "type": "structure",    //  Type of object.  Currently 'building', 'structure', and 'item'.
    "src":  "img/wall.jpg", //  Source of the sprite sheet file.
    "where": {              //  Location (in grid coordinates) where the object should be in the map.
        "x":    23,
        "y":    1
    },
    "x":    0,              //  Location of the object IN THE SPRITE SHEET.
    "y":    0,
    "w":    154,            //  Dimensions of the object IN THE SPRITE SHEET.
    "h":    154,
    "dw":   25,             //  Dimensions of the object in-game.
    "dh":   25,
    "repeatY":  13,         //  Object repeats vertically in this case, for 13 tiles.
    "except": [{            //  Although it repeats for 13 tiles, it has two exceptions in the repeat, which create two gaps in the wall that players can walk through.
        "x":    23,
        "y":    2
    },{ 
        "x":    23,
        "y":    3
    }]
}

And then here is an example of a door object INSIDE a building (a tile that warps players back outside when stepped on). Note that these background tiles go inside an array of tiles inside a background object in the map for now:

{
    "type": "building",
    "src":  "img/pokemon.png",
    "where": {
        "x":    3,
        "y":    7
    },
    "x":    1,
    "y":    92,
    "w":    16,
    "h":    16,
    "dw":   25,
    "dh":   25,
    "door": {                   //  Door located at (3,7), warps to location (7,7) in the same map that the building is in (which is why 'map' is unspecified here).
        "at": {
            "x":    3,
            "y":    7
        },
        "to": {
            "x":    7,
            "y":    7
        }
    }
}

Some things to keep in mind:

• If a building does not have a door, it simply omits the door object.
• If a structure does not repeat or has no exceptions, it simply omits repeatX, repeatY, and except.
• Order shouldn't matter, but the maps might as well have everything in the same order for consistency.
• Although the engine currently uses the format outlined above, that does not mean it is the format that has to be used. The adaptation is a two-way street.
• The important thing to note is that since I was able to programmatically split buildings into individual tiles, we do not need to list every tile that is used--only the top-left tile in most cases.

Debate whether objects with .x and .y should be made into Point objects, with functions like Point.prototype.toGrid() built in.

Throw some of the visual ideas Sean came up with for the menu into play, such as the glowing volcano, running water, and floating clouds.

The menu also needs to have a parchment-esque background.

Yeah. For real.

When a player moves, all objects (including other players) in the viewport need to move (so they player will appear to stay in the center of the viewport).

And when a player is stationary, they need to move as usual.

When a user opens a chest, even though they are shown adjacent to the chest on their screen, their position on the server is actually set to that of the chest.

Thus if a user clicks a chest and then refreshes the page, their character is located on the same tile as the chest.

For some reason, players can enter buildings but not leave them. I believe this is because position.instance is still set during world.collision.onEdge()... Very confusing.

Move the socket events from server.js to another file.

When the players were rendered via the DOM, it was essential to have multiple canvases. Now that everything is drawn on a canvas, they should be merged into one for more efficiency.

My original reasoning for keeping a separate buildings canvas (for instance) is that buildings would only need to be drawn once per each map change. However, now that the viewport will be moving with the player, this is no longer true.

Render remote players in a way such that they do not move with the viewport.

Position, inventory, and any other relevant information needs to be saved to a database of some sort. Restarting the server should not lose this information.

Increase the dimensions of the map files.

Recreate Player in a way that allows for a Me (thinking of a better name) object to inherit from it, while having access to the constructor argument (user) and being able to override the move() function (and others).

Figure out OAUTH / OAUTH2 / etc.

Adding the offline authentication seems to have broken the existing module. Twitter and Github still let users log in, but Facebook and Google do not.

For some reason even though the collision is all handled by the server, players do not move around buildings and objects. Nor do they trigger changeMap, but that's because I haven't made them do so yet.

Viewport needs a .getCenter() function, which finds the rounded center tile of the viewport.

It also needs a .center() function, which centers it on the player.

Right now the onEdge function looks to world.dim, but now that the world dimensions change per map this breaks certain features.

Hahahaha when another player moves, it moves the client's viewport. This is hilarious!

Doit.

• Server:
  • log()
  • timestamp()
• Client:
  • output/echo/print() [outputs to some sort of running log]

For some reason tiles with layer: 'background' render only about half of the time.

Wtf?

Positions are already saved to the server's memory. This information needs to be sent to the users as they login, and the users need to use it.