Merchant Empires: Coding your own PHP Universe LG #63

#

#### "Linux Gazette...making Linux just a little more fun!"

# Merchant Empires: Coding your own PHP Universe

#### By Bryan Brunton

Bryan Brunton is the creator of the Merchant Empires Project. Merchant Empires is a multiplayer, web-based game of space exploration and economic competition. It is a game of strategy, role-playing, combat, and diplomacy. Merchant Empires is based on the venerable BBS game Tradewars. In the article below, Bryan Brunton is interviewed about his experiences in bringing Merchant Empires to life.

Q: Why did you write ME?

A: A number of reasons. First, I wanted to see if it could be done. I have always been a fan of space based strategy games and I have always wanted to write one. Although I knew that the efforts of bringing the idea to completion would be at times tedious, I didn't care. Secondly, I ran across a game called Space Merchant which is a closed-source, ASP-based implementation of Tradewars, and I was appalled at how badly it had been done. In my opinion, there are many things wrong with the Space Merchant implementation but one thing really struck me as ridiculous: when playing Space Merchant, occasionally an error screen would pop up that said, "Command not processed due to an Error Storm. Please log out and try again." The utter inanity of the the concept of an "Error Storm" and that someone was attempting to pass that explanation off as rational was, to me, hilarious. I said to myself, "Tradewars deserves better than this." However, at the same time, I don't want to overly disregard the thought and effort that went into Space Merchant. The developers of SM deserve a lot of credit for their work.

Q: What software have you used to bring ME to life?

A: Here is a brief summary of the open source software used in ME:

> Apache
>   Any webserver that supports PHP could be used.
> PostgreSQL
> PHP
> PHPLIB
>   This libary provides classes that simplify PHP database access and session tracking.
> Python
>   The first version of ME was written entirely in Python. Due to performance considerations, I switched to PHP. Parts of ME remain in Python.
> PygreSQL
>   The ME event processor and map creator gather and update ME data that is located on a PostgreSQL server using these libraries.
> Medusa Asyncronous Network Libraries
>   Medusa is used in the ME event processor. These libraries provide telnet access to the ME event processor.
>   The ME event processor and map creator gather and update ME data that is located on a PostgreSQL server using these libraries.
> KDevelop
>   KDevelop is a great editor for HTML/PHP code. I will probably be purchasing the new PHP IDE from Zend.
> Gimp
>   Almost every ME image has been created with this excellent tool.

Q: Many of the ME players tell me that the ME site has been, at times, less than stable. What problems have you run across while developing ME?

A: I ran across a number of bugs and gotchas. The pre-configured scalability of the operating system itself and applications such as Apache and PostgreSQL in most Linux distributions is really quite horrible. In my opinion, pre-configured Linux does not provide a stable platform for a medium traffic, database backed website (Apache + PHP + PHPLIB + PostgreSQL). And when I say pre-configured, I mean as installed on the average PC from any of the popular distro CDs.

Here are a few of the problems that I have run across (most of these caused major headaches):

- The maximum amount of shared memory, open files, and file nodes on most Linux distros is set pathetically low.

- Apache, PHP 4, PostgreSQL had (and possibly still have) problems with permanent connections using pg_pconnect(). Either the PHP parser or Apache does not correctly close database connections when a child http process terminates.

- ReiserFS and PostgreSQL had (and possible still have) issues with using PostgreSQL with the -F option (no fsyncing on each write operation). This would result in corrupted file system and/or database.

- I purchased a NetGear networking card. The tulip driver for this card fails miserably under high load. In my opinion, the monolithic Tulip driver is a mistake. It gets rewritten and older NICs suddenly stop working. It doesn't function consistently across all cards.

- The back-end storage manager for PostgreSQL doesn't dynamically free deleted rows. This has a major impact on performance on heavily used tables. The PostgreSQL documentation states: "Running VACUUM periodically will increase the speed of the database in processing user queries." The documentation doesn't define exactly what "periodically" means. Who knows how many people just like myself have wondered why the load on their web server is at twenty because PostgreSQL is missing decent documenation on admining the database for a high traffic site. Also, PostgreSQL ships with a back-end process limit of 32. That number is abysmally low for a site with even medium levels of traffic.

Q: Why on earth would anyone want to put away one of today's state-of-the-art games like Quake III in order to open up a web browser to play ME? Just how interactive can your game be when it doesn't require the CPUs on your player's computers to make even a single gigaflop of floating point calculations?

A: The stateless void of HTML is certainly the last place a player wants to be when, potentially, an enemy vessel could be pounding him into space dust. But a browser based gaming environment has advantages that I value. I looked at a number of similarly directed projects before writing ME. Many of them had stalled or the developers had spent six months time writing a server and client with no playable game to show for their efforts. I wanted to spend my time immediately writing game code. Spending untold hours writing a scalable multiplayer game server was (1) beyond my ability and (2) boring. Also, I like the lowest common denominator factor involved in playing ME. All you need is a web browser that supports javascript. You can have access to and play ME from a far greater number of places than a game that requires client installation and configuration. As far as what makes a good game, I have always enjoyed intelligent turn-based game play, not frames per second.

Q: The gaming industry as a whole has been very silent concerning Merchant Empires. Recently, when questioning one industry representative about ME and his company's initiatives in bringing games like ME to the marketplace, we received nothing but silence and utter denials of any involvement. What commercial interest has been shown in ME and what future do you see for the "resurrected-from-the-dead, BBS2HTML" gaming market?

A: There is no commercial interest. I despise banner ads. The Merchant Empires site that I run will never use banner ads. This means that I can probably never afford to purchase additional bandwidth to host ME (it is currently run on a friend's 768K DSL line). There is always the chance that a well funded organization that wants the honor and privilege of sponsering ME could provide additional bandwidth. One side note on DSL: while it is great that such cheap bandwidth can be brought to the masses, the reliability of DSL (as profided by QWest in the Colorado Springs, US area) is attrocious. Only a company in monopolistic control of the market, as QWEST is, can afford to provide such lousy service.

Q: How popular is ME?

A: Over 7,000 people have created users. ME has a loyal group of a couple hundred players that play very regularly. In my opinion, the game is somewhat limited in its playability due to its simplistic economic and political models. I would like to flesh out these areas so it might have a greater appeal. The possibility for role-playing is very limited beyond pirating and player-killing.

I enjoy hosting ME because there is something that is just cool about writing a piece of software that gets frequent use and can potentially generate lots of data. I don't know why but I just like lots of data. The ME database can grow to over 100 megs before I delete data from old games and players.

Q: What do the ME players most enjoy about the game?

A: The players seem to most enjoy the politics of planning ways to kill each other. The same is true for most online games that involve combat. In ME, players pick sides and then organize toward the goal of conquering galaxies and then the entire game universe. It is fascinating to watch the organizational approaches that different alliances take along a autocratic to democratic continuum. Many of the ME players are also programmers who provide development assistance. The players definitely enjoy watching the game grow and improve.

Q: What plans do you have for improving ME?

A: IMO, Scalable Vector Graphics (SVG) are the future of the web. SVG is essentially an open implemenation of Flash. SVG could potentially be more powerful because it is based on open standards such as XML and Javascript. It is unfortunate that browser-based SVG support on Linux is limited to a some barely functional code in the MathML-SVG build of Mozilla. On the Windows and Mac side, Adobe provides a high quality SVG plug-in. But as Linux is my current desktop of choice, I am currently caught in this SVG dilemna.

There are a few big features that I want to put into ME. I'd like to implement a java applet that could provide realtime game information. I would also like to introduce computer controlled ships and planets. Eventually, a computer controlled Imperium (the police in ME) will play a larger part in the game.

I would also like to remove ME's dependency on PostgreSQL. I have nothing against PostgreSQL but other people have inquired about running ME with MySQL. Currently most of ME's database access is through data classes provided by PHPLIB so removing the few PostgreSQLisms in the code wouldn't require much work.

I am planning on a few major changes in ME 2.0. I want to have hexagon based maps (currently sectors are square). But to do this right, I need SVG. I want to implement a whole new trading model where there are literally hundreds of different goods and contract based trading agreements. I'd like to do away with ports as separate entities, making ports simply a feature of planets. I would like to replace ME's current simple experience point advancement model with one that is skilled based. These and other ideas are discussed at the ME Wish List over at SourceForge.

Q: It has been noted by your players that your code sucks. Please don't take this the wrong way, but I really must agree. Before this interview, I was looking through the code to your event processor, the server side Python process that handles important game events, and I noticed that all of the program's intelligence is crammed into your networking loop.

A: You should first consider that I wrote Merchant Empires as fast as I possibly could. My approach was very simple: look at a Space Merchant screen shot and reproduce it as quickly as possible. Also, writing Merchant Empires was quite intentionally a learning process for myself. Parts of Merchant Empires use C++, PHP, and Python. While I had limited C++ experience, I had never used, and knew nothing about, either PHP or Python. I wanted to learn both of these languages. Parts of Merchant Empires, such as the inconsistent use of CSS and the combat functionality, are from a coding standpoint barely at the proof of concept stage. At the time that I wrote the event processor, I barely understood what a select networking loop was. Today, I have forgotten everything that I learned on that concept and now I am just pleased that that particular piece of code still works.

Q: So your code is pretty rough around the edges. Have you considering using any recursive programming techniques to spruce it up?

A: Recursion, if properly used, is an awesomely powerful programming tool. However, I have never actually used it. I thought that by interviewing myself for this article (which is a somewhat recursive process), I could introduce myself to the concept of recursion, and if I like it, consider using it in the future.

##### Copyright © 2001, Bryan Brunton.
Copying license http://www.linuxgazette.com/copying.html
Published in Issue 63 of Linux Gazette, Mid-February (EXTRA) 2001