mmo

Developing MMO Game Servers in PHP and JavaScript

December 29, 2010 in Programming, Starlis

Hello, I’ve just reset my blog and now going to use it for projects going forward, primarily (at this time) Starlis.

During the early months of 2010 I was working on new bleeding edge technologies toying with the idea of a real time browser based game using WebSockets. The idea was fun. Integrate social networking site Twitter into the game and tie in Real World aspects and gameplay elements. I started the game writing the server FULLY in PHP.

I know that makes some people scream.. but I’m rather experienced with PHP and have knowledge in deeper areas of PHP. I’ve worked on an application networking system for a few years that enables multiple PHP processes to communicate to each other, Inter Process Communication.

Why would you do this? Because PHP is single threaded and a synchronous language. DB queries etc block everything. Cant use that TCP connections! So I wrote AppComm based on the idea from a blog post I found on the internet using proc_open() function. It worked great for other projects like IRC bots and RSS feed parsers until I started doing some serious work with it like the idea of a realtime MMO game server with 250 NPC AI clients playing the game at the same time as myself and others…

I started to see massive performance issues, and it was due to the polling nature of the IPC workings of my AppComm system.

So I refactored the AppComm library and all TCP Socket Streams to be stream_socket instead of the socket_ functions, and implemented an event loop around stream_select to monitor all streams and tick functions for timed interval functions. This gives immediate response to data coming into a stream, so the buffers do not get filled up easily (which is what happened on the polling system, tons of data comes in at once and isn’t read until Sleep() is done sleeping.), and enables the process to sleep even longer and not poll at very quick intervals.

This made a huge difference, and the server runs great now. However under heavy load can still get some high CPU and decent lag, but thats due to MySQL queries due to the synchronous nature.

Notice a reoccuring word here thats a problem? Synchronous…

So I then found Node.JS… Boy does it solve that problem. I toyed with the idea of a rewrite of the game I was working on, but was hesitant about time since already got pretty far into the game and was now at the point of implementing game play elements.

Interestingly, I believe PHP would be decent under my AppComm system without the slowness of MySQL, as that was really the main place CPU time was spent, but I know it’ll never be as efficient as an async system like Node.JS.

But things got busy and dev stopped for a while on the PHP server. Then one day I came up with a great idea for a different game, a space game where I wouldn’t be bound to the horrors of 3d mathematics for handling the shape of the earth (original game was built on top of Google Maps) in all the math calculations.

Lets cut to the chase, I’m working on projects in my free time cause I want to make money off them. With this Twitter interaction game I really could not see many ways to monetize it. I thought of some, but it relied on partnership with advertising companies and other companies etc. I couldn’t see many ways to directly take money from the players.

That’s why my new idea, which I named Starlis, got me so excited. I was out of the grasps of real world ties, and now in a fantasy world freely open to my own imagination. Lets just say I have a very creative imagination.
I immediately started seeing ways to monetize the game, which gives huge motivation to work on the game and make the game good… Because you know the better the game is, the more people play it, the more people will pay me.

Now I can start over in Node.JS! I learned a good bit from the first initial game idea in PHP, and from my own personal experience in gaming: Today’s programmers are idiots. Performance is important.

Sadly I hear so too often to ignore performance from the start and come back and improve it only if its a problem. I strongly disagree with that ideology and refuse to accept it. I have C++ experience with game hacking, which involved ASM and deep memory work, function hooking etc, so I have a functional understanding on the computational flow path of code, regardless of language.

It’s not hard to see where bottlenecks can occur on your program even before you write it.. I firmly believe taking time to design and plan out an applications architecture will overall save you time.

So that’s exactly what I’m doing. Thinking of the areas of code that can be bottlenecks, and writing it efficiently from the start. areas like a network protocol parser will be called in almost every step of the app, so that need to be written efficiently.

I’m currently designing and building the Starlis Server Architecture. It’s designed around full Asynchronous IO, and designing a Complete Graph server architecture with each node running copies of the same code on different physical servers, and each includes a Message Routing system that will keep track of every server in the networks load levels, and automatically send the message to whichever server has the lowest load.

Designing this simple idea from the start and laying it the foundation will be adding horizontal scaling to the application before the application is even written. no hacking or modifying code after the games launched and having down time due to crashes and maintenance due to the re-engineering.

It’s harder to implement a better foundation for a house when a house is on the lot, than it is when there is no house…

You never know if the changes you have to make to achieve scalability requires massive fundamental changes to your applications logic, which if it does will likely cause you to do the least work possible. Around here we call that half-assing. I’m not fond of half-assing my work.

So with Node.JS, I’m developing a fully scalable application architecture from the get go to handle the games server, and top that with MongoDB for its extremely fast performance and built in amazing sharding support, we have a solid foundation for Starlis. A foundation that says “I’m ready for anything.” support for vertical AND horizontal scaling, with code that could be written in 1 week (I’m developing this on my free time, so other RL commitments and personal entertainment makes it impossible to accurately judge how long something is taking me).

I personally think that’s awesome.