Framework Merchant Empires :: Tutorial :: Installation


If you went too far, you can head back to the Getting Started page.

Now that you were very astute in the getting started step, and your two paths are committed to memory so deep that only 6-8 weeks of decomposition will get rid of them, you are ready to set up the framework.

Q. Why did you choose MySQL? skip

A. Well, because the PgSQL people are somewhat rude about stuff their database server cannot do. Hear me out before sending me dirty emails. First, I love PgSQL. It's very stable, fast, and has some features that make programmers drool. I simply adore the transaction rollbacks (to specific points in time, no less) and the amazingly efficient caching that actually does improve the overall query speeds for many applications.

The problem with PgSQL becomes apparent when you try and code an online game (I am so going to get flamed in my inbox for this). In the beginning, PgSQL will outperform just about anything you can throw at it, but after awhile the performance will degrade. I believe (but I don't know) that the issue is the transactions, which I feel PostgreSQL is built around. The superior level of control over transactions is very cool if I was running a commerce application, but creates an unstoppable bottleneck for gaming. Please don't message me and tell me how wrong I am, because I promise you I have done the homework and used both MySQL and PgSQL. In fact, I prefer and use PgSQL for all other projects I've been involved of since 2004, including one online game that still is active on the internet.

MySQL, on the other hand, comes with three different storage engines (more than that, but only three that are useful). They are InnoDB for transactions, MyISAM for direct DB, and their Memory engine for heap tables. To me, it's nice leaving hit counters and score incrementers in a MyISAM table, which is very fast. For real time battle stuff, a memory table works well. All you need is a little backup task for redundancy. This leaves the transaction tables for when they are needed, not as an implied thing. One dispute of what I just said is going to be "just don't use transactions". Well thank you. Glad to know that I can just pull the transactional code out of the storage engine and recompile PgSQL.

// Sample of an important query that doesn't need transaction support
UPDATE `player_scores` SET `total_score` = `total_score` + '$new_score' WHERE `player_id` = '$player_id';

The above query is not resource intensive. Depending on your server configuration, PgSQL may do it faster than MySQL, and maybe it won't. In *my* experience, MySQL will handle this faster using a MyISAM table than PgSQL will handle it. To see this test in action, make yourself a script that runs this query for 50 arbitrary players, randomly. Keep a log of the query times, and invoke 10 copies of the script in the background. When finished, take a look at the average query time.

In my opinion, and based on my experience, PgSQL is not a good candidate for online games (but it's an awesome candidate for anything else, except maybe the space shuttle or tomahawk missiles). In fact, MySQL really isn't the best either, but the extra storage engine options are very attractive. You gotta admit that running a SQL query against shared memory is cleaner than using sysvshm.

Now that my speech is over, we can install the app. What we have to do is import a SQL file into the database server and edit one of the php scripts to reflect the server settings. The file is in the code folder, and is aptly named "insert_me.sql". Don't insert it yet until we cover a few things.

The sql file relies on the database name "framework". I apologize, but I don't have an installer for the app yet, so I had to make a direct dump of my own structure. If you are comfortable with editing a SQL file (it's chunky) then go ahead and rename it. Just remember what you name it to for the setup in a few steps. I simply do not know if you have to create the database first, but I recommend it just so things are as smooth as possible.

Also, take the time to create a db user and password with full permissions on the framework database. Make a note of the details and find the file constants.php, which should be in the same folder as the lovely pair include_me.php and insert_me.sql (you feel like Alice yet?). Open this file and scroll down to the defines DB_HOST, DB_USER, blah blah. You should be able to figure out this step. :-)

Once your changes are made and constants.php is saved, do the database insert using your favorite MySQL client. For this step there are three common ways. The first one is the MySQL command line client. Another way is the MySQL Admin GUI application (use the DB Restore feature). Thirdly, there is the phpMyAdmin admin project. You will have to choose which one and go from there.

Inserted? Good. We are ready to get started with our first game script. If you messed up any of these steps you will hear about it really fast in the next page. If something doesn't work right, try it a second time before emailing me with something like "i cant get it to work lol how do i fix it?"

Head over to the Hello World page.