Where are we now?

Ok, this whole Idea leads me to where are we at right now. First of lets start with the whole authentication idea behind the system. Originally the combat script that I had handed out to me used a forum registration that bridged the 2 systems together. This failed at some points since sometimes the login lost its original status and so on. Also, it lead to confusion on what was what and what did who and where are we at right now?! (yeah, I am gonna make this sentense that complex since it felt that exact way).

Anyways, after a couple of hours of digging I found that the whole registration code/ login code was right for the taking. The only thing I really needed was the function that did all the work for me and plug it in.

$user->session_begin(); $auth->acl($user->data); $user->setup();

This is the basic idea on how the user connection was made from phpbb3 (yeah, we'r talking phpbb3 here).

$result = $auth->login($username, $password, $autologin, $viewonline, $admin);

This is the basic login method

$user->session_kill(); $user->session_begin();

Thats the logout method. And everything else is nicely tied up using the user object of phpbb3. No fuzz there, easy come easy go (even it took me a couple of hours to find it and how to implement it all... but thats just a nice side story). So at this point I can ditch the whole idea on keeping track of my user, since I am basically 'borrowing' the session state of phpbb3. This leads into phpbb3 being the leading. Thus one option that remains to be done here... Inserts!

// just checking is this works.. $user_row = array( 'username' => $_POST["pname"], 'user_password' => phpbb_hash($_POST["password"]), 'user_email' => $_POST["pemail"], 'group_id' => 2, 'user_timezone' => $user->data['tz'], 'user_dst' => $is_dst, 'user_lang' => $user->data['lang'], 'user_type' => 0, 'user_actkey' => $user_actkey, 'user_ip' => $user->data['ip'], 'user_regdate' => time(), 'user_inactive_reason' => 0, 'user_inactive_time' => 0, 'user_new' => 1, ); user_add($user_row,false);

And thats the basic insert script needed. This adds a user inside the forumboard with a default registration status and so on. Nothing fancy. Does this allow spammers to appear? Yes, sure... it can... However, the forum is not here remember? It is part of the system, however spammers wouldn't know that they have to register here and then use a different directory / url to post there. This is where spammers usually get lost. Since they are fixed on that directory/url they are in.

So to prevent the whole spamming fiasco, the idea is to have 2 different directories where one is the ladder login and the other is the forum login. This is a similar concept I have implemented on my own community and it works like a charm.

So basically this leads with 2 different systems that are bridged together and phpbb3 becomes leading in this case. And the irony I find with systems like joomla or WP to phpbb3 is that they make it way too complex... this is where I think simplicity, and its just written down on this blog ;)

Connecting the 2 together

Now there is one part that remains vital here. The user info thats stored in the forum does not overlap with the ladder script. That is one thing. Since the forum uses different fields (ok, they can be customized). However the ladder uses its own set of fields to define the user. To connect the 2 together the systems holds the userId inside the ladder script in combination with its own unique userid. So, you basically have 2 idea to fact check if this user is really "you!". This additional checksum is needed to prevent hacking and strange things to happen. Since the system constantly checks if the 2 really match. If not, then something really went wrong and we have to assume this is either a hacking attempt or we lost some piece of information. So we can't continue. Simple.

However, inside the ladder script itself, the internal userid becomes leading and that forum id is only being used to check if you = you. Other then that its the internal userid that does all the work for us. Since it is that userid that connects the player to the team, tournaments, games and so. And also the user database of the forum might be having a whole different userid sequence. So we cannot rely on just the user id of the forum alone. I could spend ages about talking bridges here and why, why not etc. I am not going to do this. I am just saying, it has 2 userids... One for external, one for internal.

On a side note, if this needs to be like bridged into ... whatever. The only thing I need is to bypass all these login/logout/user inserts and replace them with another one. Thus, it has to potential to bridge with some other system. However, that is not the initial intention here. But I thought I would mention it anyways. Why?! I don't know... I like to think out loud.

Teams

This leads me to the next segment. Teams. Teams is defined by the players. So, at some point you might say that the player and teams have to be connected at some point. This is where the original ladder script starts to blur at some point.

The original combat script did have some parts that did allow more then one team to be created at some point, but seriously... it did not really work out. I had been thinking about why it didn't work, and that was mostly due to the interface itself.

When I think of an interface, I think of lists... create... edit... and delete. These are the primary functions which always need to be there. No matter what.

So here is a basic concept picute on how a team management page would look like. It has most of the important features on this page to manage your team.

Sure, there are maybe some points missing or what ever (but hey, this is early development right?). But most of the essential parts are there.

You have always the way to make a new team.

You can select all your teams and manage your players

You can see which teams you are in

And if you are the captain (recruiter) of the team you can see who is on your recruitment list. With that says, one thing that might be missing is the tournament / schedule etc. This is the next step... Like the title says: where are we now? This is where we are at.

The setup has the ability to add players, create recruitments, accept/decline them etc. During the line I will probably have to update pages while progress continues. But this is also where I have thought one step further rather then hacking everything on a single page.

Most of the lists, sections that are created are blocks. Ok, there exceptions... but most of them are. You have a block view player, a block view team and so on. Don't see these blocks as "phpnuke blocks". They are just defined as a piece of logic that spits out the complete list as a whole.

The reason why I think of it this way is that I am able to plug stuff in / out while i progress over time. There have been moments in the early stages that I didn't do it this way, but thats a matter of going through the old code snippets and move them in their own block section. But other then that... it works like a charm.

Thats for instance the same thing with requesting information from the database for instance. Getting a player information is one single function:

// Now i am getting tired of doing this all the time.
if (isset($sUsername))
{
$sql = "select * from cs_player where pname = '$sUsername'";
$results = sql_select($sql);
$csp = sql_array($results);
return intval($csp['pid']);
} else {
return 0; // your just another looser my friend!
}

This for instance grabs a player by name ( I am not showing the complete code snippet since I like to prevent mySql injections if you don't mind). Or if you want to have the complete team information, why not?

$tid=intval($tid);
// Now i am getting tired of doing this all the time.
if (isset($tid))
{
$sql = "select * from cs_team where tid = '$tid'";
$results = sql_select($sql);
return sql_array($results);
} else {
return ""; // your just another looser my friend!
}

This is what makes the system pretty 'simple'. It is more less feeding Id's or Names to a function and get everything back. You might think to yourself "but thats how everyone does it?"... My answer would be: Nope...

So the main building blocks I have so far is the player, team, recruitment, the connection from player and teams, the ranks, the player role in the team.

So... Where are we now? We are going to make the whole game/rounds mechanic! This is where the real fun begins!