October 23rd, 2008, 05:14 PM
My server at GoDaddy is a Windows box due to the side jobs I was doing at the time. It still supports MySQL, so that should not be a problem, right? If you think we need a Unix/Linux OS, I can see if they are selling sub-domains that I can tap into (they talked about this last time I checked, but had not done so yet).
From your last post, it sounds like there is not a GUI or web interface for MySQL. Either way, I will play with this later tonight.
Since you have stepped up to the plate to work on this with me, would you like me to send you a copy of the game? I have several copies.
October 23rd, 2008, 05:19 PM
I am sure you will have access to MySQL from the Windows box or from the account manager. I'll do a little research online to see if I can find anything about it.
Originally Posted by ourfarm
Sure, if you don't mind. It will help to have something to reference while working on the program, since currently I don't really have a clear idea for how the game works.
Originally Posted by ourfarm
Last edited by paulscode; October 23rd, 2008 at 05:24 PM.
October 23rd, 2008, 05:24 PM
I found the following, which might indicate that you can edit your database from your GoDaddy Account Manager:
Worst case scenereo, you could always set up your database programatically (with a Java application or a Perl script).
Last edited by paulscode; October 23rd, 2008 at 05:27 PM.
October 23rd, 2008, 05:26 PM
I went with MySQL 5.0 and DSN.
October 23rd, 2008, 05:40 PM
October 23rd, 2008, 06:09 PM
OK - bare db is there.
Do you want me to start with character tables or equipment (weapons) tables? Or do we need to start with a login/security "thing" first?
October 23rd, 2008, 06:27 PM
I have just built the first table "characters".
CREATE TABLE `characters` (
`cID` INT NOT NULL COMMENT 'Dumb key',
`cName` VARCHAR( 50 ) NOT NULL COMMENT 'Character name',
`cType` VARCHAR( 3 ) NOT NULL COMMENT 'PC or NPC',
`cInt` INT NOT NULL COMMENT 'Intelligence',
`cSen` INT NOT NULL COMMENT 'Sensibility',
`cAgl` INT NOT NULL COMMENT 'Agility',
`cCor` INT NOT NULL COMMENT 'Coordination',
`cCon` INT NOT NULL COMMENT 'Constitution',
`cStr` INT NOT NULL COMMENT 'Strength',
`cPer` INT NOT NULL COMMENT 'Personality',
`cApp` INT NOT NULL COMMENT 'Appearance',
`cBra` INT NOT NULL COMMENT 'Bravado',
`cWil` INT NOT NULL COMMENT 'Willpower',
`cHeight` INT NOT NULL COMMENT 'Height in cm',
`cWeight` INT NOT NULL COMMENT 'Weight in Kg',
`cSex` CHAR( 1 ) NOT NULL DEFAULT 'M' COMMENT 'M or F',
PRIMARY KEY ( `cID` )
) ENGINE = MYISAM COMMENT = 'Characters (PCs & NPCs)';
I swear their tool is the same one I used to use from SourceForge!
Since we are going to have the db on-line, I will likely need to add some type of field to associate each record with a specific user/GM, but you get the idea. There are a bunch of virtual fields (calculations based on these and other values), but this should be a good start. Let me know how else I can help.
October 23rd, 2008, 08:01 PM
Awesome, good to see the database stuff coming along.
I have another question for you. Is there going to be a main "screen" in this program (sort of a "parent window" if you like)? If there is not, then we will probably want to make this program an application launched through webstart. If there is a main parent window, then we could go with either a webstart application or an applet with that main parent window inside the applet's frame. The code for either method will be virtually the same, so one way is not more difficult to program than the other. It is just a matter of what will work better for this application. Since you know the game better than I do, I leave the decision up to you.
As for the security stuff, you could create a table that will hold username and password information for each GM (and any other information you want to collect) plus a GM id (an AUTO_INCREMENT field). That way, adding a GM id field to the other tables can be used to link a single GM to a particular row of data.
Also, I've written several different CGI scripts for user sign-up pages, so we could pretty much plug-and-play from those to create a webpage for new GM's to sign up and create a username and password.
Oh, one more question. How secure should we make the database information? One thought I had would be to create our own encryption method that would be used to encrypt the password before inserting it into the database. That way, if some sneaky GM were to read someone else's password from the database, he wouldn't know what to do with it. When a user logs in, it would take what he typed, encrypt it, and compare it to what was in the database.
Let me know if you have any other security concerns or suggestions.
Last edited by paulscode; October 23rd, 2008 at 08:11 PM.
October 23rd, 2008, 08:46 PM
I guess we need a GM table for logging in and "owning" data. A dumb key, login, password, name, E-mail, etc. Then each character would be tied to that GM. Global tables (equipment, skills, etc) would be viewable by all, and each character would have a sub-table linking the character to their personal gear, skill levels, etc.
The data will live on my web site. Are you seeing this tool as being web based or run from each user's PC?
Most of the tables will have a seq/dumb key.
As far as the data-entry screen/pages/frames, I sort of see this as having a main/parent screen. From it, you could have a menu to go to inquire about global stuff (equipment, skill descriptions, etc), another area to maintain characters (PCs and NPCs), their skills and levels, their equipment, etc. All this stuff would need to be entered before the "fun" can start. Finally, there would be a page that has the combat calculator. An of course, a credits page!
Re-using CGI stuff is fine with me. Re-use code wherever possible! Do it right once and you don't have to go back later (my mantra at work).
Inventing our own encryption is fine with me. Sounds like its right up your ally. GMs should not be able to get to other GM stuff, but...
Should the login/GM table be the first thing to work on? I assume I need to send you the db name/login/pw so you/GMs can log into the db?
October 23rd, 2008, 09:12 PM
I tweaked the characters table a little (it's been a while since I used MySQL). cID is now unsigned, auto_increment & primary key.
All the other INT rows are now tinyint(3)s, unsigned.
October 24th, 2008, 06:48 AM
You can email the information to me if you like. Please note, though: this database login information will be hard-wired into the program's source code, so there is no need to give that information to GMs (nobody should ever see the database login information - makes things more secure that way).
Originally Posted by ourfarm
Since there is a main window, we can go either applet or application, whichever you think sounds good. I was thinking for that main window, there could be a row of buttons for the various popups, and a nice background image. It would look good in either an applet frame or in an application main window, in my opinion, so I have no preference whether to have the program launch in an applet or in an application downloaded to the user's computer. What is your preference?
October 24th, 2008, 11:08 AM
I completely understand about the connection stuff being hard-coded (as long as I have a copy of the source in case I ever need to change it).
I am not seeing the difference between how it would work between the applet or application. Do you have an existing simple example of the two formats so I could see the difference? I was thinking of just an application, but this is my ignorance. We need to have some way for people to be approved as users/GMs (I don't want thousands of people bumbling about the db). Bottom line: I want it easy to use by everyone, but secure from hackers.
Thoughts or concerns?
I will work on a GM table this evening so we can begin logging in.
October 24th, 2008, 12:38 PM
Sure, I will throw together a couple of examples to give you an idea of the difference between what an Applet vs and Application would look like. I'll also send you a login-screen example.
Yes, you are right about security, that has got to be something to constantly keep in mind as we develop this project. The biggest way to make the database secure is to hard-code the login information as I mentioned earlier. The account creation and loggin scripts will also contain the hard-coded database login information, so I will take a close look at that to make sure it is secure (For example, we don't want it to be possible for a hacker to simply download the main script and open it with notepad to get the database login information). I may need to end up translating these to Java instead of Perl, so they can be compiled into JARs were no prying eyes can read the database information. Additionally, giving each GM a userid and password, and encrypting passwords as we mentioned earlier will further increase security.
As for making the program easy, putting it online as we are planning is the best way to do that, and a simple login screen will give the program a good balance of both easy access and security.
October 24th, 2008, 09:15 PM
OK - it sounds like this will be 100% on-line "stuff" - not a problem.
Originally, I was thinking the GM Id should be a seq key, but then I got to wondering if that would be too easy to hack. Should it be some "other" type of id, or will a simple seq key be buried deep enough in the Java to avoid this concern. Do we need any "GOD" level security for you and me?
I will try to add a few more tables, including the GM table
October 24th, 2008, 09:45 PM
As long as we keep the database login information secure, it won't matter if the GM ID is seq or random, since the only way to connect to the database will be through our program, which will require the GM to enter his username and password. Any hacker who can figure out how to bypass the program to connect to the database, would be able to just read the GM table anyway, so making the IDs random wouldn't really be any more secure anyway.
Originally Posted by ourfarm