Game Settings

[codestryke]

I'm slowly working on this game engine, it's been one of those projects where I'm either making huge leaps and bounds with the coding or it just sits on the hard drives. One day I will complete it, I think LOL.

One of the questions that I always pondered for the engine was how to do the settings for the game. When I code a game I use include files but I don't want game owners to be able to access raw PHP files. I could stick them in the database but that would be very inefficient (hitting the db on every page to load settings data).

The next idea I had was to use an XML file. I found, once again, that XML is terrible to work with even via PHP. It worked but was very wordy in the code. It was at this time I was going to put that question on the back burner and code other functions of the engine until I hit upon a mention of INI files with PHP.

We all know that PHP uses an INI file for it's setting so I started to read up on some of the native PHP functions dealing with INI files. So far so good, easy to use, the INI file itself easy to understand if you had to access it directly for editing but what about speed?

I found this article on the web http://www.phpro.org/articles/Application-Configuration.html that profiles the speed of different ways to handle application settings. What I found the most interesting was how fast the ini file was vs other methods (php include, xml, database) depending on size of the configuration file. A bit more searching / researching uncovered the mystery of the speed. The INI functions are built into PHP nativly so you are dealing with compiled C, where as includes, xml and database are using interpreted commands.

Something to ponder on your next game

[Mufasa]

Interesting, never thought to do something like that. I always just use a global include

[travo]

Thats a good thought, definately has me thinking. I might run some tests now, see what happens.

With my current config file, it was quicker by a few milliseconds. Hopefully my game will get to the stage where I need those milliseconds

Thanks for the find

[Chris]

About the test
I'm not sure about the database test there.
- it treats opening database connection as a cost (which is irrelevant in BBG since you need to have the connection anyway so it should not be considered a cost).
- they used VARCHAR while obvious choice is CHAR (this way MySQL knows where each record starts).
- in the second run they obtained 1 value only (and you usually need more than one), while other methods obtained all values.

Perfect solution
It seems the best solution would be to store all the data in database. Then, once you change the data you not only write it to the database but also parse the database and create an INI file out of it. Convenient, able to backup everything via SQL dump and very fast (since visitor use only INI file).

The problem is with changing settings under heavy traffic. Especially if your engine needs to change same values by itself. What will happen when you write to the file while other user try to read it? I don't know about internal PHP write, but when I upload files via FTP I get strange errors (the file is unavailable then). This could really mess with your game, imagine situation when you have a cost of units stored in settings file, then an user click "buy units for all money" while the file is not available so he gets cost=0...
Anyone got experience with this? I did test with FTP upload only and the results were disastrous (now I first disable the game via database settings then upload things). I wonder if similar problems can be observed with PHP file write.

[codestryke]

Perfect solution
It seems the best solution would be to store all the data in database. Then, once you change the data you not only write it to the database but also parse the database and create an INI file out of it. Convenient, able to backup everything via SQL dump and very fast (since visitor use only INI file).

I beg to differ on that point greatly. We use to use that method ourselves but converted to using includes/defines because under extremely heavy load, say 150+ users online, the database starts to become very lagged. We saw huge improvements across the server once we switched off from the database for certain configuration settings.

I would not use the INI approach on things that may need to change during the course of the game. I'm starting to use it for database connection settings and path information. I have 3 different environments I can have code on.. Live server, my dev computer and finally a jump drive each one has different setups. With this method I can have one file I need to update to get up and running, or one file to exclude when moving files from one platform to another.

In the near future I'm looking at converting possibly our round information that only gets changed once before the round starts to use the INI and see what type of performance gain we get.

The other thing to look at was the test, as you stated it only grabbed one value from the database (yes I agree a CHAR would of been better). Lets say you have 5 config settings for a gang module. With a database you have 2 approaches you can take to get all that data loaded.
1. Query each setting one at a time, so 5 queries, and put them each into a variable
2. Query all setting for gang, get a record set back, loop though the records set and make them variables via variable variables.

Method 1, 5 queries, even cached it's going to impede performance
Method 2, Using an interpreted loop is going to be slower then native C code of the php engine

Using something like INI vs defines vs database is very conditional but it's nice to know all the options

[Chris]

I beg to differ on that point greatly. We use to use that method ourselves but converted to using includes/defines because under extremely heavy load, say 150+ users online, the database starts to become very lagged. We saw huge improvements across the server once we switched off from the database for certain configuration settings.

I meant:
1) Store variables in database for ease of use, edit them, backup, etc.
2) Once the database settings are ready dump it to PHP/INI file (and only the file is read by the game, the database is read by admin panel only).

I would not use the INI approach on things that may need to change during the course of the game.

Yes, but it is tempting... I always need dynamic global data (per game not per player) in my games. So I end up creating some settings table anyway (1 additional query). It is a real waste since it is written by the engine only and very rarely (like 1 per hour things are recalculated and global setting changed). If I could use file instead...

[travo]

1) Store variables in database for ease of use, edit them, backup, etc.
2) Once the database settings are ready dump it to PHP/INI file (and only the file is read by the game, the database is read by admin panel only).

Similar to what I was thinking, but I had a thought...
If the INI file is being written to and someone tries to read it, will they get an error trying to read it?

Not sure if it happens or not, but easy fix if it does, if parse_ini_file or whatever the function is returns false, read from the database.