A demo session of the eleven chat client

I hear that's the thing beginning programmers say to game developers. One of those naïve things people want to do who don't know any better. But while I agree it's an illusion to think we, as beginners, and a single person, could just write out the next World of Warcraft, I can totally understand why one would want to do it.

The reason why MMORPGs are near-impossible to pull off is the same reason that makes them so interesting: They're a big honkin fun challenge. They combine all the fun tech and its problems. And they're fun to use and well regarded as well. Think about the challenges:

  • Graphics and animation - often even on low-end machines, often in 3D, with bone meshes, inverse kinematics, several detail levels of models and customizable weapons, avatars etc.
     
  • User interfaces - often completely custom written on top of low-level 3D engines.
     
  • Maths - figuring out how leveling needs to work, how different weapons interact, but also pathfinding, and graph theory for the NPCs' limited AI.
     
  • Social and economic science Managing interaction between players to encourage fun, discourage trolls and griefers, and balance gameplay between beginners and hardcore gamers or at least keep them from interfering with each others enjoyment. Often also involving trading systems.
     
  • Networking - Including load-balancing of lots of users, accounting for input lag, streaming level data and video.
     
  • Security - In addition to traditional hackers, you've got lots of players and script kiddies who are fans and are just trying to game the system a little for personal benefit.
     
  • Storytelling and content-creation - Non-sequential stories depending on user decisions, and lots of other content overlapping with graphics and animation to keep players coming back, and to bridge the gaps between story missions.
     
  • Databases - Includes storing all user information with good performance under heavy load and with transactional integrity even on sudden disconnects (e.g. so you don't pay for an item and then don't receive it).

I think the only thing from computing you don't need to know how to do for an MMORPG is how to build hardware dongles and write their drivers.

And you want to build one?

Well, yes and no. I wouldnt really want to run an MMORPG. I also already have a job. And I suck at 3D modeling. But a bunch of these problems are intriguing and fun to think about, so Im tinkering with ideas, writing little test projects that implement this or that part that one would need for such a game. I've also been reading a lot of stuff on Stack Exchange's GameDev sub-section, for example a question on how one calculates the leveling of characters.

So you might just see me blog a little more about game design in the future. Or this may be the first and only post I'll do about this topic before I lose interest, who knows.

So what have you made so far?

Having played a couple hundred hours of Star Trek Online, I realized that a lot of the program felt like a graphical client talking to an IRC server that had a bot that ran the actual game logic. So the networking layer is what I wanted to start with. I'm not sticking to any IRC specification, but simply started implementing a modular chat server that is kinda similar to IRC, and has chatrooms (which are useful for separating maps and their communications overhead), and of course user accounts with blocking mechanisms.

The advantage of this approach is that, even if I don't ever make a game that uses this, it may be useful to other people who are looking for some sort of networking layer, be it for chat, or for some other social program. And at the very least it let me practice sockets and is allowing me to learn how to use TLS to encrypt a connection.

Where will it go from there?

Well, the basic idea is to then build the bot that actually implements the game. It will live in chat rooms, one for each map (i.e. a city, planet or whatever) and let you connect to one. Once in a chatroom, it will send you all the data you need to get started.

In the case of a graphical game that would be models, level maps etc. as well as pending messages you may have (e.g. crafting operation completed or spell prepared etc., but also remind you of mission rewards you need to accept or present a mission introduction you haven't confirmed as read yet). It will also send status about the player, like inventory, cooldowns of abilities you've recently used etc. and update you about changes in any of these, and inform you of nearby enemies and allies and what they're doing (to you?).

You can now send commands to this bot, which include character movements, casting a spell, firing a weapon or whatever.

So, oddly, all of this feels a lot like it can be implemented fairly elegantly and simply as sort of an IRC/e-mail hybrid with read receipts. And this can all be done without needing to have a client, nor any graphics. Heck, you could test this by writing an ASCII client that looks like NetHack.

The game map

The game is streamed, so it might not be the best idea to download the entire map at once. Especially if you want to be able to maybe have large or endless maps, or maps that can be re-used for different purposes. You'd want to be able to only load those parts of maps that the user visits for this mission.

So the obvious approach so far seems to be to just split the map up into tiles that have relative locations to each other and then load the tiles surrounding your player's location, and when the player moves load additional ones so you never run out. This can be a 2D tiled map to start with, but can easily be expanded into cubes that can also be stacked vertically.

To simplify, I'll probably have only a 2D coordinate inside each tile. The vertical coordinate for a player or NPC inside its particular tile-cube will then simply be decided by the ground level underneath it. Since we can connect the tiles arbitrarily, stairs would still be possible to make. Just create a tile with the stair model at its end:

StairsOnTileMapExample

The player will seem to walk up the stairs because the ground level rises. If we now connect the left edge of the tile to the tile one level up, the user will easily walk up one level. The only downside of this approach is that a character wont be able to hide under the stairs.

Another advantage of using such tiles is that they can be used for collision testing. You can just block an entire tile from being stood on.

That wasnt too hard ?

Well, this is still missing any item management, interaction, mission objective enforcement, combat or pathfinding mechanisms, so it's far from a game, but yeah, its probably what I will try to implement after the chat server is finished. Or maybe Ill just oh look a butterfly.