PureMourning

Update as we approach Open Alpha in a few days . . .   

General game information and a FAQ (including information about Open Alpha prizes) can be found here:
https://whispering-w...35c30ff9a3d4a13

Thanks for all of those who signed up so far -- things are still pretty early stages but am looking for to you playing and your feedback!

That's so awesome, Gaddy!

I'm excited to see Wayfarer, Stadius and the likes venturing in the world. 

By the way- I invited you to the Discord server. Would love to have you in there -- it's a great place to see much more real-time updates on development notes, progress, etc. Cheers!

Hi all,

I've been working on the project virtually every day the past ~2 weeks since the last update and wanted to share what I've been up to:

In keeping with "KISS" (Keep It Simple Stupid), I've decided to start with 4 races and 4 classes:

• Humans, Elves, Dwarves and Orcs
• Warriors, Mages, Clerics and Rogues
   

Want constant behind-the-scenes-updates?: There's almost daily dialog in the Nightmist Discord server's off-topic channel if you want to see more frequent updates and behind-the-scenes conversations (even the mighty Pandilex has been giving me tips on design decisions, etc.)

You can view recent progress pics here:  https://fallacious-s...623a6a6dc67472d

Key items you'll see in the link above:
 

• I've been working on adding the basic constructs of monsters, their attacking behavior (which is varied based on "aggressiveness" levels) and how they appear in the UX.  You can hover-over and get real time-data on mobs, like their health
   
• I've also been adding the inventory and equipment system, to include right-click context menus that allow you to inspect item

Screenshots for those who don't want to click links

Take care!

{ apologies for some of the screenshots being jacked in the OP -- stupid expiry on the images I exposed within my note-taking app -- but missing/new screenshots below!    }
 
But first . . . a quick insight into the last 2 days:
 
I've been in session management hell the past ~48 hours.  I noticed a fatal security flaw that allowed Player A to access Player B's character despite having authentication methods in place during login.
 
It only made sense early on to add a login screen that was equipped with the usuals:  allowing players to enter a username, password, and ensuring that those two things checked out.  At the time of my original post, I had already built the backend logic/respective database schema to facilitate this:  I even made sure to store user passwords as hashes in the database, and in turn, check the user's inputted hashed password against what is stored in database, etc.
 
Upon successful login, a player enters the main game after selecting a character.  In the original code, the initial bi-directional socket connection was established after running the login checks, which meant, that another player could connect to another player's character if that knew a.) the correct route / URL for hitting the main game and b.) another player's character ID -- which would be easy to brute-force if they didn't explicitly know it.
 
I made the realization that I wasn't doing any sort of session management!  In other words, I was not keeping track of session information on a per user basis as it pertains to active connections to the server.
 
I changed the database's users schema to start tracking session IDs at the point in which a player establishes a new connection.  I also wanted to do all of this in a way that aligned to two key requirements:
 

• Ensure only one character can be played at a time
• Mitigate Player A from accessing Player B's character

I believe I've solved for both of these (well at least in the context of realistic expectations considering I am running the game on a local server without SSL/TLS) and think I have made it out of session hell.  It was fascinating trying to understand how to create and track session data across the entire app, both backend and frontend.  The way the login sequence works entails the client technically making two distinct connection requests to the server so I had to come up with a creative/hacky way to make sure both requests were tied to a singular session ID.
 
I ended up using Flask's built-in server-side session storage capability to save/load the initial connection data and then re-construct it at the time the game loads, ensuring that the session ID is consistent despite there being two distinct connection events:

Some code examples for you fellow nerds:
 

const serializedSocket = serializeSocket(window.socket);sessionStorage.setItem('socket', JSON.stringify(serializedSocket));

The really interesting part is that I also ran into issues trying to retrieve the stored socket information into JSON format due to "circular" behavior with its member attributes.  So I created a helper function to serialize/de-serialize it:
 

const serializedSocket = JSON.parse(sessionStorage.getItem('socket')); 

// Check if the socket data exists and is connected
if (serializedSocket && serializedSocket.connected) {
    // If a connected socket exists, use it
    console.log("Connected socket exists.")
    socket = deserializeSocket(serializedSocket);
} else {
    // If no connected socket exists, create a new one
    console.log("Connected socket DOES NOT exist.")
    socket = io.connect('http://localhost:5000');
}

//Helper function:
// Deserialize the socket object
function deserializeSocket(serializedSocket) {
     // Create a new socket object and set its properties
     const socket = io.connect('http://localhost:5000');
     socket.on('connect', function(data) {
         socket.emit('send_sid', socket.id)     
     });
     if (serializedSocket) {
         socket.id = serializedSocket.id;
         socket.connected = serializedSocket.connected;
     }
     return socket; 
}

Missing screenshots from OP:
 

 After that basic client-server connection was handled, I started thinking about a simple grid system to handle the various areas that may exist.  I built a simple x,y grid system and the foundation of movement:

 
Then I wanted to cleanup the UX and make it more clean and starting building placeholders for things like character info, inventory, etc.

 
 In this final screenshot, you'll notice that the movement system is starting to evolve and its process has been the most profound for me so far.  For example, after building the basics of movement I realized, "Oh, crap. How do I handle telling Player A that Player B left the grid?"  This got me into a rabbit hole of understanding how webs sockets work, and in particular, how functionality within Flask's SocketIO library operates.  It took me a few hours to understand the concept of connected clients (players) being in a various "rooms", which represent how a player can receive communication.  I learned that each grid/room in the game needs to have its own socket "room" for sending messages to specific areas.

 

 
NEW Screenshots:
 
Spruced up login:

 
Cleaned up movement behavior and started adding basics of an inventory system:

 
 
Created an image for the initial "Town Square" and put it in the main game's background.  I also had a cool idea to change the game's background every time you go to a new area.  Something for the future, perhaps . . . 
 

 
So much to do!

The image links say "Access Denied" when I try to open them.

Ah, apologies, Stig!

I realized there was a permissions issue with how I was hosting/sharing the pics.  I've updated the original thread and the pics should be there!