tiny-devs / tiny-dungeon-online Goto Github PK

We should consider move the project to Deno. What do you guys think?

Add tslint to project and clear out any warnings

It would be very helpful to put in help on how to play the game.

This is very annoying. Also, it would be very nice if the "enter" key would toggle focus between chat and game

rank still has some weird behaviours

In order to avoid a level 1 dude wearing a lvl 100 armor and getting tons of defense from it, we need to restrain item usage based on minimum level required to use it

Currently damage is calculated like so:
totaldmg = (random from 0 to total atack) - (random from 0 to total defense)

this creates a weird behaviour, that causes a very low level enemy to be able to cause a lot of damage when the random values are max atack and 0 defense.

Whenever someone is in another room and a new player logs in, the player on the other room won't see the new logged player.

I think it's just a matter of broadcasting the login to all rooms, like

for (const room of this.map.rooms)
// broadcast new login

• Use offscreen Canvas (since we are not rendering images, this is not useful)
• Use multiple layered canvases

  <canvas id="ui-layer" width="480" height="320"></canvas>
  <canvas id="game-layer" width="480" height="320"></canvas>
  <canvas id="background-layer" width="480" height="320"></canvas>

• Render screen differences only, not the whole new state (validate viability).

Links:
Improving HTML5 Canvas Performance

Like we did on #4 , we should encapsulate server code on a class and properly set everything up, instead of loose variables and methods on the index.js file

NPCs that can comunicate with one or more lines of text

Change transferred data from string objects to ArrayBuffers

Instead of using loose numbers, create an enum with all room's ids, like

export enum Rooms {
    InitialRoom = 0,
    Woods,
}

Using js files on the client is getting very messy, specially on the index.html file (we have to add the scripts by hand and GET one by one, without minification and bundling).

Perhaps we should migrate our JS code base to ts and serve only a bundle file, this would also unificate our code base to the same spec.

Create a .ts file exporting all types of commands on the server so far, each one will represent a command (login, move) and will have an Id defined by the commands enum.

Basic XP and leveling, also a menu to see your stats

Now that we have implemented basic NPCs (#58 ) we need more complex and active NPCs, more like enemies. In order to accomplish so, the following tasks must be done:

• Collision with NPCs (both ways, player and NPC)
• "Follow" system for aggressive NPCs
• Simple fight system (both NPCs and players now must have "life", which will be reduced after collision with aggressive NPCs)

Today we have somethings like "command": 'player-login', case 'walk-command':, command: 'walk-command'.

We should take these string constants and use the constant variable, to turn this:

command: 'walk-command' ...

into this:

command: commands.WALK ...

Any user can click multiple times on the login button, creating several login requests.

Configure despawn in order to avoid too much objects in memory

At public/js/client.js line there is the following code:

let gameConfigs = {
    width: 500,
    height: 500,
    boardRows: 7,
    boardColumns: 7
};

This code defines how the client will draw the board, but at index.js (server) you can find the following code:

var boardRows = 7;
var boardColumns = 7;

We should remove the properties boardRows and boardColumns from the client and leave them only on the server side, whenever the client logs in we get these properties before instantianting the Game object on the client.

We need to document the entire process of contribution, From setup and execution, to a pull request

We need setup deno bundler for all javascript files.

Official docs about Deno Bundler

Basic bag system and item spawning, picking, using and/or droping. We could start with something like "boots" that give more speed (speed is controled by the delay movement method), or food that restores hp.

• server
  • maybe a new layer for drops
  • logic to spawn, pickup, use, drop
  • broadcasts
• client
  • drawing new items (sprites layer)
  • backpack design
  • system to use/drop/wear items and send info to server

Testing the game in the current version that uses Deno runtime and native web sockets.
I found performance problems in simple tests like moving the character on the screen quickly, it ends up crashing the server.

These are the deploys I tested:
Old version on Nodejs and socket io
New verison on Deno and native web sockets

Today we add each new file to be served on a list of strings that correspond to a file path, like this:

      const publicFiles = [
        'board/Board.js',
        'board/layers/BackgroundLayer.js',
        'board/layers/SolidLayer.js',
        ...
        'Game.js',
        'Main.js'
      ];

It would be much easier if we could just scan the client folder and create this list of paths/files automatically. I believe it can be done using "readdir" like this:

      const publicFiles = await methodThatUsesReadDirToCreatePublicFilesArray()

Here's the "readdir" documentation

On the client file we have lots of loose variables and functions that are related to the socket client, e.g. var socket = io(), var playerList = [];, function checkKey(e), and others.

We should create a class (maybe in a sepparated file) to encapsulate these variables and methods, in order to organize the code, make it more readable and consistent. It would be something like:

class Client {
  constructor(game) {
    this.game = game;
    this.socket = io();
    this.playerList = []
...

And then instantiate this class inside the Game object on the client, controlling everything else from there, like:

class Game {
  constructor() {
    this.client = new Client(this);

The difficulty curve is absurd

Press and hold should move the player

• what's the most affordable approach for the server (aws ec2? heroku?)?
• how many players will we accept simultaneously?
• should we have more than one server (like "server1.tinymmo.com, server2.tinemmo.com, ....")?
• can we get enough people to fund this project?

With help of some friends we thought of a really cool idea to persist a player's data, similar to having an account system.

First we debated about local storing all data from player, but this would be very unsafe since the server would have to trust information from the client, and anyone could mess around with this.

Then we thought of encrypting this data, and this sounded really feasible, since there are very secure encrypting methods and here's how it could work:
remember on PS1 games, when you were given the option to save your progress on memory card OR save your progress by writing down a code, that would be a sequence of button presses, then to load the state you were, you would just type down that sequence?
It's just like that. The "code" will be encrypted, in a sequence of chars that can only be read and written by the server and the encrypted code contains all information about the player!

To make this possible we will need to:

• Define and add a encrypting lib
• Define what player info we will need to store on the encryption
• Create the encrypting method
• Send and store the hash on local storage, or simply hand it to the player
• Create the upload and loading player from encrypting method

Deri is an a*hole, she keeps blocking people.

A good way to handle it would be to implement an invisible, server side only, layer of "path blockers"

Turn every var into let or const to avoid scope related bugs

In some misterious cases the server doesn't return the Command.Login after a successful connection as show:

@andredarcie please help me investigate the heroku logs on the deploy (only you have access to that deploy)

When holding a key, players go too fast across the map.

Today, whenever a player moves, we broadcast the entire list of players on the server (forcing us to use JSON.stringfy) to each player (at broadcastPlayerMove on the clientHandler),
then we take this list of players and draw each one of them on the client (at updatePlayers on client.js).

If we were to send only the position of the player who actualy moved, and its Id, we would no longer need to stringfy the list of players, and much less data would traffic around.

Using a fully random method to pick color for players make them sometimes mixed with the background, or colors don't match with the overall game palette

Today we need to define the matrix of the collision layer for each room both on the client and the server (buildSolidLayer() on the server and getSolidLayerShape() on the client).

It would be very usefull if the collision layer matrix for each room was inside a JSON file that both client and server reads from.

Since gold is a different type of item (that does'nt actually takes space on the bag), we should allow for it to be picked even when the bag is full.

One nice feature before alpha release would be to show name and level of top 3 players

Create system to draw the map on the client based on a matrix sent from the server, something like

server sends and client have some matrix like:

[[0,0,2,0],
 [1,0,2,0],
 [0,0,2,0]]

where 0 is grass, 1 is tree and 2 is dirt, and the client renders something like:

and the server validates a move based on where the player tried to move (this applies only for non-walkable tiles)

Tasks:
Server

• Define how our map will look like and how each type of tile will be represented on the matrix (an object? just a number? Enum?)
  • Define a basic background map (a set of possible walkable tiles, like grass, dirt)
  • Define a basic non-walkable map (a set possible non-walkable tiles, like trees, water, walls)
    • Create methods to check collisions of players with objects on the non-walkable layer

Client

• Create objects for each type of tile (with a respective "draw" method. Remeber each tile is 8x8 pixels)
• Create new layer for collidibles
• Draw layers based on each respective matrix

I know we are not supposed to keep adding tasks to a milestone, but I jus't can't imagine the 1.0.0 without a quest system
Basic overview:

Before the launch of 1.0.0 we need a larger map with more enemies and items (maybe #46 should be done first to avoid messy code)

• monsters from level 1 to 25
• items from level 1 to 50
• map
  • 50/50 rooms done (I think it's good enough for a beta release, so i'm marking the checkbox)

We need a room system.

Today, the class "ClientHandler" on the server has a list of players, the players are the only movable entities on the game, in later stages there will be items and npcs.

This list of players must be moved from the ClientHandler to the abstract class "Room". Each Room will have a list of players (also the layers for collision and later the list of items, npcs, etc).

Our map will be just a matrix of rooms, we must think of how we will know if a player can switch a room by walking towards the wall.

Basic diagram of the overall idea:

Perhaps we need to use event listeners in order to work on all browsers

We need a death penalty, @FabriDamazio sugested all items were lost! Maybe xp loss too?

Towards our next milestone (1.0) we need to first implement a basic NPC system for "pacific" NPCs first. They obviously must be controlled by the server and they're info sent to all sockets to draw the NPC accordingly.

• Server logic
• Client logic