server – (defun games ())

Lisp logo by Conrad Barski

What? We’ve had blog posts about the fact that we’re writing Spycursion in Lisp. Some call it secret alien technology. Okay, full disclosure: Lisp as a computing language was created on Earth by a human (his name was John McCarthy) back in the late 1950s. I can’t say whether or not he was inspired by beings from another world. I don’t know for sure, and even if I did, it would be a secret. I would never say. What I do know is that there is a great deal of power packed into the elegant and surprisingly simple programming language known as Lisp. Every few years, we see more modern languages (say, C++, Java, or Python) bringing in “novel” programming constructs into newer releases of the language. Yet, these exciting new constructs are frequently taken from Lisp and often have been part of Lisp since darn near the beginning.

So, it’s a great language if you’re a programmer willing to venture outside the proverbial box. But why did I start off talking about Lisps, plural, as if there were more than one? Simple: there is more than one. In fact there are many. Lisp is actually a family of programming languages. A Lisp can be quite different from other Lisps in much the same way that C++, Java, and Python are different from each other. (If you’re curious, those languages all belong to what could be called the Algol family.) What we have been generally referring to as Lisp is actually a language called Common Lisp, which is the result of an effort to consolidate features from many of the earlier Lisps into one standardized language. Common Lisp is a powerful choice, which allows our tiny team of developers to deliver you a great big gaming experience full of secrets, intrigue, and espionage in a dystopian world just waiting for you to leave your own unique mark on it.

But Spycursion is an MMO. For the three of you who don’t already know it, that means “massively multiplayer online” game. We would like you to know that we are taking that first M very seriously. No doubt you have heard about some online service that fell to its knees at some point because a mass of people all tried to connect to it at the same time. I remember, as a keen example, an evening in recent history when newscasters were reporting the increasingly certain result for a presidential election in the United States. So many people in the country were frightened by the outcome that the Canadian immigration website eventually went down that night. Some people thought this funny. Others thought it worrisome. I thought, Canada did not program its immigration website in Erlang.

So, what’s an Erlang? It’s not a Lisp (though that would certainly have been a sharp guess). It is, however, a programming language and an extremely powerful one at that, just not in the same way that Lisp is known to be powerful. Erlang was not designed to be a general purpose language with Lispy features that lets a tiny development team like ours mould the language itself into the perfect tool to build Spycursion for all of you. Erlang was designed specifically so that when hundreds of thousands (or dare we imagine, millions) of you all decide to play Spycursion at the same time, our servers don’t fall flat as if they had nothing more important to do than to provide information about immigration to Canada to panicking voters.

Erlang is a programming language whose central purpose is to do a massive number of tasks at the same time and also to create systems that never go down, ever. The downside of a language that strives to achieve what no other programming language can is that it is not general-purpose like Common Lisp. Erlang is primarily a server-side language, and so we aren’t really aiming to keep your own personal computer running. Rather, we want to make sure the computers responsible for providing you access to the world of Spycursion are able to keep that world available to you, even if you all decide to enter the game at the same time, even when we have to update our systems, even if we have hardware issues, and even if one of us has somehow missed a bug in our code. (There’s less chance of that in Erlang, but it still happens to the best of us.)

Yet, as we said, Erlang is not a Lisp. We are (defun games ()), which has Lisp right there in the name. (And we’ll give one month of free game play to the first 8 people who figure out how that makes any sense.) Sure the Spycursion client you enjoy on your computer is powered by Common Lisp, but we also want that Lispy goodness on the server side so we can fine-tune our programming language and bring you the best game possible. Unfortunately, there is almost always a trade-off when making design decisions about programming languages. If only Erlang were a Lisp so that we could harness the superpowers of both languages at the same time.

Now I am guessing that perhaps at most three of you have heard of LFE. It may be more of that secret alien technology, but it too was created on Earth by a human (his name is Robert Virding) back in the mid 2000s. LFE stands for Lisp Flavoured Erlang. As the name implies, we have Lisp and Erlang in a single programming language. We at (defun games ()) feel that it truly represents the best of both worlds. We can use the power of a Lisp to extend the language so that it is not only a gaming language, but a language oriented specifically for Spycursion. At the same time we can build the world of Spycursion on the solidly reliable and massively parallel foundation that comes with an Erlang-based application.

LFE logo by Duncan McGreggor

So, how many Lisps do we need? To provide you the best massively multiplayer online gaming experience we possibly can, we need two: Lisp Flavoured Erlang to serve you en masse and Common Lisp so we can delight you individually.

I was looking at our previous posts and I noticed that Scott had written a bit of an overview of what the server does, but I never made any attempts to make any explanations about the client, I guess that somehow I tend to think that everybody knows, but some times is better to talk about what you think everybody knows. The client, is, after all, the most visible part of the game.

If you write a single player game, normally you can get away with having everything in a single place (the executing machine). The natural question when you have an online multiplayer game is, What can you have in your client and what must be on the server?

Let’s imagine a simple game which can be played online, “Air Hockey”, and of course, keeping it simple, just two players. Each client could have a map (the table), the assets (the paddles and puck graphics), the sound effects and music. Since each player is using a different computer to render the table, paddles, puck etc, we could quickly come up with two versions of the world, the one you see and the one your opponent sees, and that can greatly affect game-play. If you try to block the puck but it is not where you thought it should be, then you could unfairly loose a point.

Right away we understand why we need a system to make our worlds as similar as possible. So both clients must communicate with the server, and tell it where the paddle is, what is its speed, and perhaps some other information, the server in this case will communicate to both clients where the puck is, what is its speed and direction, where is your opponent’s paddle, and how it is moving, state that tells you if the puck collided and what it collided with, etc.

Now, in order to render things as synchronized as possible both clients must communicate with the server as frequently as possible, because the server is the source of truth, but at the same time there may be limitations that can cause you to not be able to receive/transmit in each frame, however the game must maintain its fluidity, so your client must be able to decide what to do when it does not receive information from the server, and then communicate to the sever what happened so it can re-sync stuff.

What happens if you get disconnected? the client should be able to determine if it lost it’s connection with the server, and have some way to get you out of the game in a way that won’t make your game crash. You might get substituted by a bot, so the other player can finish, but that is up to the server.

Now let’s complicate things a bit, imagine that somebody invented a extreme version of air hockey combined with pinball “Pinbockey!”, there might be obstacles that react to the puck when they get hit, furthermore, imagine that the placement of these things can be customized, and some players create special tables.

When this happens we will have another complication, you won’t have all possible maps in your game, the server must transmit those maps before the match starts, and your game should be able to read that information and render the map as envisioned by the level designer in reasonable time. Asides from just rendering the table, it must be able to understand what events could happen, and how do those events look and sound, all of that “protocol” should be established and the client must understand how the server will communicate the state to it, so it can render things correctly, play the appropriate sounds, etc. The main job of the client’s program is to display the world as consistently as it can to all the players, so all of them are playing the same game, and at the same time respect the physics and rules of the game in between the moments when it gets updates.

So far we have talked about a game with two players, but MMOs by definition have many players, and they could be doing things like jumping, running, engaging in conversation, interacting with the world, etc. Some of those things should be visible, and/or audible to you, each running client should create a representation of that reality which immerses each player in a single cohesive world.

Spycursion is a game with some particularities, you can hack, which means you will have devices that will connect to other devices, and that means that you will have GUIs that should react to devices, some nearby and some remote, which may at the same time be visible to other players,the client in many cases will just be a dumb terminal, or GUI and all of the things happening in this interface actually are communicated to and from the server. All of that must happen while keeping the physical world around you going, because Spycursion is also an espionage game, and people around you will be watching and hearing you and in some cases trying to gain access to your devices.

By this point you might be able to get some idea of what happens in the server and what happens in the client, the only thing I have not mentioned is that any program that is capable of showing a representation of the world that is understandable by the player could be a client for that game, so potentially several clients could be developed for a single game, and the visual appeal and performance of the client has a great deal of influence on the success of it.

I hope this was interesting to you, I tried to keep it non technical so all interested parties can get something from this post, we might revisit some of these ideas in future posts.

I hope you have fun and learn something everyday, and keep an eye on this project, which will give you an opportunity to do both,

Tag: server

How Many Lisps Do We Need?

What’s the deal with this server side and client side stuff?