Posts by Cheetah(Steve has been developing games ever since he could first type in BASIC commands into his Commodore 64 at age 5. He really cut his teeth working on tinkering CircleMUD "back in the day" which is how he learned the ins and outs of C and network programming. Still an active game developer, he now spends time doing web development, playing games (mostly RPG's) and generally being a technological tinkerer. He also enjoys writing about himself in the third person.)
It’s been awhile since I’ve posted; I’ve literally had no time to play as it turns out! But as things have settled down, I’ve had a little more time. Mostly occupied with my web comic (warning: blatant plug).
Anyway! I had a lot of fun with a game last night, and I wanted to share it.
Good Old Games (GOG.com) has released the first and second trilogies of the Ultima series. This is significant because for many people, Ultima was their first delve into computer RPG’s. Not only that, but the Ultimas for better or worse have shaped all the RPGs that have followed it.
Some things that are staples today in what is considered an “expansive world” (like the ability to cook, or NPC schedules) started or at least became popular in the Ultima games. And Richard “Lord British” Garriott, creator of Ultima, is a model for many developers who would like to strike it big in the world of game development starting from nothing but lines of code and a PC.
So, whatever your opinion of Ultima, it has a lot of historical significance. And so I bought the two trilogies on GOG.com and started playing through them. This article is going through the ones I have played, comparing my recollections of the games with my actual playthroughs and noting things that are interesting in each title.
So I’ve been playing Bastion lately (By Super Giant Games and available on Steam), and this is interesting for a couple of reasons. The biggest reason is that it’s an “Action RPG” and that’s a genre I don’t play anymore, and yet I’m playing this game.
What’s so bad about Action RPGs? Well, I find its kind of a tired genre. I’m talking about games like Diablo or Torchlight; real time games where your primary action is clicking at hoards of monsters. This is distinct from Roguelikes which, generally speaking, are turn based and more “tactical” in a lot of ways. Action RPGs are sort of repetitive stress disorder games, where you pick the best weapon or spell and “spam” it until everything is dead. (continue reading…)
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.
Hello, ladies and gentlemen;
Felix has been kind enough to give me permission to
make a mess of post on this site, so in the proud tradition of programmers everywhere: Hello, world!
Let me warn you; the first part of this is going to read a little bit like a rant, but I promise it gets constructive. And I’m not ranting against things I hate, I’m ranting about things I wish could be better. Things, in fact, that I love. To my mind, this is vital for game developers to see; we, as a collective, need to always learn and strive to make better products. We need to learn from the good and from the bad, and always play with an open mind.