Overview

The goal of this proposal is to improve the overall MMO experience to have a clean field to add new features. Before adding anything new, we want make sure hustlers can log correctly with their gear, and have a smooth experience in both map and social features.

1. Optimize and Smooth the Overall Experience

The frame rate drops when moving from a district to another because the game instantiate too much elements at once. We want to improve the experience by testing several ideas we have in mind.

1A. Initial Loading Time

[local : no problem | about 7s to load]

[online : unknown]

Notes

• The initial loading doesn’t seem to have a code problem as it is working without errors and relatively fast locally.
• Compress the textures to the maximum compression without visual quality loss
• Make sure the format of the textures is adapted to a web browser game
• Calculate the full weight of the loaded textures and optimize it if possible
• Ensure the loading only loads the tile the player is on
• Loading manual unit testing to identify either problems or unoptimized behaviours
• Make smaller tiles [LDTK]
• Online test sessions

1B. Tilemap Loading Time

[local : not smooth | breaks the dynamism]

Tasks

[online : same behaviour]

Notes

• When a game/scene is using several tiles/chunks that are active or not, based on the player’s position, the usual method to avoid the loadings from blocking the player experience and progression is to use multi-threading. This process allows us through a concurrent execution to load or unload other tiles/chunks with different threads while the player and rendering are still active on the main thread.
• Some games don’t use threads at all and load all the assets of the scene but this solution is not conceivable due to the high number of textures the MMO needs.
• Javascript is a single thread language but has “close to thread” behaviour mechanisms such as “async/await” keywords. This makes asynchronous code possible but it is not true multi-threading. There are several libraries though that can be used to have a thread-like implementation like “thread.js”.

Tasks

• Divide the tiles in 9 proportional areas [8 around, 1 at the center] that will be called “sub-tiles” and add each of their center positions to a bidimensionnal array :

"[tiles] - [sub-tiles] -> sub-tiles center pos " " - [tile center pos]"

• Implement basic AABB collision detection to detect in which sub-tile the player’s collider is in
• Implement a thread system with the most adapted method in the tile loading function so the loading happens on another thread
• Based on the player sub-tile progress, call the loading of the 3 closest tiles [either with 1 or 3 threads -> need to run some tests to choose the less expensive way]
• Check up and fix data races possible problems
• Verify the memory management to avoid leaks and minimize fragmentation
• Testing sessions
• Fix problems
• Online testing sessions

1C. General Optimization

Notes:

• A few more things could improve the game performances like instancing, which allows us to reduce the number of draw calls, frustum culling which will render only the visible parts on screen, improve the shaders if possible and double check the code in general and simplify it if it is possible.
• The use of a tool to calculate the number of operations from a part of code would help a lot.

Estimates & Cost

Acceptance

DAO members should verify that…

• On a desktop computer with a decent internet connection, the start/initial loading is improved (compare with the previous loading)
• On a desktop computer with a decent internet connection, the players can walk around the map without noticing the tiles loading

2. Hustlers Gear and Inventory Fix Proposal

Some people cannot log with their full gear or cannot choose their hustlers when they have several. We want to dig the way sprite sheet are linked to the server to fix it.

Because this work is unknown at the moment, we should investigate what needs to be done and create a separate proposal for it.

Estimates

Acceptance

DAO members should verify they can

• Understand the work to be completed to fix Hustlers and Gear showing up in their game inventory
• Understand the costs associated with making these fixes so they can vote with all the information necessary

3. MMO Controls [UI - UX]

Player controls and introduction are hidden when the game loads. Work needs to be done in order to make those controls discoverable, and match the polish of the rest of the dopewars.gg website. Once learned, player controls seem quite straight forward but a pop up for new players with a recap of the controls and a small UI widget displaying when pressing a key could make it much clearer.

Estimates

Acceptance

DAO members should verify that…

• The players can join the game and learn the controls the first time on a desktop computer

4. Visual Problems

The map still has several visuals issues, like sorting layers not working correctly when between 2 objects. To make sure it won’t happen anymore, we want to replace props with game objects, allowing us to use a better collision system.

4A. Tilemap Layers Fixes

[local : visual problem]

[online : visual problem]

Notes:

• HP has an idea of what’s going on with the layers messing around. From what I understood, there are 2 problems:
  • Some “props” are embedded in the same objects which makes it impossible in certain cases to have a prop “in front” and one “behind”.
  • The level design tool used for the map need a lot of layers to put everything together. We need to merge the layers that belong to the same depth level, to drastically reduce the amount of loaded tiles

4B. Normal Map Fixes

[local : visual problem]

[online : visual problem]

Estimates

Acceptance

Dao members should verify they can…

• Walk around the game without noticing the previously specified layer problem
• Street lights normal should not be seen

5. Stress Test Post Fixes - 50 to 200 people

We did a first stress test back the end of 2021 to test the performance of the game. With the new fixes we are bringing, we will do other stress tests to check the critical mass for the server and the performances

TESTS AND INVESTIGATION

[local : a few players simulated seems to work without problems]

[online : need to test]

Estimates

Acceptance

DAO members should verify they can

• Have a smooth experience with 50 people on the server
• Know the limit of the number of players possible at the same time
• Know what are the steps to achieve to have X people at the same time

6. Chat Features Testing and Polishing

The ability for the chat to follow in large scale isn’t proved and we’ll need to test the chat in a larger scale.

TESTS AND INVESTIGATION

[local : the chat works well with a few players simulated]

[online : need to test]

Estimates

Acceptance

DAO members should verify they can

• Chat with other players without problems

7. System Requirements

Create a system requirements document so that players understand the minimum level computer needed to play the DOPE MMO [need the cooperation of many testers] .

Estimates

Acceptance

DAO members should verify they can

• Understand what machine the player needs to have to play the game

8. LDTK Map Rework (HPMNK)

Estimates

Acceptance

DAO members should verify

• Most objects have been formatted to game objects and that you can access them individually through code

9. Unit Test the Game Backend (bort)

To minimize the risk of features breaking after code changes and the time spent on manual testing, most of the critical code in the backend should be unit-tested. Before we can write any tests we need to refactor the backend in such a way, that individual functionality can be tested, which can be achieved by reducing the tight coupling. We do not want all unit tests breaking, just because of a small change which is not even related to them…

Acceptance

DAO members should verify

• We have ~85% Code Coverage on the game backend

Team

Thomas (@johntelman7x7) - Game Developer

HPMNK (@HPMNK) - Game Artist - Game QA

Faces (@facesofeth) - Visual designer / frontend dev

Bort (@bort) - Backend Developer / DevOps Engineer

Budget

The estimated time for the whole work can go up to a couple months.

Total Budget : $24,980 to be paid in OP