Creating and Maintaining Player Account Information
by Ben Siders · in Torque Game Engine · 02/12/2005 (8:45 pm) · 3 replies
As with every question, I'm sure this has been asked (and answered) a dozen times. I'm gonna make a baker's dozen.
For one of my early "learning" projects, I want to build a custom data structure (class) in the C++ code and then hook up to it in TorqueScript. Or do I?
Here's what I want to do.
(1) Modify the GUI such that the player must "log into" the game by supplying a username and password
(2) The username/password will be validated against an internal list (details on taht aren't really important her)
(3) If validation fails, they can't play
Now, to GET their username/password, they need to create an Account. Simple enough, they click the "NEWBIE" button and a panel comes up that says to pick a Username/Password. They fill it in and click "Create Account".
Here's where my question is. First, regardless of how I want to keep permanent storage of this information, I'm unclear on:
(1) How to get the data out of the GUI control fields (e.g., how do I know what their username/password was that they enter)
In the interest of demonstrating that I'm not just asking for my hand to be held here, I've read through scripting docs and these forums, and my guess is that I need to hook up a callback to the control (written in TorqueScript) that will pull that information out for me. Am I on the right track?
(2) Is it necessary (or beneficial) to create a C++ account object to manage the read/write/validation portion of this, and interface to it through TorqueScript? My instinct is to hide the implementation in C++ and just give my TorqueScript a simple API to work with in the interface.
Any input on this would be appreciated. The basic things I need to be able to do are:
(1) Create new accounts (that includes making sure passwords are long enough, usernames aren't duplicated, and other sanity checking)
(2) Save accounts to whatever permanent storage I decide to use
(3) Read accounts from that storage
(4) Validate that a login attempt contains valid account information
For one of my early "learning" projects, I want to build a custom data structure (class) in the C++ code and then hook up to it in TorqueScript. Or do I?
Here's what I want to do.
(1) Modify the GUI such that the player must "log into" the game by supplying a username and password
(2) The username/password will be validated against an internal list (details on taht aren't really important her)
(3) If validation fails, they can't play
Now, to GET their username/password, they need to create an Account. Simple enough, they click the "NEWBIE" button and a panel comes up that says to pick a Username/Password. They fill it in and click "Create Account".
Here's where my question is. First, regardless of how I want to keep permanent storage of this information, I'm unclear on:
(1) How to get the data out of the GUI control fields (e.g., how do I know what their username/password was that they enter)
In the interest of demonstrating that I'm not just asking for my hand to be held here, I've read through scripting docs and these forums, and my guess is that I need to hook up a callback to the control (written in TorqueScript) that will pull that information out for me. Am I on the right track?
(2) Is it necessary (or beneficial) to create a C++ account object to manage the read/write/validation portion of this, and interface to it through TorqueScript? My instinct is to hide the implementation in C++ and just give my TorqueScript a simple API to work with in the interface.
Any input on this would be appreciated. The basic things I need to be able to do are:
(1) Create new accounts (that includes making sure passwords are long enough, usernames aren't duplicated, and other sanity checking)
(2) Save accounts to whatever permanent storage I decide to use
(3) Read accounts from that storage
(4) Validate that a login attempt contains valid account information
About the author
#2
2) & 3) What Ben said--it all depends on your implementation choices. There is a pretty good MySQL resource here on the boards.
4) Ahh, validation! There are a lot of things to consider on this one, which will ultimately drive how you implement:
--will the account validation/login process happen with the same game server as the rest of the game traffic? If so, then you can probably get away with the same "game connection" to both authenticate the login, and continue game play. If not, then you'll need to keep in mind that you'll need some way to get the "authentication token" (proof of an authenticated login) back to the appropriate game server.
--will the login happen across the same connection as the rest of the game play? If so, then you can most likely simply add in the password field to connectArgs (setConnectArgs() on the client side, make sure you also decode them server side when the connection is negotiated), and use the normal connect().
However, sending authentication information across a UDP connection is probably not the best way to go. Our project utilized a separate TCP/IP connection, as a placeholder for an SSH/https (we haven't decided which yet for final implementation), and then tied the two connections together server side by assigning an authentication token to the %client variable, and providing the player's executable client side a session authentication token that allows it to negotiate the UDP connection with the authentication already complete, and the server validates the session auth token with it's version to make sure you really are the right player.
--The entire connection sequence is one of the more complicated processes in the engine that is exposed to script in a large amount. Tracing through the connection sequence would probably give you quite a headache, but at the end of figuring out how everything works exactly, implementation of this will probably be a breeze. Until you do fully understand the connection sequence however, you are going to get really frustrated as well trying to get things to work.
02/13/2005 (9:51 am)
1) Actually, client side, you can just tie the input field directly to a script variable. Whatever they type in will be the value of the variable. Use a GuiTextEditControl for this.2) & 3) What Ben said--it all depends on your implementation choices. There is a pretty good MySQL resource here on the boards.
4) Ahh, validation! There are a lot of things to consider on this one, which will ultimately drive how you implement:
--will the account validation/login process happen with the same game server as the rest of the game traffic? If so, then you can probably get away with the same "game connection" to both authenticate the login, and continue game play. If not, then you'll need to keep in mind that you'll need some way to get the "authentication token" (proof of an authenticated login) back to the appropriate game server.
--will the login happen across the same connection as the rest of the game play? If so, then you can most likely simply add in the password field to connectArgs (setConnectArgs() on the client side, make sure you also decode them server side when the connection is negotiated), and use the normal connect().
However, sending authentication information across a UDP connection is probably not the best way to go. Our project utilized a separate TCP/IP connection, as a placeholder for an SSH/https (we haven't decided which yet for final implementation), and then tied the two connections together server side by assigning an authentication token to the %client variable, and providing the player's executable client side a session authentication token that allows it to negotiate the UDP connection with the authentication already complete, and the server validates the session auth token with it's version to make sure you really are the right player.
--The entire connection sequence is one of the more complicated processes in the engine that is exposed to script in a large amount. Tracing through the connection sequence would probably give you quite a headache, but at the end of figuring out how everything works exactly, implementation of this will probably be a breeze. Until you do fully understand the connection sequence however, you are going to get really frustrated as well trying to get things to work.
#3
Is there any documentation on the connection sequence?
02/13/2005 (12:04 pm)
Validation would (in the end) be done by an independent service. I have a fancy-pants idea of implementing a validation service that stands alone from the game server. I haven't dug into the code yet (obviously), but I had thought to implement digest authentication, similar to how it's done in HTTPS. If you're not sure whether to support SSL/HTTPS, I've written a digest auth module in Perl and it was pretty easy. Search the web for the RFC, it's all spelled out pretty well. The nice part is that you can test whether or not it's working properly with your browser. I grabbed Mozilla/Firefox to get a look at their implementation to clear up some ambiguities in the RFC. Don't use IE to test, they don't do it right (naturally).Is there any documentation on the connection sequence?
Associate Kyle Carter
2. Whatever works best for you! :)
I'd suggest breaking it down into steps (mysql backend, frontend, tying them together, etc.). If I tried answering your questions in any depth I'd end up writing you a tutorial on the topic, which is way way more work then I want to do at the moment. :)