zaterdag 5 februari 2011

Setting up the ladder table

So... Ladder... What do we need as info. This is a part of information I have been strugling with for quite a few days

now. Since basically it comes to this:

The results of matches defines the way the ladder changes. The ladder itself is pretty much "stupid" as information

wise. Since the only thing we really need is:

- Game
- Position
- Team
- Team Streak (how many wins in a row)
- Team Wins
- Team Losses
- Status (defending, attacking, protection,vulnerable)

This could be just be defined inside a single table with the fields as described. However, here comes the tricky part.

- Position is defined by the wins/losses and who got challenged from the matches
- Teamstreak is defined by the wins of the latest matches of the team
- Team wins gets defined by the wins of the matches
- Team losses gets defined by the losses of the matches
- Status gets defined by the last pending match AND the previous match

So at some point it is fair to say that the ladder gets updated on different points:
- When a match gets accepted (status change)
- When a match gets declined by both teams (status change)
- When a match is finished (Team Streak/ Wins / Losses updates / Position)

This above section needs to be done through one function (it needs to be centralized), since in that way I am able to rebuild the complete ladder when needed

zaterdag 29 januari 2011

Shitting up the ladder

Ehm... setting up the ladder I mean. Basically, the ladder is what makes the system tick at some point. Its an overal table that shows the progress over whats happening during the complete season.

Overal, it comes down to positions inside the ladder. Since this drives the ladder. And as far as I discussed it previously it comes down to that a team inside the ladder has a few states:

- position (rank)
- invulnerable
- protected

Position is the place where the team is at inside the complete ladder. This position will eventually determine which teams he can challenge. In basic terms it comes down to that you can only challenge the teams above you, not below you.

When a challenge has occured, this leads to a match (which is defined by the match system which is implemented).

After the match has taken place there are a few states which are the results:

Option 1. Team 1 wins - Team 2 loses
Option 2.Team 1 loses - Team 2 Wins
Option 3. Both teams rejected the match

The last part is database wise implemented (Since there is a handshake inplace where both teams can decide to reject the match or reschedule). Still... there needs to be a place where this can be entered. But we'll get to that one later.

However, the point where I want to focus on first is the whole ladder (since rescheduling a match has nothing to do with the ladder eventually, since its just a matter of checking a box, and setting up a new match).

So this leads me with option 1 and option 2.
With option 1, Team 1 will get the status of protected, team 2 will get the status of invulnerable
With option 2, Team 1 will get the status of invulnerable, team 2 will get the status of protected

With option 2 however, something different will occur. Team 2 takes the place in the ladder of Team 1, and Team 1 moves one spot down in the ladder.

The states of invulnerable and protected isn't that hard to implement, since it is a matter of setting a flag next to the teams and say if they are invulnerable or protected... nothing special about that part.

Its the positioning that troubles me at this point. A basic ladder could be defined by a simple table where it just says:

Ladder
Team, Position, Status

Thats it basically... However, what if... something goes terribly wrong with the Database system? Is there a way we are able to 're-calculate' what the ladder would look like. I mean, a database is a file... and things are being saved into the file. And a file can... when things go really wrong get corrupt at some point.

Sure, this can happen at some other points aswell, but thats damage which can be restored at some point. But with the ladder as I just described as above, there is no backup on how the ladder is being calculated and so on.

There is however one backup plan that sticks in the back of my mind: The Matches!
The matches contain all the info on who won etc. So using that as a backend for the complete ladder to be rebuild (when needed) I could eventually rebuild the complete ladder from the ground up.

Even better yet, I could even say: Show me what the ladder looked like on 20 december 2010. Ok, show me what the ladder looked like on 11 Januari 2011.

So eventually, using the matches as a reference point, I could use this as a "tracking" mechanism to show a ladder from that given point.

I eventually want to take it THAT far. However, this requires some tinkering and thought process on how to calculate the whole ladder. Since this is the part which requires a lot of testing and simulations to mimic this effect.

I will give it some thought, and work out the details somewhere tomorrow. Since I think (at the current state I am at right now) this is the ideal method to make it work... its a safety net more or less... Just in case things go really wrong.

donderdag 27 januari 2011

The technical datasheet



(Click on it to zoom in... Its a pretty big picture ;))

Here's the technical datasheet on where we are at right now. The white parts are the parts that are existing (and might be fine tuned in a later stage), the red parts are the parts that needs to be developed.

woensdag 26 januari 2011

Date acception

Seems like that the date accepted is fixed by now. The next thing I want to try to sort out now is the edit match. Since there are still a few issues wrong with that page. Let me try to explain this part.

The game selection is an ajax call. And when selecting a game, it sends out a request to fetch the information for that game. While creating a match this seems to be working properly since I am more or less "manually" triggering that ajax call to take place (since it happends when i select a game)

However, when requesting the same page back (after pressing save for instance) this manual process is not there at that time. So, my assumption at this point is that the ajax call does not take place, thus it can not fill in all the bits and pieces like Mode, Map etc since the game is just not there yet.

So thats the next thing I need to fix here and there just to make the edit process a bit more 'logical' and understandable what is really happening at that point.

Edit1:
Well, my first assumption seems to be correct. After the form submit take place the ajaxcall is not being triggered. The cool thing though is that the whole result of the ajaxpage is just a part of a form. So... if I can just include that part of the form when I am editing it, I should be halfway there.

Edit2:
So yeah, that should sort it. I am including the same form as the ajax call but now as a PHP Include file. This leads me with a new issue (which I just sorted). Since an ajaxcall is nothing but a new php page request. So it does not have any database connection etc.

While this is all being included from one configuration file, and this config file has one perticular function that only exists in this config file for setting up the database connection, i am simply using 'function_exists' to test if this page is used for an Ajax call, or just being included directly inside the form itself

Now, the thing I do know by now is that a form submit has a post array, while the ajax call does not. With that in mind I am able to tell the difference between if its an form include or an ajax call...

You still follow me? I hope not...

Edit3:
So now i need to grab the values for those parts which are being handled through the ajax part. Which are in this case:

- map1
- map2
- map3

So that should sum up that part i think. Lets implement this one while we are at it.

Edit4 (last one for now I think):
I also changed the same thing with the Dates and Times. Since those never received a default value which was entered by the user. This should be fixed by now

dinsdag 25 januari 2011

Upcomming matches

Right, next up is listing up the upcomming matches I think. This one shouldn't be that difficult I think, since its just a list of matches that have been accepted and are in the future...

Yes... it is that simple



Ok, view pending matches is there. I am using a little "hover" over effect I have been experimenting with earlier on to display the time till the match. Its a nice gizmo since its not always there. It only shows when you are putting your mouse over the dates etc.

Also it should give some additional information about what "TBA" stands for, why its there etc.

However, this leads me to another issue I just encountered. Apperently the status of the accepting dates is not working properly. At least, I had 3 matches made. Accepted them all (set a date) and for some reason it still gives the status "pending".

So what happened there, I do not know yet. But i'll figure that one out later on.

Developments have been slow the last 2 days

Now that i just wrote down the initial post about logging. I like to add that in the last 2 days developments might look like they have been going rather slow at some point.

There are some minor parts I am trying to fix here and there, which is probably not really new worthy to write down (hence the lack of updates in the last 2 days).

Also I like to add that I am currently on some form of medication which puts myself in a very 'drugged' state. Its known as PCH in the netherlands. This means that I am asleep most of the time, and I when I am awake, I do code a bit here and there but it doesn't go as fast as it has been going in the last few days.

I thought I would just mention this one aswell. I am still working on it, but in a more 'slow' state.

Logging

Just a thought I need to write down here, since I am thinking about it. And I don't want to forget this one eventually. Eventually I want to come to a point where I'll log everything thats happening inside the system. And as far as I can come up with there are currently 2 different logs i need to setup

- player log
- team log

These logs can later on be used for 'nice' tools in a later stage. Since it could show a complete history of a player, or of a team. It could show the recent activity from a user. Which teams he has been and so on.

combine that with some nice statistic graph (I am thinking fusion charts in this case), it could turn into a more visual aspect making it look interesting at some point, even while its not even 'that interesting'. It's just more a toy...