Blog for Jason Lee at GarageGames.com

Team Construction - as tough as making the game...

Jason Lee — 2007-07-05T15:23:03+00:00

In a team construction environment, building the membership, organizing and fulfilling the needs of the team as a whole can be as troublesome as building, marketing, distribution of the game. As an indie game developer this is the downfall of most projects, large and small. Less then stellar motivation, lack of experience, loss of focus and a plethora of daily responsibilities are the main killers of game design. Some of the factors for success in this area include:

1) understanding managers: having team leaders is excellent, but having team leaders early on is a challenge. Finding the right person to fit the mold that allows for the average struggle of team members and participation make this decision a hard nut to crack.

2) recruitment avenues: having access to large groups of like minded people is imperative. It's not enough to plan out every aspect of a games design and just pick up a piece of art or code here and there. It is absolutely vital that you have a focused team to give the overall vision and development cycle a life of it's own. This factor alone, even if a game gets "completed" makes or breaks it when it's released. Having random art, odd contrasts and unorganized vision, no matter how well implemented, makes a release hardly worth the time it took to create.

3)moola: given the above aspects of gather team talents and providing motivation for a well-created game, this hidden cost of development falls under team compensation. You can have all the best hardware and software along with the greatest game design imaginable, but if your team can't be motivated enough financially, you're in for a struggle.

People often wonder why there are so many ideas out there for games that just don't get made, or can't seem to get off the ground, given these factors, it's not impossible to see how they fail miserably. Even in some of the companies that build games on a regular basis struggle with these issues, so when you play a game, your also feeling the results of hardships during development. Some of the main things you don't like about a game really hinge on it's development organization and implementation, over and above the way it plays.

MMORPG - Server Architecture New Expectations for Indies

Jason Lee — 2007-05-23T17:02:42+00:00

In the continued pursuit to find and implement resources for the every growing field of MMORPG designs, i've researched and planned out many variables, the most pronounced being server technology. This includes software combined with hardware resources that can offer the best bang for the buck. The most obvious choice for security and scalability i have found is most obviously the Linux platform. Here i want to address specifics about why Linux is not only the best choice for an indie, but is also the most cost affective solution as well.

Open-source...
Obviously open source provides for much cheaper systems from a software standpoint. That lower cost makes up for most indie developers lack of knowledge or even desire to work with Linux and it's less user friendly interface. Windows and to some extent Mac OSX domination of the market for client based systems is staggering, which offers the highest level of possible player bases. This however by no means limits your server choices. A Linux box can certainly service any platform available given the correct set-up. Open source products are available in abundance and it the slow migration to more open information shares is a practically vital resource for indies that wish to offer an MMO.

Options, options, options...
What i'm going to cover here is limited, but there are pratically hundreds of viable options that any MMO designer should look into with full force. These alternatives are usually modular in nature and have fairly high learning curves, yet many of them offer secure peer-peer/client-server hybrid technologies that can uber expand even the best hardware/software singleton or sharded systems.

Singelton verses Sharded
Singleton mechanics are like a world gone segmented but in a fluent single server feel. Sharded mechanics are multiple "sharded" servers running duplicated instances of the world. An example of sharded architectures is a game like World of Warcraft where the client logs in to one shard for every connection, typically these server shards handle around 3000 clients and those clients all share one instance of the world, closed off from other server shards. The Singleton mechanic offers a fluid persistent world where every feels as though they are on one shared world. Capable of switching between zones to meet fellow players games like Guild Wars and EVE are run in this manner. If this seems confusing to you, it's simply because the architecture isn't much different. Singleton splits the world up into zones, each area being capable of handling around 100 or so clients in a given range, but allowing those clients the freedom to transfer seamlessly from zone to zone. Sharded offers one persistent world, but limits the amount of clients that can create account on that shard. This doesn't allow as much freedom to simply zone to your buddy that resides on a separate server shard.

Both have there advantages and both can offer the alter mechanism through code changes and server designs. So in the beginning of designing your game, giving consideration to the outcome is pretty vital, but not earth shattering if you choose to go either route. There is however some *new* trends/techs we will most likely see in some of the newer releases of MMORPGs. One specifcally of interest to indies is a dynamic layered peer structure, the other and still a viable option for indies (except more costly in hardware capital) is a hybridSS.

Dynamic Layered Peer (DLP) and HybridSS
Although searching the web for either of these will yield less then stellar results, these architectures are however being considered as very viable solutions. The DLP system offers very small amount of upfront server setup. The front end is Almost entirely setup to handle largely populated areas, offer master database structure and offer randomly generated keys for hashing among peers. In this system the larger amount of processing overhead is handle at the client, relying only authoritative data to the master server nodes. Each peer can be setup to handle zones of there own location in game or handle random zone processing, it can also be setup to split up proccesses among multiple areas in game where whenever there are free processing ticks available among any client that data is shuffled then processed, this makes every client a server. This obviously bring to mind security issues, but since it's a joint layered load system, it makes it extremely difficult, if not utterly impossible with key encoding, for a client to access the process thread it's handling or even know who or what it might affect if they could find it. PArt of the reason we don't see this currently is it's complicated and a bit more difficult to manage.

The HybridSS offers the client zoning transparency with a "regional server" front end. This means at any given time you are on a region server, but can easily interact with other region servers dynamically. It's fairly simple to implement and given the popularity of the 2 structures but has the advantage of singleton worlds using definite sharded servers speaking to each other allowing players easy interaction, but also offering structure for competition on a regional level. An example of this sort of system would provide each player to link their account to a server in say the Utah region, giving GM's or OP's the ability to manage local resources and players the ability to form localized groups in their communities of player base. Guilds could however operate in the same manner as sington server systems, where any person from any region could join up with any other, but instead of clients being shuffled between server loads, each player is always regional. Much in the same sense that a server cluster runs now, processor load sharing/balancing can be performed across regional servers where localized machines can reach out for spare processor time on less heavy loaded region servers.

For Neophagia, I'm planning the HybridSS model. It gives players the most freedom, but in a more organized manner. It also allows the scalability options i think suite mmos the best, but I'm keeing an eye out on the DLP tech, since it could offer the best price performance of any mmo out there today. Now how to make it happen!

Two Powerfully Simple Solutions
For me and the research i've done thus far, there are really only 2 options. One is Python and the other (which is seriously leaning toward now is Erlang. Python is used in just about every mmokit out there right now. It's a powerful solution to server scripting technology, but unless you're interested in running all the modules using several different software solutions, erlang offers what i would say to be a more simplified full service solution, taken directly from the faq "Erlang is a general-purpose programming language and runtime environment. Erlang has built-in support for concurrency, distribution and fault tolerance." Basically, it's build from ground up to handle database, server loads, potability and fault tolerance all in one. Although there is far more documentation on how to work python into Torque, i feel ultimately Erlang is going to give the project the best possible handle on server load, redundancy, security and distribution. There are just too many tools built right in!

Our MMORPG project

Jason Lee — 2007-04-14T18:27:10+00:00

Yes, an mmorpg! Yet another project to develop the next big hit in the genre. I was thinking today about what makes our project different then the now many titles either being produced or now released onto the gaming world? I also thought about many of the key elements to the design that would make this game really stand out. So heres some basics for anyone to grab hold of when creating an mmorpg, which i think are pretty key to it's success...

Making it real:

Players really need to feel *part* of the game, not unlike life as we know it, players need to feel they are really making a difference in the game as a whole. This is probably the most difficult aspect of game development to date. Most games feel very "out-there" with plot lines that don't make sense, ideas that are worn out and epic battles that fizzle. These, along with limited communications amongst players make many mmorpgs feel fake, stale and downright cumbersome. "Let's Farm" seems to be the growing theme of mmo's and as a designer, making the feel of these task seem less "task-full" is a major priority.

Building the team:

So many games don't have much heart. The designers are distant, the corporate world gives off bad vibes and dis-concern once the project is complete, which leads to an explosive start and limited longevity for the mmo. Many recently have been plagued with incomplete storylines, dead end questing and a very high level of other shortcomings. The key here is in the team, the artists, modelers, coders and overall team build MUST be fully vested in building the game they want to see played. Not to much unlike that great relationship in your life, your teams has to be there, they have to sing in unison the song of the game. That may sound cheesy but it's a sad fact that games that are missing that heart, no matter how technically great the may seem, they feel shallow without the team enthusiasm.

Project leads:

Key to a great gaming model is to have your project leads mesh well. they need to have a good feel of the game overall, it's goals it's strengths and weaknesses and really need to *let the game become*. Stringent deadlines and strict carved in stone ideas only foster a very linear project. Leads and flexibilty, tagged along with motivation can keep your project going in the best possible direction.

Notice that I'm not really talking about the engine or the technicals of game development, like db's or character progression. If you've ever fully enjoyed a text based rpg or many of those really simple games that don't really appeal totally to your senses, then you know all about the heart of the development team and what it means to unite in a group vision of that one game that people really enjoy!