Tools and environment

Since I have not had the chance to touch the code (my wonderful girlfriend is in town over the weekend; it was a very good trade), I figure that as long as she was surfing her knitting blogs, I would regurgitate some old info, interspersed with new stuff, into one entry so it’s easily accessible.

Environment
Both client and server are being written in Python (you may have guessed this due to the prominent associated tag spread throughout the previous entries). The client uses pygame for rendering.

Client and server are also using the multiprocessing library, which allows me to run what would normally be threads (limited by Python’s global interpreter lock so that only one could actually do anything at a time), sharing (serializable) resources between processes, chief among them being the map. On the server, this will be instrumental in handling client connections outside of the main game thread.

While I had started with C++ (and am still quite the fanboy), Python is immensely faster for development. Many things that require questionable libraries in C++ are either built directly into the core of Python or supported by well-maintained extensions to the language.

Tools
The server will only ever run on Linux; to start with, it will live on my EC2 instance. That makes server development relatively simple; since I work and play in Linux, it’s already right at home.

The client is also being built in Linux; however, the intention has always been to build it for Windows as well (hopefully Mac, too, but definitely Windows). For this reason, I’m trying to stick with completely portable libraries; I think I’ve been successful so far.

As far as actual code, I write mine in a great little text editor called Geany. While I’ve been pushed towards Komodo by some very capable coworkers, it’s not in Portage (Gentoo’s package manager), so I stubbornly abstain. ;) Running the code is handled directly from the command line.

Motivations
This project is meant to satisfy a few cravings on my part:

I’m not using a separate data store for game world objects, so I don’t have a connection bottleneck there; since I’m running separate processes for each connection to the server, the GIL isn’t a problem either. My main considerations, then, are how many processes a single server can handle effectively, and how much game information it can store in memory.

Since the multiprocessing library can almost trivially expand across multiple machines, I can at least attempt to scale up in this way; also, I have experience integrating with memcached, which could assuage my single-machine memory limitation. Both of these things introduce latency (inter-server communication, in both cases); how much will depend upon how well I can limit the necessity for connection processes to access and manipulate game data, and how efficiently I can represent the game world and its contents in memory.

Part of the reason it took me so long to pick up Python is that I was always under the impression that it was slow… as in slower than PHP. Yes, it is slower than reasonably well-written C and C++; however, it is a great deal faster than most interpreted languages. The execution speed argument is meaningless on the client; any machine built in the last five years will almost certainly run the client application with no trouble at all.

The server is obviously a different matter. I could almost certainly handle a notably greater number of connections with a good C++ server app than with one written in Python… however, while my C++ is good, it’s not exceptional — and, quite honestly, if I tried it in C++ again I would probably just never finish it. That’s not a general argument for Python, of course, but in my case it’s another relevant point.

Anyway, I’m working late tonight on a database migration for a client… going to see about writing a bit on the game before I start on that. Thanks for reading!

Comment

Commenting is closed for this article.

Trials and Tribulations

You've made your way to a brief record of the odd and intriguing events which constitute the development of my pet project, The Great Two-Dimensional Online RPG.

Tags

android, architecture, c++, client, crafting, ec2, git, graphics, ipc, java, leveling, maps, menus, movement, multiprocessing, processing, pydoc, pygame, python, queue, rendering, scaling, server, skills, stack, synchronization, textpattern


RSS Feeds

Search This Site