Game log

[Nox]

How do you deal with game event logging?
I guess it's pretty important as when I played a certain pbbg when something was reported on forum they
were able to do wonders with that and inspect pretty everything that happend in the game.

But I don't see other way now than insert a function call to every place something happens (will probably be tons
of places) and so on + I'm not sure how to design a mysql table for that. Surely it shouldn't be baked in a text/varchar,
but there will be variable number and type of variables. Maybe id (primary),user,time,type (secondary key) and other table with types
(id, value varchar with a marks like %1%) and third table with those values? Seems a bit too complex for something like this
(like http://buildingbrowsergames.com/2008/05/05/designing-browsergames-a-flexible-stats-system/ )
What do you think (or how do you deal with it)?
Thank you

[Scion]

for me logging output belongs in a file, and you should find several helpers available that support logging to files.

I would be interested in hearing the reasoning behind keeping logging in a db?

[Nox]

Well... it was just in my mind it would be in db and I never thought about it being anywhere else

Except of not dealing with atomicity and easier search and filtering probably none

I believe you understood me right, but just to be sure I add that I meant logging like
"17.2.2009 11:35 Player X attacked player Y, receiving Z resources" or something like that,
I don't mean access log or error log

[Tribal]

the problem with doing something like that, is if you have 50 active users, all making at least 10 attacks an hour, if all users stay on for 2 hours you have already got 1000 logs in your file

i dont know about yourself but i was told not to use flat files for more than 100 records?

i probably would use a file however would more than likey split it up and have file logs per day, then you could have a file structure like the following:

Site Root
    - logs
        - log_category (ie, player attack logs)
            - 2009
                - 1
                    - 1.log
                    - 2.log
                    - 3.log

etc etc....

This would make searching a tad easier, wouldnt be too hard for backing up (crappy windows 2000 file in folder limit thingy) and it wouldnt really create much of a mess on your file system :-)

Thats probably where i would go, what you think? Or have i got completely the wrong idea?

[Nox]

Thank you!

Well...you got right a question I didn't ask, more like Scion mentioned it it would be good to think about.
I meant more like how should be those records stored in db (and didn't hit me to think if it should be in db or not)
and if it's necessary to manually call a function or if there can be some automation.
I actually don't know generaly then what should be put into db and what into file, I tend to store things in db.
Maybe those that players don't really need and I do?

I'm not sure if it's better to put it in categories or not, sometimes it might be useful, sometimes not...
If you say files are better than database in this case than okey, I'll use files
Something like: id time type data1 data2 dataN and make a php file for interpretation of type (shouldn't I go for separate categories)
Won't there be problems with things like 'where type=5 order by data2 desc' or it's fine and you can easily find it according to time
or load it into array and then play with it? (I guess you surely have at least some games with log)

And do you have any idea how can this be automated or is it unavoidable to insert and fill a function call in every single place
an action should be recorded? With tokens it's pretty stacking up those things one shouldn't forget

Ah, there's plenty of questions, I hope you'll survive that

[toxin]

I think it is a good ideal to put player actions in the database. It may be a good ideal to add conditions that must be met before you do this.
You may not need to log every attack. You could randomize the log with a 1 in a 50 chance it will get logged. Or you could set up  conditions that trigger the log. Player x has attacked player y online 15 time in a row. Player y gets upset and may quit since he can not play as he keeps getting hit by player x. you can log this to keep track and take actions if you think one player is harassing another to a point they can not play.

[Nox]

toxin
I thinks it's important to log everything...for example I can't figure out that player 1 attacked player 2 ten times, when 7 of that attacks were not logged due to bad roll

[toxin]

Have not tested this in a game. It needs more work.
SQL

Code: [Select]

CREATE TABLE `user_logs` (
  `log_id` int(11) NOT NULL auto_increment,
  `user_id` int(11) NOT NULL,
  `user_name` varchar(255) NOT NULL,
  `action_type` varchar(255) NOT NULL,
  `opponent_id` int(11) NOT NULL,
  `time` varchar(255) NOT NULL,
  PRIMARY KEY  (`log_id`),
  KEY `user_id` (`user_id`,`opponent_id`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 AUTO_INCREMENT=3 ;


function log_user_action($user_id,$user_name,$action_type,$opponent_id,$time)
{
include'db_con.php';
mysql_query("INSERT into user_logs Values('','$user_id','$user_name','$action_type','$opponent_id','$time')") or die(mysql_error());
}


log_user_action("0","username","buy","0",date("M n h:i A"));


I had another thought but lost it.

[Scion]

the problem with doing something like that, is if you have 50 active users, all making at least 10 attacks an hour, if all users stay on for 2 hours you have already got 1000 logs in your file

i dont know about yourself but i was told not to use flat files for more than 100 records?

really?

In the product i develop at work if we switch the log level to debug we will generate well over 1GB of log file every hour.

Its important to remember that 99.99% of log file entries will never ever need to be examined. So you dont really need to run lots of querries and searches. When you do then you use tools like grep to isolate the entries that you are interested in.

If you need to keep a record that A attacked B why not have an attack table that stores all the attacks that have taken place. or a trades table for the trades, etc.

I wouldnt call that logging....its more sort of keeping a transaction history....which IMHO certainly belongs in the DB.

[Nox]

Thanks for ideas

1GB/hour hell, that's something

So I might go for a few tables with similar subject and data structure.
toxin - I thought about something like this in the beginning,
the problem is that since its "log_user_action" and not "log_user_attacks" there might be required more than 1 extra data (like opponent_id)
and opponent_id might not be needed in some types of actions.

Ok, "transaction history" , so DB then...

Its important to remember that 99.99% of log file entries will never ever need to be examined.

Probably yes...I don't know...if you have experience with this (rather from games) I'm surely willing to listend.

It's just - I used to play one very good game and from bug report section in it's forum I got an impression,
that they were able to extract almost anything that happend in the game (cca 6-10k players, turn based),
well, maybe I'm wrong, it was some time ago or I got that impression wrong...but it would be nice to have a good log

[MystressNyx]

I can tell you from personal experience with our games that yes, you should log ANYTHING that involves interaction between players. Even if you can't imagine it as something you might ever need to check on, eventually, you will. Either you will need to know what happened or, as it began with us, your players will want more and more details after the fact.

We do this logging in the DB with a different table for each log type so that each can be designed specifically for the data it will need to hold. For example, in one game we have hack logs, mission logs, and faction logs. While it may seem cumbersome to have the additional tables, it's actually more efficient as you're never searching through data from all the missions when you really just need to see the hacks.

[Sraet]

You will generally want to make what is going on more explicit as well. If you want to track down exploits so you can see when to roll back to or what to remove from whom and the like, you will want to see things that give odd results. When fighting should the damage ever go about 10000 points for example? Cause if it does that would be an event to log. Did some one spend more money than was in their pocket/bank/whatever? Was there a transaction between players that doesnt make sense? All I am saying is having a list of 'player (id) with (name) bought an object' is not a very helpful log.. Just make sure they include enough data to be useful instead of just a list of an action. You may also want to add IP address information and the like, see if someone got the haxor

Morale of the story: If you are going to spend the time to embed logs into your game, and the space needed to store and keep track of them, make sure they are useful

[Nox]

Thanks very much for posts, good ideas
That's what I meant by "extra data", but I guess I wouldn't go as deep as is required before

[Scion]

yes its important to pay special attention when designing your log messages...yes, you should design your log messages! not just print out some semi random stuff...

Just to add a further 2 cents...

I think its important to distinguish between keeping records of transactions or other interactions between players and what i would call more traditional logging.

Transaction records are probably best stored in the DB, or at least the most recent ones, this has the benifit that you can integrate the access directly into your games admin panel, or even make it available to the players. Show them a list of their last 10 trades, or allow them to export them as a .xls file... Thes log entries dont need to be just strings, they can include references back to the original objects. So you have a lot richer level of information than if just using a string (or at least easier to access)

Logging is what i use to let me know whats happening in the application itself, generally logging systems include different levels of priority of log messages, error, warning, info, debug are all commonly used levels, This is where i would put any messages about unusual circumstances in the game. Logs like this are easy to process ofline.