12th grade, 2009.

My friends and I got bored in the 3 months between school and college. We spent a lot of time playing Counter Strike (multiplayer first person shooter game). Since we couldn’t always meet at someone’s house to play together, we had to resort to playing online. The problem was that we could never play on common server since the closest public server was too far from Saudi Arabia (hence, the latency was too high to play). This meant that one of us had to host a game server locally and the rest of us had to connect to the hoster.

The problem with this method was synchronization. Since we all were on internet connections that didn’t have dedicated IP addresses, the host had to share his IP addresses manually before each game. This often involved calling each and everyone one up by phone. (we honestly just forgot about group chat).

I thought I could come up with a program to facilitate sharing of public IP addresses and game hosting statuses.

Please note that this program is defunct as of this day. This is because my account on 110mb expired after years of not using it. Also, please excuse the “amateurish font, and oddly scaled program”. This program was developed in 2009, on a 32 -bit machine having a resolution of 1024 x 786. This means most the spacing and other alignments in the program would be out of place. Also, since website is now defunct, I can’t login to demonstrate the program’s functionality, hence the errors in the log.  

Program design:

Decentralization:

Since the program had to work in a decentralized manner, I figured out that all the clients had to connect to a commonly reachable “address”. Since I couldn’t set up a machine with a dedicated IP address, I resorted to using a free web hosting service to host a series of text files by which I believed I achieve the required objective.

Public IP address detection:

I also figured out that finding each user’s public IP address could be achieved by using the same free web hosting service. All I had to do was place a PHP file on the website. This PHP file, when navigated to, would display the visitor’s public IP address in one line. The client would programmatically access this file to find out it’s public IP address.

User login:

Each user had to “registered” by the site administrator.  All he had to do was to create a text file titled as the username. The content of this text file was the encrypted password. Any client attempting to “log-in” would query by FTP for the existence of this username. If it existed, it would compare the user’s password with the decrypted contents of the text file on the site. A successful match meant an authentic user.

User presence:

I implemented a feature would let users who are logged in to find out how many other players were online, playing or waiting for a game. This was done by simply writing a text file onto a “status” folder on the site with the username and his status the moment he logs in. The client would then just have to download all the text files in that particular status folder to view the statuses (“Ready”, “In-Game”, “Hosting” etc) of other users who are logged in. These status text files are deleted when the user requests to log off.  This implementation had an unavoidable set back, users who do not log out or who get accidentally disconnected would leave a false “online” status to others. (Though, looking back on it now, I realize I could have fixed this issue. I could have made the clients to repeatedly (say, every 5 minutes) update their statuses along with an added attribute called “last updated”. Other clients could check whether the last seen of a user’s status is greater than 5 minutes. If this is the case, the client could interpret this as a false online presence.

Game status:

I came to know that the game status of a game running on host server could be queried by simply connecting to a dedicated status indicator socket on the host server. I implemented this added feature to provide details about on going games to users without having to actually connect to the game.