So much has changed since I last blogged about making Epic Frontiers, I decided to address something that many developers have a hard time with: Server Architectures. Now, server architecture is something that is more of an IT skill than a game design skill, but with the proliferation of social gaming and online-enabled gaming in general, it’s something that designers need to be very well aware of. As a matter of discussion, I’ll talk about server architecture as it relates to one of my own projects, an MMORPG demo named Epic Frontiers.

Now, Epic Frontiers was based on a T3D server which connected to a MySQL database directly, serving all of the information to the client machine through the game server. It’s an old architecture that looks like so (I’m omitting Authentication and Master Servers because they are mainly involved only in the beginning of the game interaction cycle):

 

 

That’s a bad network design for a couple of reasons:

 

• Security: First and foremost, if that T3D server gets compromised, the hacker has a direct connection to the database, and you’re pretty much dead in the water. It’s as simple as that.
• Server Load: The T3D server is already doing so much for the game world that adding database queries to the list of things to do is asking a bit much. Throw 200 players onto a T3D server, and with all the crafting, trading, and combat, the server might start sparing a CPU cycle or two towards plotting to murder you in your sleep. Also, if you have any sort of scaling system in place, your server is probably going to take advantage of it earlier than you might want it to, translating into higher costs of running the game.
• Complexity: There’s easier ways to get your data than to assemble SQL statements using Torque Script, and mixing database calls and bugs with gameplay just means that your debugging gets that much more complex.

So, “a couple” means three to me. It actually means two, but being a programmer, I’m counting from 0, so there you go… Anyway, going by the above, there was an iteration of server architecture that solved the above issues (two and a half of them, anyway) by placing a web-server between the T3D server and the database server. What this did was make the T3D server ask a web server to fetch the data, which it then passed to the player. The network architecture looked like so:

 

It’s a more secure design, in that if a hacker got into the server running T3D, they would then need to hack into the web server, which was between the T3D server and the database server- or they could try directly for the database server, but at least the password wouldn’t be sitting inside a T3D instance, and you could enforce some very strict security rules on the database server that could force them to have to compromise the web server first or else be very creative.

Secondly, you’ve taken load off of the server by using things like TCPObject and HTTPObject to ask a web server for data, which is then fetched by that web server. T3D just uses the data whenever it comes in, and issues in grabbing that data won’t impact the entire server (unless the data relates to the operation of the entire server). So that will translate into lower operating costs over time, and higher performance of the server.

And second-and-a-halfly: Complexity. This is only a half-point, because T3D is still making all of the database calls on behalf of the player, not to mention all of the calculations for some of these things. Want to craft something? Your request goes to the T3D server, which then queries the database, and then uses that information to figure out if you’ve successfully crafted your thing, and then it notifies you. Hurray- you’ve just made T3D do something that you can offload to an app that was made specifically for the task!

Wait…what?

That’s right- what are you doing asking T3D to mediate crafting, which (depending on your gameplay mechanics, but I’m assuming your run-of-the-mill MMO crafting here) doesn’t really happen in the game world? Think about it: When a player crafts, their client plays an animation while in the background, the game server tries to figure out the crafting mechanics. That can be done either in Torque Script or in code, but either way, it’s being done by T3D, which has lots of other things to worry about, like positions of player, physics (if you’re using it), AI, etc. But crafting doesn’t have to happen within the T3D server to happen in the game, does it? I mean, we’re already having T3D ask a web-server for which items are in a player’s backpack when they click on their inventory, right? Wouldn’t it be easier to offload crafting to an application server running a crafting app which is optimized to just figure this stuff out? Can’t crafting queries be directed to that application server using TCPObjects and/or HTTPObjects in the same way that database queries can?

 

 

That network architecture would look like this:

 

 

What we’re doing here is implementing application servers that take the workload for non-realtime gameplay mechanics off of T3D’s already burdened back, and turn it into a set of queries which T3D fires off to be done, relaying the results once that’s done. As you can see, this requires a server for that application, and so in a scaling scenario, you’re probably going to scale your crafting server at a different rate than that of your T3D servers, because a single crafting server can almost certainly handle many T3D servers’ queries. And your T3D servers will run much better, and you’ll probably fit a few more players into your zones as a result.

Going further (but not by much, since it’s been mentioned several times in years past by others), you can offload your chat functions to a specific chat server (or IRC server, for that matter), and any other functionality which doesn’t need realtime feedback. Offload combat? Probably not- unless it’s some kind of turn-based mechanic which can stand waiting a second or so for the player to get a result without the AI eating him alive during that time. For Epic Frontiers, I have an NPC conversation feature that is quite logic and database intensive. Offloading that would take a huge load off of the server. The same goes for some of the AI functionality which, while relatively fast, is not always needed for realtime use (the NPCs aren’t the only things with AI in the game). Offloading it means not only does the server not have to process that itself, but also that I can devote a few more cycles to it.

That’s all the good news! Now, because I can’t be honest without doing this, here’s the bad news:

• Network Complexity: The network will be more complex as you have more servers to manage. If an application server goes down and you do not have some kind of load-balancing in place, you’re in for a world of hurt as portions of the game simply no longer work (“every time I try to craft I lose a hammer? OMGWTFBBQ!!!11!11!one1!”). So if you’re going to go down this road, you need to have both scaling and load-balancing in place to ensure that these portions of your game service run as smoothly as your T3D instances. Additional servers also means additional cost, though as a Crafting Server would likely need less resources to handle crafting queries from multiple T3D servers, this would not be as big a hit as having to spawn more T3D servers because the crafting slows them down.

 

 

• Design Complexity: Yes, I did say previously that your T3D code would be simplified because the work previously done by T3D basically gets reduced to web queries. But you can’t get anything back from those web queries unless there’s something doing something with that query and returning information- and that requires writing specialized applications that do nothing but crunch that data. Just as you can implement a Master Server using PHP, ASP, AS3, C/C++/C#, or anything else, so can you implement a Crafting Server in any of those languages (though I’d recommend a low-level language, for performance reasons). This means that changes to a query function in your Crafting Server may dictate changes to the query formation in T3D. A bug in T3D may mean changes to Crafting Server code. These two applications need to talk to each other (securely- even on the back end!), and that means you need to design them with each other in mind.

 

Now, I realize that this is quite a bit of food for thought for some of you Indies who want to make an Online (MMO or otherwise) game and already find the task daunting, but just remember that in this case, the crafting code is already needed, and the additional overhead of wrapping that code in its own application and spinning up a server for it is minimal in comparison to going further down the road and trying to wring more performance out of a server that is already doing too much.

Designers are creative people, and Indie designers have to be both creative and technical in order to be viable. Be creative with technology, leverage flexibility, and automate as much as you safely and responsibly can. And of course, the above is not at all the final word on network design for online games, and as someone who has spent 13 years in IT can tell you, network architectures are custom things. Customize your network to serve your needs!

Design, Networking, Production architecture, conversation, epic frontiers, game engine, games, mmo, mmorpg, morpg, network, npc chat, npc conversation, online, orpg, rpg, T3D, tools, Torque

Yes, you read that right: It’s quite possible that I’ve lost my knack for cool blog titles. But really, who has time for that sort of thing these days? Not me, that’s who- or isn’t who…

…anywho…

Well, 2010 was a hell of a year: Epic Frontiers didn’t progress as fast as I would have liked, but the contracting side of the house is doing pretty well. Two projects is no mean feat- not in parallel, anyway- and the fact that I can juggle those is a good sign for what is becoming my sole business.

The latter half of 2010 had me juggling both of those projects as well as 20 hours a week doing tech support. And I would still be doing it, except that after 9 months, I got laid off. That was not the economy. That was a franchise burning through its money without bringing in significant clients- but I digress. Some things are a blessing in disguise (though at times those disguises are really, really good).

And with that, 2010 is past and in the rear-view as I roll through 2011. Contracts are being fulfilled, products being made, and plans coming to fruition.

Products? Well, it’s not subtle (especially if you’re viewing this site in an IE browser- it’s getting fixed, I promise), but on your right is the new DigitalFlux store. Just the free products, as of today, but the first official DFE Terrain Pack, which had been on sale for a short while in the last incarnation of the store, will go up for sale tomorrow.

After that, other products as well, which are in the pipeline, including:

• Magnitude Editor v2: Version 1 is for sale on the Garage Games site, and it’s fantastic! One thing I wanted to do with it was to make it available both outside of the Torque engine, and also make it available for users of other products. And so v2 will be a standalone app in order to accomplish that.
• Tunnel Breaker: An inexpensive puzzle game made in TGB, you’re a miner trying to get through all the lesser gems in order to haul in the big diamond on the other end of the mine- try to make the shortest path possible to get the highest score!
• pathBlazer: An add-in editor, pathBlazer will be adding some much-needed control over the creation and modification of paths in the Torque 3D engine. It is very feature-rich now, but I’m not quite done with it yet, and it will be well worth the money once it’s released.
• A premium GUI Art Pack: You can see some of the stuff I’ve released for free in the store as a free download now, but this pack is designed from the start as professional-grade, premium GUI content.
• More terrain texture packs: Despite the three free packs and the one premium pack, I have several hundred textures looking to see the light of day. These packs will also feature normal maps to go along with the textures, in order to save you the time of having to generate them yourself.
• There will be more…

So, with the contracts, Epic Frontiers, the product line-up, and an upcoming wedding (of course it’s mine- who did you think I meant?!), this is going to be one action-packed year!

News digitalflux, digitalflux entertainment, editor, editors, epic frontiers, gui, magnitude editor, path editor, pathBlaze, terrain, texture, textures, ui

If you haven’t noticed already, we’ve rolled out a huge update to the Epic Frontiers website, based on WordPress templates which makes updating the content there soooooo much easier. Plus, the site wasn’t designed by me, so it looks ten times better

Aside from the regular site update, the Epic Frontiers Dev Blog is not to be found there as well, so please make a note of it. This blog will still make some mentions of the project, but at a much higher-level view than what I used to post. Instead, I’ll be concentrating more on technology and other news coming out of DigitalFlux Entertainment.

So, what’s new? Well, the last few weeks has begun to become very productive as I’ve finished up the first in what is probably going to be a small line of tools targeting the T3D game engine. The tool is named the Magnitude Editor, and was designed to generate datasets consisting of permutations of data (such as name generation, combinations of attributes, items in a database in which all the combinations of them need to be entered, etc) in much smaller amounts of time than what people usually have to do in order to get the information created these days.

The next tool in the pipeline- and very far along in development- is the pathBlazer tool. It streamlines adding, duplicating, setting attributes, and combining paths within T3D, as well as some in-development features such as making paths conform to terrain and/or water blocks. For anyone who has worked with paths in the Torque engines, it’s a must-have tool.

Down the line, I’ve got other enhancements and upgrades planned for T3D tools, and while I won’t get into too much detail, I’ll just say that great things are happening behind-the-scenes here at DigitalFlux…

Uncategorized dev blog, epic frontiers, tools

Michael Hartman just wrote up a fantastic blog about MMO elitism among communities. It was so good that a few rather “special” individuals showed up to trash him just for suggesting that the tired DikuMUD framework is, well… tired. I feel a bit of solidarity with him regarding this subject, since Epic Frontiers is trying to break out of the DikuMUD mold with features such as NPC conversation which requires a more delicate touch than just bashing an NPC or MOB over the head until gold and loot come flying out of its ass (oh come on, did you really think the bear had a coin purse it kept that money in?)…

So the subject of this blog, inspired by Muckbeast, is how Epic Frontiers may differ from other MMOs such as WoW and social features we’re working on in order to further improve the signal-to-noise ratio in our community…

In brief, the problem with MMO elitism is that it’s based on the fact that the design of the game segregates players from each other by level, in effect giving communities little choice but to reflect their gameplay in their social interactions. And because a high-level player is impacted by interacting with new players with stagnation, the communities of these games becomes stratified and negative towards players that attempt interacting with them and inducing “drag”.

Starting at Level 1, a new player can never hope to accompany a veteran Level 80 player on an adventure. But isn’t that the problem? Adventure means being in over your head…

The standard response is that those veteran Level 80 players don’t bother playing with noobs because they’re busy playing “End Game” content. But, why is there “End Game” content anyway? Could it be because the levelling system designed into present-day MMOs is insufficient to accurately represent a player over the intended lifespand of the game? These days, it takes a few weeks to level your character up to the max level in World of Warcraft, if you’re inclined to read through the many levelling guides posted on teh interwebs.

But then, if that is part of the problem, then how can Epic Frontiers try to minimize it? Glad you asked. There’s a few things we’ve done with the design to keep players interesting in the gameworld that will most likely help the community stay fresh (imagine sheets on a clothesline in a summer breeze):

• Firstly, we have no classes or levels, and all skills are raised upon use. And while the skills themselves have levels, the granularity of “skills” is such that characters can be highly specialized and varied.
• Owing to the skill-based nature of the game outlined above, we found that procedural content was a good tool to use in order to provide content that matches the kind of player you are. Or, put another way, it is simply impossible to handwrite quests for every combination of character you have, but we are putting technology in place that can deliver the same quality of questing across a broader spectrum of character types.
• In addition, we’ve deepend the crafting features and added a fast and unique NPC conversation system that also lends itself to the quest generation technology in a way that not only gives the player vast amounts of fresh content, but also delivers a much broader spetrum of gameplay. Now we can have quests of a social nature that involve NPCs at a level you haven’t seen before. This kind of thing naturally allows the player to slide into character and out of the temptation to act out (after all, the NPCs will remember your general personality at a more detailed level than just reputation).
• We’ve improved AI for the NPCs and based it on personality traits. Extending that, the NPCs will also be looking at the players in like fashion, and if the player acts like a moron, he will likely be remembered and treated as such. The NPC will remember what you’ve talked about, how it made them feel, and that influences further help or hinderance you receive from them. The world is much more consequential than the usual MMO, and we think that the players will more naturally align their attitudes with that kind of gameplay (that said, we know it’s not a perfect answer, because there is no perfect answer for the problem).
• Beyond game features themselves, we’re keen on integrating social features into the MMO that bring social networking tools into the hands of the players. This doesn’t mean tweens with MySpace pages invading the game, but character pages with social functions that help the players to play together, bond, communicate, and have fun without taking the focus away from the gameworld. These features of course come with the standard reporting tools on both the web-facing part of the game and extending into the game world itself, to help curb inappropriate behavior (racial/sexual harrassment, etc).

Again, this design is not foolproof, and the “funness” of the game comes first, but the design as we have it should enable high-level and low-level players as well as social- and combat-oriented players to not only coexist, but mingle freely. Because crafters can concentrate on crafting rather than grinding combat quests to gain XP, they can more easily fulfill their role in the world while those who wish to be pure combat are not required to choose a profession or secondary class (or even primary class, for that matter). And likewise, the skill-based system supports the Jack Of All Trades types that will inevitably emerge.

Mixed parties of veteran/new players with combat, crafting, and mixed characters are encouraged by the varied gameplay requirements, making a more adventurous and tolerant environment, and less of a game where high-level players are impacted negatively by interacting with new players and thus act negatively (or neutrally) to them.

Hopefully, our feature set will result in a better community than has been exhibited by other games at certain times (and the asshats who have inspired these blogs are certainly not representative of everyone who plays MMOs, or else we wouldn’t be bothering to develop them!), and I think that Mike is right on target with his blog. The subject of communities needs much more attention as more gamers migrate onto internet-based games, and frank exploration of the game designs that influence behavior is long overdue.

Uncategorized ai, community, dikumud, epic frontiers, Greater Internet Fuckwad Theory, mud