[fitkoh]

Okay then it might be helpful to remind you that a full-blown registration system is only needed when one wants to identify the users/players in the long-term; hence the users table/list and the registration process plus the login/logout routines. If that's what you really want then yes, a database-backed app is warranted.

On the other hand, if you only want to keep track of the who's who, short-term (ie during the ongoing game server-side), then PHP sessions are what you're looking for instead. PHP session is the way PHP keeps track of the user-agent requests (ie the way it keeps state on a stateless protocol that's HTTP). They are generally ephemeral (destroyed when the browser exit) and you can destroy(/or regenerate them server-side) via your PHP script.

I'll leave it to you to see what fits best your use case. In case of an ephemeral state preservation (that shouldn't require a user, login, logout tables) you'll only need the session table implemented preferably with Redis [don't use a classic database server in Games, inadequate for latency] and a session script.

The way I would have implemented it is by using JavaScript in both the front-end (your actual JavaScript-based game) and in the back-end using Node.js and Redis to store my users session data.

If Node.js and Redis are new software for you, I'd highly recommend you to start studying them in-depth. They are the keys for a successful HTML5-based Game App.

Good luck!

I have planned to have members and their records maintained, so a registration system has been a requirement since the inception.

I have spent some time researching these technologies, and it's quite intriguing.

The Redis server reminds me a lot of puppy linux: the ultra fast linux distro that runs entirely in the ram. It runs at spooky fast speeds: like a spider, it moves so quickly you'd swear things happen before you click.

The capabilities of Redis to transmit data are incredible (if documentation is to be believed), but given what I've seen disc-less operating systems do, I can believe it.

I actually installed nodejs on my backup server meaning to tinker with it about a month ago, but haven't made any time yet, and I'm still on the fence if nodejs is the best solution in my circumstance for interacting with redis. More reading is required.

I do like the idea of running a dual setup, with the persistent database to hold records, stats, trophies, items, the like, and a redis server handle more fluid data about character state: vector and position. But I think I'm a long ways off from that one: sql is still new to me and I think I'd benefit in the long run by acquiring more familiarity with sql before learning redis.