DigitalFlux Entertainment

Thoughts on Level-based zones in MMORPGs

July 30th, 2013
Comments Off

I had a thought the other day about MMOs and how new player do not get a chance to roam the game world like a high-level player does. It seems obvious that the reason is that a Level 1 player walking into a Level 50 zone would obviously be dead meat (obviously), but the truth is a very different matter, and as it relates to MMOs who, more and more, aim for the mythical “sandbox” gameplay, it’s something that designers should think about.

Consider below, a map of Lord of the Rings Online with the player levels listed for the zones:

Zone map for Lord of the Rings Online

When you look at this, you see some obvious things, such as the players starting in areas that, in the books, were understood to be (initially) far away from the fighting, with higher-level content further away, in areas relevant to the fighting in the book. This is all well and good, especially for an MMO based on classes and levels and looking to guide players through the content, and it works well enough for these kinds of MMOs.

For a sandbox MMO, however, this may not be the optimal layout of content.

When we talk about “sandbox” MMOs, we generally mean MMOs that aim to give players a much greater amount of freedom. Some of these are still class- and level-based, some are skill-based, and some have unique rulesets (and are usually niche games with small populations). In any event, we’re focusing on the design wanting to give more freedom to the player, yet staging content in such a way that new players do not have the freedom to roam without having to “level up” or “skill up” before entering certain areas.

But that’s how it should be, right? Well…not really.

Think of the world as it actually is in Lord of the Rings: Before the actual war breaks out, Frodo and the hobbits can actually travel freely to Bree- their sole limitation in doing so, and the reason why they tramped through the backwoods to get there, is that the Black Riders are looking for the ring in Frodo’s possession. That’s it. Bree isn’t under siege, and they’re not sneaking through enemy lines to get to it. They themselves are being hunted, and so everyone else in Bree can come and go as they please. Level 1′s included. Black Riders included!

You can say that the same is true for the town near the Lonely Mountain, years after the defeat of Smaug and the resettling by the dwarves. As a matter of fact, you can say this of every town that is not in the middle of burning itself down. Towns are havens for those of the same faction, and being such, they represent islands of relative safety amid dangerous territory- dangerous territory that sometimes is a lot closer than entire zones away.

Of course, that’s how it is in MMOs now: Low-level zones consist of completely low-level content, to the point where in Guild Wars 2, they instituted a level-scaling mechanism to lower high-level players’ levels so that they still found challenge in lower-level zones. They could have just included some high-level content in each zone, since Level 1 players usually get indicators regarding the dire-bunnies that can kill you outright. Or, more accurately, Level 80 mosquitos

All your blood is belong to me…

This leads to a second issue: Quests. If, in a Level 1 zone, you are regaled with tales of the big, bad Level 5 wizard that you need to defeat, only to level up and move into the next zone where you need to defeat the big, bad Level 10 bandit king… Are they really that big and bad in the first area? Is anything?

However, if level content were mixed throughout the game world, this would change the dynamic dramatically, freeing players in their ability to travel and explore in addition to the other features you look to implement for the “sandbox”.

Your higher-level players would have reasons to come back to the zones that they started in, and lower-level players would have reason to mix with them in ways that do not involve them holding the other players back. There’s content for each of them. The low level players can run interference against the minions while the high-level player engages the Level 65 wizard.

Secondly, your quests don’t seem as if the big, bad wizard in the starting zone is a yawn anymore. Low-level players get a more real sense of danger nearing certain areas in the zone, instead of just merrily chopping their way through and making sure to heal after every X monsters they mow down. And the content in the lower-level zones are no longer completely irrelevant to higher-level players.

And while it’s true that you could still implement level-scaling, as was done in Guild Wars 2, you might find it unnecessary, or find a different way to implement it to get even more life out of your content.

Has it been that long?

July 29th, 2013
Comments Off

I took a look at my site the other day while doing some routine updates, and realized that I haven’t blogged since 2011. Holy. Crap.

Obviously, that’s too long a time, but I have excuses! Yeah, no. Not really. Not at all, actually…

Over the past two years, I’ve been doing some contract work, mostly with WillPwn4Food on their flagship product, DodgeBots. Also, I’ve been evolving my understanding of MMORPGs and gameplay in general, along with more ideas on NPC AI, what my “ultimate” MMO would be like, and more of that kind of stuff.

With that said, I have a few blog posts to sling out over the next few days, weeks and months, and a few bigger things that I hope to get out the door as well.

So, apologies to my probably-non-existent-by-now audience for taking so long to blog, and keep an eye out for more posts!

</facepalm>

Online Games Network Architecture

September 22nd, 2011
Comments Off

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):

 

Basic Network Architecture

So basic that it's not secure...

 

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:

 

Network Diagram 2

Better, but still very basic...

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?

 

You Betcha!

You Betcha!

 

That network architecture would look like this:

 

Network Diagram 3

More robust architectures are...more robust...

 

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.
Network Diagram 4

You can expand these techniques out to design the network how you need so that it performs well...

 

 

  • 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!

, , , , , , , , , , , , , , , ,

I must be getting old…

March 26th, 2011
Comments Off

I realize that I don’t blog nearly as much as I used to. I’m not going to lie and say that I’m going to change that- things are busy!

Firstly, I’m learning a huge amount lately on the recent shift from working solely on my own projects to contracting. It’s something that’s been slowly occurring over the past 10 months, and previously, I did not see myself getting any enjoyment out of working on someone else’s project, under their rules, for their visions.

And I was wrong…

Most likely, what burned me on working for other’s projects in the past was the experiences I had in working on close to a dozen indie projects that never got past the team devolving into immature back-and-forths that usually doomed the team (one of the reasons why I wrote this thread on Garage Games). And let’s not start on working in the IT field- there’s two reasons why IT has one of the highest rates of substance abuse: Bosses, and users. I’d mention vendors, but after a certain trip to Atlantic City in a limo where I almost walked out $2500 richer from the tables (don’t switch dealers when you’re up), I think I’ll let them slide…

It was like this, except without the girls, long hair, cigar...or winnings...

So what happened? Well, I took a contract. I did it for the money, really, and reluctantly, because I was neck-deep in Epic Frontiers and started as an advisor to help get a fellow Indie off the ground. It turned into a year-plus contract that continues now, and helped me cut my teeth on negotiating, dealing with clients, and working on a contract that was far from the kind of games that I envisioned myself working on. But as the project takes shape, you still look at that and say “wow, I did that”. I also got to farm some work out to my Epic Frontiers team for various art and web back-end tasks, which is always nice, especially since they did such great work on my own project.

Some time later I picked up a second client and proceeded to level up my skills on a game that threw a good number of curveballs at me. I learned about stress, crunching for weeks on end until my body literally caved in and got so sick that I couldn’t work at all for two days (says something about crunch-time, even when self-imposed), and how to better estimate time on contracts. I also learned a lot about the Torque 3D engine, especially on the network side, where I basically gutted out the unnecessary parts like Predator.

Pictured above: Network optimization.

So, after a few months, the part-time IT work that I was doing dried up and I was laid off. Three days before Christmas…

Ted, you're job security is what we like to call "fra-gee-lay"...

At that point, I figured it was time and went full time into game development contracting, which is where I’m at now. I work every day (6-7 days a week) out of my home office, and I’m pulling in just enough money to not miss bills. I feel less stressed on most days, and my wife (and I) think that I’m much happier doing what I love.

So what’s next? More work.

Having made the transition, the goal now is to secure my footing by getting contract work done as well as producing more products, both for Torque and for the wider game development community. And some of the tasks on my table look like this:

  • Ongoing contract work
  • Products (Magnitude Editor, Path Blazer, GUI Packs, Texture Packs, etc)
  • Learning Actionscript, Flex, PHP, and making some forays into Flash-land
  • More contract and product work

With the Magnitude Editor released last year, I’m working on an update that ports it over to Adobe AIR for greater flexibility in where it’s used, for those who don’t want to buy engine licenses for those on their team who just enter data, and also to reach past just the Torque engine market. And for those who have purchased the original, they will find this version as a free upgrade.

There are some other tools that I have in mind, but foremost right now is a tool for the Torque engines named Path Blazer, with the following features:

  • Easy creation of path nodes by extrapolating the current direction of the path, allowing for a single click to produce a point at or near where you want it to be
  • Duplicating paths to the left, right, above, or below the selected path
  • Path “lathing”. More on this later…
  • Re-numbering paths, making it easier to take out nodes from arbitrary areas and retain consistent node ordering
  • Setting attributes for every node in a path
  • And more…

2010 in the rear-view, driving through 2011…

January 21st, 2011
Comments Off

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!

, , , , , , , , , , , ,

Epic Frontiers update, tools, and more!

May 27th, 2010
Comments Off

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…

, ,

Post GDC: Going Social… Going Alpha…

April 6th, 2010
Comments Off

Things are hectic here- I like how this feels…

GDC was a blast! Had some promising business meetings and talks and did the yearly interview with Torque Powered, in whose booth I demoed the latest version of Epic Frontiers. Kudos to Eric Preisz for the new GDC booth set up and putting in the “Community Pit” with such a comfy couch (honestly, because when you’re on your feet and talking all day and night at a convention like GDC, such things are just awesome). And kudos to Michael Perry for whipping up a series of interviews with myself and other Indie developers in the midst of so much convention center chaos :)

Another development coming out of GDC will be that we’re nearing in on a closed Alpha for Epic Frontiers, to be opened to members of the Torque Powered community. Having your game QA’ed early on by fellow Indies is a great idea, and we’re hoping to stomp a lot of bugs with both operation and gameplay in order to bring a better gameplay experience to our customers.  We’re aiming at an April (yes, sometime this month) opening of this.

On the web front, we realize that the website for Epic Frontiers could be a bit more spiffy, so we’re currently having the website redesigned- and not by me… We’ve pretty much settled on a clean, basic design that should be easy to navigate, and easy to update as well, so as we get more content, we can post it right up instead of going through more archaic web-update processes that we’ve been stuck with. This Dev Blog will remain, and we’re going to be adding some social features to the site as well, which brings me to my next point…

The Epic Frontiers Facebook page is now up and running! We’ve got our Dev Blog updating there, as well as photos and videos (coming soon!), so you can keep track of Epic Frontiers from your Facebook page anywhere in the world. And if you’ve got a mobile phone, you can now follow our updates to that page on Twitter as well!

Those are all the updates for today, but we’ll be back with more exciting news soon!

Candy for your eyeballs…

February 9th, 2010
Comments Off

Yeah, I’m well beyond apologizing for not updating the website as much as it should be- priorities, people! But I figured it was time to blog and show off some screenshots of what’s going on in the development of Epic Frontiers…

For starters, a demo was hosted in November and December, to generally positive feedback from the interested parties who participated. Being conservative with a team that is new, they’re holding off for a larger slice of the world to play in, which we’re happy to oblige with. This is normal business stuff, and I can’t go into any more detail than that, but in the meantime, there are plenty of other details we can go into:

Early demo tent city inside Ris'Hebbik

Early demo tent city inside Ris'Hebbik

As you can see, our art style is coming along very nicely, and even in this older shot you can see a few of the new style icons replacing my own stick-figure placeholders. The scene is an early layout for the caravan tents that occupy several corners of the old city of Ris’Hebbik, holding items for sale from all over the planet of Chi’Hamak, not to mention elsewhere.

Ris'Hebbik

Early layout for Ris'Hebbik

With the demo, we created not only a small portion of the game, but we chose an area that would be very hard on our team- one of the cities. Development-wise, this is a baptism by fire, a stress test of our team’s ability to accomplish big things. Because, let’s face it, an MMO is a big thing!

We hit some crunch, as evidenced in my last blog, and that lasted for a few weeks, along with intensive meetings and work, and we were able to host the small zone for play, resulting in the second paragraph of this here blog. While we awaited that feedback, we relaxed a bit, since the holidays were upon us, and we applied lessons learned from that battle so that our asset pipeline was easier on us moving forward. Off the top of my head, we had close to a dozen changes to the way we approached the art pipeline across every discipline, from concept, modeling, texturing, animation, all the way through to placing those assets in the game. There were also loads of lessons learned on the development end in regards to database work, the server, coordinating meetings and people, and so on, etc.

But in the end, it was worth it and we had a demo that, while not as great as we could have ever hoped (I think every developer has that moment when putting something out the door for a deadline: “wish I had enough time to do more with XYZ”), was enough to get noticed and let us know that we’re not the only ones that think we’re on to something.

So, where are we now? Here’s a quick shot of some terrain painting for the Ris’Hebbik zone:

Ris'Hebbik in the distance

The city of Ris'Hebbik in the distance...

The zones are approximately 2km x 2km each, which makes for a huge amount of terrain to cover in the game- not to mention populate, but those are some of the lessons we’ve learned during the demo. The areas pictured above are mossy, rocky hills surrounding Ris’Hebbik used by local farmers to graze their shank goats (when not being run off by the larger and less mild-mannered Bony Chargers).

The next Epic Frontiers blog will cover our particular zoning functionality and show off the new Ris’Hebbik layout, as well as some development shots of the neighboring zones. Stay tuned!

Crunchy demos

October 30th, 2009
Comments Off

It’s been a long time- I don’t even know where to start, so we’ll do this in a categorized rather than chronological order…

The Demo: My last blog was posted a day before my birthday, on September 19th, and during that time, I’ve accrued a team of very talented and dedicated guys and girls who are putting equally nice artwork into the game. Using contacts that I made at Austin GDC, I’m also able to bring motion-capture animation into the game through Mixamo. Having met a really good concept artist in Austin, I was also able to create and distribute a thousand fliers at VGXPO in Philly three weeks ago, bringing in a modest bump in web traffic. This effort will be replicated for the various Comic Cons that roll through New York next year, each one bringing in thousands of people (as opposed to VGXPO which brought in maybe one or two thousand in total).

At the same time, I’ve moved the database to a test server- an XP machine that sits on my desktop and does nothing else, except maybe drip liquid coolant onto the RAID array now and then (that reminds me, I need a CPU fan). We’ve had team members from as far away as Ireland log into the game and test while, ironically, one of our guys just 50 blocks south of me in Brooklyn wasn’t able to get on. This allowed me to crush a bunch of bugs that popped up only under online conditions.

Next, we’ve started moving the behavioral AI into the game and testing that, which continues today. We have the beginnings of a rotating overhead mini-map (not ready as a resource yet), and we’ve almost solved the mouselook-and-select-objects issues that dog many people (that is also not yet ready as a resource- it’s kind of spongy right now). Drag and drop functionality is back in and we’ll be adding some crafting recipes and materials this week coming up, and mission generation is also coming online.

And finally… Outsourcing. Because of the time-crunch and the failure to get as many 3D artists as I would have liked, I’ve resorted to outsourcing some tasks. It’s not because I have deep pockets, but because the demo tasks need to get done. In any event, I have some advice for would-be outsourcing/contracting people reading this: Don’t promise anything you don’t know how to deliver. I’m not about to mention names, because mistakes become past mistakes quickly and though I wound up canning the contractor, it doesn’t mean their work doesn’t get better. In fact, the modeling and texturing was done very well, but the client doesn’t need to hear about your internal problems. Be a black box for me, would you? Thanks.

So, we’re in the final two-week-stretch here, and I’m starting to work from about 9am to about 1am every night, with a few hours dedicated to my girlfriend most nights, but otherwise huddled over the laptop beating my head against walls until they crumble. And far from technical, I need to work on budgets and project timelines for the prospective publisher as well- they do like to know how much money and time a project will cost them. If any of you wannabe MMO creators out there hate business, then you better learn to love it, and fast, too.

AI: What can I say? Interrogative is no more. In fact, it is more. Having started to morph from a feature for the MMO into something that can be used generically for games, into something that I’m intending to throw at the Turing Test competition, and even beyond (shhhh), the name Interrogative is no longer proper. Hierarchical opinion-based knowledge representation systems using generalized pre-compiled dialog along with dynamically-created dialog with interrogative and natural language processing front-ends is no longer what Interrogative is or was. It’s not even tested yet, but the theories are there, and having run it past a number of industry heavies, I can confidently say that I’m on the right track with my experiments.

At the lower level of things, Interrogative is alive and well in Epic Frontiers, and we have about a dozen new conversation keywords and dialog sets to throw into the system for testing. After that, proper changes will be made to support the Infidel opinion-based architecture we want to implement, which will allow the game to support the players changing the minds of AI, as well as AI reactions to players and other AI who do not share their own opinions (hence the name Infidel, which means “non-believer” and can be applied to anyone who does not share your belief in whatever subject you feel passionately about).

With all this AI tech springing to mind, I’m thinking about spinning off a company to hold all that technology, so that I can continue to develop it without interference from video game contracts and such…

GameX Summit: Well, the last conference I attended for the year was just great! Met up with Dave Mark, Mike Worth, and many others and had a great time. For a first-time summit, the mistakes were minor, and the recovery from them pretty swift.

Unfortunately for me, the students that showed up were almost all design students, and not artists, as I was hoping, for recruitment sake. That said, I also met a lot more people interested in AI, and attended a couple of mind-blowing sessions by people such as Clint Hocking, Dave Mark and Kevin Dill, Damian Isla, and Mike Worth, whose audio session simply rocked.

The only real downside to the conference was getting lost. I don’t know what it is about the Pennsylvania hillside, but I’ll be damned if I didn’t wind up in the Valley Forge National Park at 11:30pm one night staring at over twenty deer in my headlights. And it wasn’t that “ZOMG what kind of car is that” stare, but the “dude, this park belongs to us after dark” stare… Interesting area. But the food out there is pretty good.

That’s about it for the blog for now. The next blog will have more eye-candy ;)

, , , , , , , , , , , , , , , ,

Killing Noob

August 14th, 2009

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.

, , , , ,