Tag: application server
Alright!… so now we’re close to having a somewhat functional product. In that, we will have something that can accept connections and have some interactivity between those connections.
We talked about architecture, interthread communications, and network code. Now, let’s integrate a script language. The script language is going to be responsible for the game logic — basically, anything we want to be able to change really easily. For this example, we’ll use Python because it is very easy to integrate. (continue reading…)
So now we’ve done a basic design overview, and we’ve gone over our interthread communication. It’s time to dig into some net code. As a bit of forewarning, this net code only works on UNIX variants; it should compile cleanly on Linux or Solaris. Windows net code is actually quite similar; replace most of the #include’s with “#include <winsock.h>” and then add the Windows-specific bootstrapping.
If there is a demand for it, I’ll do the port myself at some point. The Windows threads are a different matter; my understanding is that those operate somewhat differently from POSIX threads, but it is no doubt fairly easy to do. If you are unfamiliar with network programming, I highly recommend Beej’s Guide. One of the few programming books I’ve ever bought is his; you should buy his book too! This guide assumes you know what a socket is, and can handle words like “descriptor” and “port”.
It’s been a busy week! But we’re back at building a game application server. See part 1 of the series if you need to catch up.
So … Let’s start off building a glorified chat server, something you could build a MUD or MUCK off of. Adding tile graphics or whatever you may like is really just an extension of that, and if there’s interest I can show how that’s done as well. By aiming for a lower goal, though, we’ll get a good short-term accomplishment. (continue reading…)
So … as promised in my last post, I’m going to start a series of “how to build your game application server”. The first step is to figure out, in general what you want to make. Then, the next step is to get a sense of your architecture. How are your components going to fit together and communicate with each-other? What interpreted language will you use, and what underlying “lower level” language will you use to support it
For this series of examples, I’m going to take you through building a multiplayer server which would be suitable for running a MUD/MUCK or a multi-player tile based game like EUO or Shattered Moon’s Ultima IV multiplayer.
To change gears from my last post, let’s talk about some game software design. The purpose of this article is to sort of underscore a certain way of thinking about software design; this probably won’t come as news to some of you, but for those of us who have been writing games since the DOS era it might get some gears turning.
When “application server” is said, what probably comes to mind in most developer’s heads is one of the following: web server, java application server (Tomcat, jBoss,etc.), or something similarly boring and business-related.