Unnamed Game


Unnamed Game
the progress of an unnamed game!

Hi guys, So I don't have the know how and such on creating a blog so instead I'll utilize a thread to share with you all my creations and progress.

I'm currently busy with the menu and quite proud on the interactive GUI (Buttons, RadioButtons, Textboxes and HREF links).


And yeah that's about it for now (off to work) :)


Made a flow chart for Phase 1 at work yesterday during the course of the day, got quite busy though.

Think I'll finish it today and share it here but I did print it and complete a few steps such as the server<>client handshake.

* Server stores socket IDs and IPs in a 2D array since a DS_List seems completely silly to me
*Client enters username and password, client side prevents the following [no username below 3 characters or above 20 characters, no password below 6 characters or above 20 characters, no blank username/password]
*Client sends username/password to server, server does the exact same checks but needs to check to see if the username already exists, which is where I stopped.

So the next thing I think is to figure out where I'll store the player username and password.. I'm thinking of creating an ini file, but here's the catch, there aren't any registered users yet, so I sort of need to predict what I will do..

Can I even search a directory for an ini file name ?
This is a difficult one because I don't want too many links back and forth. I really feel that I need higher dimensions though,
so maybe what I'll do is I'll create ini files with the username, then link that username to the open 2D array that stores the Socket ID and IP as [x,2] = usn,
and then within that ini file for the player I'll store precious relative to players state variables.. like last x/y pos, character appearance, and then from there have a link to other INI files which will have the players inventory, their skills, their dough, etc.

Xer0botXer0.ini - Stores some variables as well as reference links to other ini files.

and so forth.

But those reference links may then not be necessary considering how easy it is to guess what the other ini file names will be!

Now if someone is following this, is there a better way at handling such a variety of information in an organized manner per user ?

Well I'm off to work.


So I've made some progress with the registration process:

  • the client chooses a username/password combination
  • the server verifies whether or not the username already exists
  • the server passes some filters to ensure that the username and password are in the correct format
  • the user receives an ok from server if credentials check out
  • server creates the relevant .txt file for the player
  • the player also has remember_usn/pass RBs which stores their state in a settings.txt file

But I've decided to move over to .ini files, so tonight I may move those over to .ini files since they seem to be able to do what I need of them, they're also easier to use and require less coding.
Golemized ini setup.png
Golemized Menu Template 2.jpg
I've also started some plans which can be seen above regarding the registration process, which already puts the user into creating his character, choosing some skills and so on.
Then below is a document which is more of a flow chart with relevant information included as I wanted to understand the relation between arrays, and also to visualize what information may be relevant.
Last edited:


So just a quick update:

I'm rewriting the code for the network communication, atm I was working on the registration process but it felt confusing.
So I spent more time figuring out how to make that work in a systematic manner.

My plan thus far is for one to move over to ini files since .txt files felt unnecessary and required a bit of extra work,
Each message type or what I call 'primary_Key' the server receives will be handled in a switch statement, where each case will be dealt by it's own script!

I feel that using scripts keeps the amount of code within one file to a minimal, which can end up feeling really confusing.
The idea is that each script needs to handle its unique situation on its own.

aand that's about it for now.
Next update is hopefully once I've made it as far as the earlier posts in the rewrite, then I'll see from there.