Blindly Coding (Posts about MMO)

My Thoughts on The Essential Shape of Games Part 2: Quantifying the Problem For MMOs

Austin Hicks — Wed, 16 Jul 2014 12:00:00 GMT

NOTE: this is old, and I no longer stand by the design in these posts for a variety of reasons.

In part 1 of this series, I gave a proposal for what a framework for implementing most types of games might look like. In that post, I promised a part 2 in which I attempt to quantify the size of MMOs in terms of the framework. Here it is.

My Thoughts on The Essential Shape of Games Part 1: What is the Essential Shape of a Game?

Austin Hicks — Tue, 01 Jul 2014 17:30:00 GMT

NOTE: this is old, and I no longer stand by the design in these posts for a variety of reasons.

My quest for an MMO is leading me down all sorts of interesting avenues, most recently Libaudioverse and self-taught digital signal processing. While Libaudioverse is my top priority project at the moment, I am still devoting a non-negligible amount of thought to some core issues with game programming.

One of these is how one might go about making a game system that has three essential properties: network friendliness, developer friendliness, and flexibility. Spurred on by a design pattern called the Entity Component System, my brain began to generate ideas specifically aimed at MMOs, and for a while it seemed that an Entity Component System was the silver bullet. But I no longer think it is, at least not by itself.

And I wasn't even asking the right question. The question I should have been asking is this: leaving aside network issues for the moment, is there some structure that seems to encapsulate most or all games? The answer seems to be possibly, but I have yet to implement it.

Herein I share my thoughts on what the structure might be. Part 2 defines the problem in terms of an MMO and part 3 will talk about the options for actually getting this up and running. But first, we need to define the structure.

Building an online MMO Part 3: Teleportation and Refactoring

Austin Hicks — Sun, 16 Mar 2014 12:53:00 GMT

This is the 3rd part in my series on building an MMO, and it is no longer just an architecture. Basic game functionality has now been implemented: incredibly boring combat, the ability to walk between locations, and the ability to have persistent maps. Progress has slowed down, and these posts will consequently begin growing shorter and more broad.

Building an online MMO Part 2: Steps Towards a Functional Game, and a Forray Into Alternatives

Austin Hicks — Tue, 04 Mar 2014 21:45:00 GMT

This is the second part of my series on my attempts at an MMO architecture. I have an incredibly basic working game at this point, though it does have problems which I believe to be solveable. The entire program, both client and server, is currently 897 lines. I am going to outline the basic components below. I will also talk about my adventures with Unity3D, Unreal Developer's Kit, and a few other products. As always, this is a description of the current state of things. I may come back in part 3 and say I had to throw it all out, but at least there is something to learn from knowing that it didn't work.

Building an online MMO Part 1: the First Attempts and Why they Failed

Austin Hicks — Sun, 02 Mar 2014 15:56:00 GMT

Those watching me on Twitter are no doubt aware that I've been working on something. Last weekend was quite frankly the most productive I've ever had, and the net result was the very lowest level components of an online game. I have since taken it further, and stand at working terrain as of this posting.

I have decided that I will blog my progress, along with notes and information on the architecture as it develops. This means that I will no doubt have to say what changed, but I will of course post why it didn't work or what I gain from the new model. It is amazing how little information exists on this subject: there are some tutorials on making basic board games and sporatic information on how a real online MMO works, but nothing complete. I have worked a lot of this out myself or brainstorming with fellow developers, and very little of it by reading tutorials. The intent is that this will be an ongoing series, for as long as I maintain interest in writing it. Rather than jump straight in and say what I have currently, I want to start with my first two attempts and why they failed. I think this is important if only to provide some background. It also taught me why I shouldn't do certain things. It also taught me how to use Gevent, and succeeded in convincing me that Gevent is the right path.

Note that Christopher Toth (@mongoose_q on Twitter) is a co-programmer, but I've done 90% or more of the programming thus far. His advice and thoughts have been extremely hellpfull, and I can't take sole credit for my current success (but in all honesty I can take credit for my failures).

This is quite lengthy.