[网络] MMO游戏制作前期准备及思路

3D Buzz’s latest training project involves documenting the development of a massively multiplayer online (MMO) game to create an online class over the subject. Over the past six months, the 3D Buzz team has been in development of a technical demonstration for the game’s platform. This demo was intended only as a way to explore the methods, tools, and technologies that will be employed in the class.

Please note that the gameplay elements discussed and shown here are a part of that tech demo test, and do not represent the look, feel, or theme of the game that will be generated throughout the class itself. These things will be decided through the class's development via design discussions between 3D Buzz and class participants.

MMO Development: A Technical Smorgasbord
I get asked a lot why 3D Buzz has decided to take on the development of an MMO as a Unity training topic. For the record, I’m a huge fan of the concept of MMO gaming. The idea of playing a game with my friends in a cooperative (or competitive) format was one of the biggest gaming draws for me, even many years ago in the old Doom multiplayer days. And as the technology has developed, the things that we can now do with many people all playing together are simply amazing.

Even now, while I don’t consider myself to be a modern gaming connoisseur by any means, the first time I played World of Warcraft and was able to coordinate complex scenarios with many friends at the same time, I knew I was seeing something special.

But beyond all that, I love the sheer amount of technology that has to be applied to a modern MMO game, especially in the case of role-playing games (RPGs). There are so many different aspects of gameplay that must be addressed: how will players interact with one another? How can they interact with non-player characters (NPCs)? How will the game handle items or pickups, even weapons? How will it handle spells or special abilities? And over all of this, how will each and every action performed in the game interact with the server in a timely fashion? And that’s only the tip of an ever-expanding iceberg. There are so many systems that all have to layer upon one another and integrate seamlessly to create an enjoyable gaming experience.

It’s all so deep and so technical that I can’t help but get excited just thinking about it. I think, more than anything, this is the biggest reason why I wanted to tackle the development of an MMO. There’s just so much information to impart and so many things that need to be taken into consideration, that it can quickly become overwhelming. I’ve always enjoyed the challenge of taking something that looks like an impossibly complex ocean of information and condensing it down into a digestible and fun-to-experience format. This, as many of you may already know, was the biggest reason I started 3D Buzz in the first place.

Over the next few pages, allow me to take you on a quick trip as to what we’ve been up to throughout this project so far.

Choosing the Right Game Engine

The game engine was the first key thing that we have had to tackle. These days, it makes little to no sense whatsoever to design a game engine from ground up. Sure, doing so allows for various levels of customizability, but at some point, you’ve got to realize that in most cases, someone out there has already invested a great deal of time and money into R&D-ing exactly what it is you want to do. This means that it’s often more efficient to choose from one of the commercially available engines, and there are many to choose from, each bringing their own pros and cons to the table.

Even though the entire idea started with the concept of developing Unity training, we made sure not to lock ourselves down, provided we could find a better means to create the game. I absolutely love Unity, but I’d rather know that I'm using the right tool for the job than trying to force myself to go through the motions of a development cycle for rhetorical reasons. We have experience in several different engines and we explored many different avenues to see which one worked best for us.

The interesting part was that even though we gave other engines a fair shot, it soon became clear that Unity was going to provide the smoothest environment and the easiest means to rapidly prototype each idea we had. It’s been amazing to sit down and discuss some aspect of the game, draft out a class structure, and to see a basic implementation of it within a matter of minutes.

But even that in itself is not the most compelling argument in Unity’s favor. Indeed, someone well-versed in the proprietary scripting language of certain other engines could make a similar claim. However, in choosing Unity, we were able to utilize programming tools with which we were already comfortable, such as Visual Studio. Plus, being able to use .NET opens the door to a wide variety of APIs, which you just can’t do with a proprietary scripting language. It meant that everything we did could be handled natively in C#, which led to very fast development of new elements to the program. Add to this the easy artistic integration using the FBX format, and Unity has provided us with a fast, clean, and enjoyable environment in which to develop our game.

Of course, we try not to just focus on the way we want to do things. We also try to keep the viewer in mind as well. We know that not everyone out there is in a position to spend a great deal of money on these tools, especially if it’s just something they’re exploring for the first time, or something that they do as a hobby. For this reason, we wanted to find a solution that was financially viable for as many people as possible.

Unity Standard contains all of the necessary components that a viewer will need to follow along, and it’s completely free. Sure, there will probably be some aspects we explore that are specific only to Unity Pro,
The Back End - Our Game Server

The next critical aspect we needed to get through was figuring out exactly which game server we would use. Obviously, once a game becomes “massively multiplayer,” the way in which you handle client connections becomes absolutely critical to how the game will play. Just as with the game engine, we didn’t want to create something from the ground up if we could leverage on proven technology.

We were looking for an infrastructure that allowed us to have potentially thousands of people interacting with no slowdowns. And there are a few different options out there. Of course, for starters, we looked at using the built-in networking system within Unity. It’s certainly a robust networking system, but didn’t have the kind of power we needed to support a full-blown MMO.

We then branched out to 3rd party socket servers. We looked at a few different candidates. The list was narrowed down to two finalists, those being SmartFoxServer Pro by gotoandplay() andPhoton by Exit Games. Both of these were very capable servers in their own right. We settled on Photon for a variety of reasons. The first is that Photon is built from the ground up in native C and C++. This makes it very small and streamlined (i.e. fast). It also utilizes UDP for faster performance, onto which is added a “reliability layer,” allowing the programmer to flag critical events, so that the server handles delivery of those packets. It makes for a very fast server with no dropping of critical data.

Probably the most important point that tipped the scales in Photon’s favor was the fact that it is extensible in C#. This means that the development of the game client and the server itself could take place with a single unified language, rather than having to use one language for the client and another for the server. If we’d gone with SmartFoxServer Pro instead, we’d have had to code the server using Java and ActionScript.

Just as we did with the game engine, we tried to make cost a significant concern as well. The Photon pricing scheme for indie developers and hobbyists is simply amazing. You can actually get the entire server, allowing up to 100 concurrently connected users (CCUs) completely for free. That many CCUs is more than enough for just about anyone creating their own MMO, at least through initial production. And if for some reason you should find that you need more than 100 connections on your game, you can get a 500 CCU version for just $450. Since we cater to indies and hobbyists, we found that going with Photon provided a way to keep the entire curriculum nicely focused while allowing everyone to save a lot of money.

With Widgets comes Freedom

One of the first obstacles we had to overcome as we launched into development was how to handle the various on-screen interface elements that a player needs in order to play a modern MMO. Even if you’re going with a minimalistic approach to the interface, there are certain aspects that players have come to expect within the genre, whether it be a list of tasks or quests to perform, some sort of an on-screen map, or any of a wide variety of interface elements.

To help us deal with the development of these elements in a flexible manner, one of the first things we created was a generic widget system that allowed us to quickly create tools that the player could use on the screen. The idea was that if we based all visual controls on a single widget system, we would have everything we needed to make a wide variety of tools later on.

The first test was an amazing success. It was timed to coincide with the end of our Digital Ink and Paint contest, in which we had taken all of the entries and placed them on the walls of a virtual art gallery within the MMO. Using this widget system, we were able to create an intuitive on-screen tool that allowed players to walk up to each painting and interact with it, bringing up an informational window containing the progression of the work from its original concepts to the final result.

Since then, we’ve been able to take that same framework and apply it to all of the conventional aspects one might expect to find in an online RPG, including an on-screen map, an inventory system, chat windows, and the quest tracking system. We have also been able to apply it to the concept of an action bar, which shows the player the various spells and abilities at their disposal, as well as displaying a visual indicator of the ability’s cooldown, or how long it will be before it can be fired again.

Character Building

Up to this moment, the culmination of our efforts has been to develop the underlying structure of the game itself. All artistic and visual elements are in place strictly for testing purposes, and so we have not really invested a great deal of time in them. However, we decided from the beginning that we wanted the player to have access to some level of character customization. At first, we had our hearts set on creating a simple biped character that had some swappable body parts, such as different hair pieces and clothing.

However, the flipside to that is that creating a customizable bipedal character requires a lot more artistic development than we had time for, once you take into account the time for texture creation, skinning of individual pieces, and other such considerations. It's not that it's particularly complicated, but like all artistic elements, it just takes time. Time that at that point, we simply did not have. As a compromise, we came up with the idea of creating little floating “Mr. Potatohead-like” characters, with a small library of customizable parts. It was really just so that we could have some level of customization in place quickly, but it turned out to be really funny to see the different combinations that people were coming up with, and to see them all running around in the MMO’s world.

We have since taken just a little more time and created our first bipedal character, sporting animation cycles and textures. It's still very simple, not yet having any customizable pieces, but it gets the point across. The game has supported it beautifully and, combined with an intuitive-third person camera system, has really helped to bring the conventional MMO feel into the project. The really funny thing has been that since we've now moved away from the floating egg-like characters, some part of me still misses them! As silly as they were, each one certainly had a character all its own.

Owning Your Own Piece of the World

Something that we felt was essential to helping a player really feel like they were taking part in a complete world was the concept of owning their own piece of property within the game. While there have been a few games in the past that have attempted this, it has been our desire from the start to really help the player feel like they have a place to go that is entirely theirs.

As a precursor to this, we held a contest on 3D Buzz in which people could design their own house to be placed in the game. Some guidelines were set forth as to what general theme the building should have, but outside of that, we just let people have fun with it. We got some great entries, which, because of Unity’s flexibility with the FBX format, we were able to quickly get into place within the game for all players to see and experience.

The next stage will come when we allow players to create their own building interiors. Our end goal is to have a library of interior objects, from furniture to knick-knacks to just about anything else you’re going to find within a domicile. But we also want to give people the ability to create their own pieces if they feel like it. We continue to explore how best to properly implement this idea. Currently, the winners of the contest are designing the interiors of their buildings, and we’re using their feedback to meter the types of hitches that we’re likely to run into. However it happens, in the end, we want to maintain a focus on letting the player feel like they have a little piece of the world that they can call home.but they won’t be deal breakers. Plus, if the viewer was able to make something that could be viably released, they’re not locked into having to deduct a percentage of their earnings from their work. The folks at Unity Technologies have really come forward as wanting to be a driving force in indie game development, and I continue to be blown away by how much they are willing to offer with no concern of a return percentage from an indie developer. Their approach feels like it comes from wanting to see gaming evolve, and from knowing that you need as many minds as you can get to see that happen. But I know I could go on and on about that; in the end, I’m just impressed that Unity provides so much power with virtually no red tape.
Combat - The Reason We Play Games

Of course, these days it’s virtually impossible to run into a game - especially an MMO - that is devoid of combat. However you may feel about this, there is some sort of innate draw to the idea of primal competition. Throwing spells, shooting weapons, or even some form of melee, people love the idea jumping into a world and experiencing combat with their friends.

As such, combat was something that we had to get into pretty early on in our exploration. Of course, there’s a near infinite number of ways in which the idea of an attack can be implemented. But we needed some sort of basic combat-driven functionality that we could put in place for testing. In the end, we decided on a simple fireball spell. The concept was that the player would select a target, trigger the fireball spell, see a visual effect, and then the target would take a set amount of damage upon impact.

But we didn’t want the first test to be limited to just projectile-based warfare. So we came up with two other types of abilities that we could implement as well, those being an area-of-effect (AOE) force push, and an instant-cast healing ability that could be applied to the player or to other targets.

When we got around to our first test of the combat system, it was clear we still had some kinks to work out. Probably the biggest thing that busted us that night was that we had to pull the healing spell at the last minute due to some errors, so no one even got to see that. Still, people could select each other and shoot fireballs.

But nothing was as fun as watching the force push spell go off. The idea of the spell is that the player gets a ground-based reticule that they can place underneath other players. Once the spell is fired, the center of that reticule serves as the center of a tremendous spherical outward force, pushing everyone away from the center. We probably overdid it a little, since a well-placed spell would send the targeted player well off the map or at least up into the lower stratosphere, but that test was a lot of fun and we had players spending hours sending each other flying around the game. We got a lot of great feedback from that test; a few people even said that they’d rather be playing that with their friends than their Xbox 360s or PlayStations.

Of course, the test also resulted in us having to seriously consider the world of game balancing, but that’s something that we’ll focus on a bit later down the road. It did, however, cause us to have to start taking server-side authentication a lot more seriously. In the end, the game needs to play out completely on the server, with the player’s client really serving as an interactive window into what’s actually going on with a game that is playing out on the server itself.

A New Way to Teach

Making a game is certainly a challenging and rewarding experience in and of itself, but it has always been the mission of 3D Buzz to teach, to provide high-end training on the hows and the whys of a particular technical topic. Because of the extremely intricate nature of MMO development, we wanted to make sure that we handled curriculum development from more than a theoretical standpoint. We wanted to actually make a functional version of a small MMO game beforehand, allowing us to test various 3rd party technologies, and to better gauge the manner in which the information will be presented. With so many technical aspects that need to work in complete concert, it only made sense for us to give it a run through beforehand, so that we’d have a clear path along which to guide the students as we move forward.

But beyond that, I want this class to feel like a completely different approach in 3D Buzz training. With so many hardcore technological aspects that need to be covered, the way we normally create our videos simply does not make sense. While we do pride ourselves on covering all aspects of the development process - including mistakes - there are some instances where a mistake or oversight is so severe that it requires the retraction of several minutes, or in some cases even hours, of completed video. In short, while we often show various problems that we come across while developing our videos, the quality of our presentation still requires us to be very careful and often re-record segments if we feel that it is necessary.

We simply can’t do that here. There’s too much to cover. Too many directions that the development needs to run and a lot of technical aspects that need to be managed as we do it. Plus, I don’t want this to feel like some of our previous programming projects, in which most, if not all, of the code is finalized beforehand and the student simply watches us type it out while explaining parts as we go. Rather, I want the viewer to take part in a more complete learning experience.

To this end, we will be recording design meetings and discussions in which we decide how things will work, and then simply use the experience of creating a similar game in the past to begin the programming process. If there is a mistake, then all we can do is explain what the problem was, get it fixed, and continue, just as you would during a real development cycle. I want this to feel like a more relaxed and informal journey with a team of developers, rather than a sterile and structured guide through a prefabricated series of code.

But I also want to change the nature of our usual distribution. I don’t want this class to be another set of disc-based training videos. I don’t want pre-orders. I don’t want people to have to wait for everything to be recorded and then get a copy. I want this class to feel more like an ongoing learning experience in which the viewer participates at their leisure. Because of all of this, we’ve decided that the class will be distributed via the 3D Buzz streaming system, and will be completely free to Member Sponsor subscribers on the 3D Buzz website. We try to give our MS subscribers certain privileges not available to anyone else, but in many cases a lot of their exclusive content is available in some form of hard copy to anyone. For this class, the entire curriculum will be provided via streaming to interested Member Sponsors, and that’s it.

At the same time, we’ve come to recognize over the years that opening up a class to any and all takers means that you must forego the personal aspect of the teacher and the student. To put it bluntly, the teacher gets spread too thinly. There is a point where an instructor has too many students to be able to do his or her job. We’ve been there and seen that, and we refuse to allow that to happen with this latest class.

It is because of this that the MMO class is going to have limited seating that is only available to Member Sponsors. Basically, we’re going to open up a set number of spots within the class that we will only offer to our subscribers. Once those are filled, that’s it. If someone leaves the class, that seat will open for the next interested MS on the list. We realize that there will likely be a lot more takers than we have available seats, and we really do hate that. However, we want those who take part to be able to have a fair amount of access to us for questions and discussion. We simply can’t do that if we allow too many students to sign up.

When all is said and done, my goal is to take highly technical activities and make them approachable. There are so many things that 3D Buzz has done already to take those moments in which people say “Wow, I wish I could do that,” and make them a reality. We take pride in being able to provide that. In teaching fledgling developers how to build their own MMO games, I think we've found a way to push that idea to all new heights. I am very excited about where this class is going to go, and am even more excited for those students who are able to attend.
“documentary” didn’t fully describe the interactivity level, and “workshop” put too much emphasis on interaction as a requirement, we ended up going back to the term “class” once and for all. But it’s different from a class in that we’re not going to be following some rigidly structured plan for the progress of the videos. We’re going to actually go through a development cycle and simply document the process.

This means that we’ll be recording team meetings, discussions, brainstorming sessions, and anything else that pertains to the creative process. We want to show the entire process. But the order in which we handle things will be more reflective of the order in which they’re being tackled in production, and not so much according to a plan or layout of pending videos.

That’s not to say there won’t be any actual “VTM-style” videos the likes of which you are used to seeing from 3D Buzz; far from it, actually. We’ll be doing a lot of our standard training style videos, but we’ll also be mixing things up with the aforementioned documented meetings, as well as overview-style videos on topics that we’ve already beaten to death in our previous videos (especially 3D-related stuff). Again, it’s more about documenting the process as smoothly as we can. So it’ll be a little bit of a hybrid between documentary and traditional training video. I’m really excited about the potential for this, and really interested to see how students absorb the content throughout the class.

As for a release schedule, I want to be firm with people right off the bat that there isn’t one. We’ll be setting a goal of having releases each week that the class is going on, but due to the various factors that may appear throughout the process, I’m not going to lock us down to anything. However, that’s one of the great things about treating the class the way we are: we’re not charging an upfront fee for access to the videos. If you get in and find that you don’t agree with anything we’re doing – whether it’s the rate of releases, something we say in the videos, or even if the laid back style doesn't agree with you (which happens) - then no problem. Just opt out or cancel your Member Sponsorship. There are no hard feelings from us, and I’m certain that there will be a line of folks waiting eagerly to take your seat.

Class participation is another aspect of this class which is interesting. We’re not really requiring anyone to actually do any form of participation if they don’t want to, or if they don’t have time. We understand that not everyone will be available at the same times that we are; everyone has a different schedule. Also, some folks just want to watch videos and take their own time, and we want people to know that we’re fine with that. So what we’re doing is having certain sessions that will be open on Skype for class participants to join in at their discretion. If you can’t or would rather not, it’s not a problem.

Assets and Source Code Concerns

Another question I’ve been getting a lot lately is how we’re going to handle the various assets that will be produced throughout development. Most of the folks following along (though certainly not everyone) are more interested in the coding and architecture side of the process than they are about the 3D artistry side of things. Because of this, lots of folks want to know if we’ll be giving out the assets that we come up with, so that they can follow along.

We will be making our artistic assets available, but only through an agreement that you don’t use them in a publicly released MMO. By all means, build your MMO with all of our assets, and you may certainly feel free to invite your friends to try it out. But when it comes to a publicly available version, we ask that you take the necessary steps to acquire some assets of your own. Basically, think of our assets as learning tools to help you focus on what you want to know, not as free assets for you to make your own game. Besides, we’re actually making a game, so if you use all of our assets, everyone will know you copied us!

One thing we won’t be making available, however, are blocks or snippets of source code. I think I just heard an audible groan when you read that. I realize this will probably frustrate one or two of you out there, but I hope you understand where we’re coming from here. If any of you out there have tried to seek out training in programming, you know the value of just looking at how someone handled a particular issue by reading through their code. We understand this.

However, that’s where we run into a security issue. There are plenty of folks out there who’d rather just read over our source than actually subscribe and take part in the class. Combine this with how easy it is for anyone to just copy/paste a block of code, and you start to see that giving out our code opens up a can of worms in terms of keeping people wanting to stay subscribed. While I wish I could just hand out the source to everyone, I’ve got to be able to keep our servers running somehow. So we’re not going to making the source available outside of what you see in the videos.

Tokens, Time Sensitivity, and the Spirit of Fairness

There’s another important aspect of the releases for this MMO that I also need to get across fairly early on. As I mentioned earlier, we’re limiting seating for this class, rather than just handing it out to all Member Sponsors. But along with that, I don’t want someone to be able to jump into the class in a few months (provided a seat opened up for some reason) and just be able to either skip through sections or to just cram into a few weeks what their colleagues have had to subscribe to months of our service just to access.

So to combat this issue we’re incorporating what we’re referring to as a “token system.” Simply put, each month of Member Sponsorship access you pay for provides you with one token. Each token unlocks a single month’s worth of training in the MMO class. This means that if you joined the class 3 months from now, you’d start off at the beginning, but those who had been in the class the whole time would be 3 months ahead of you.

However, this doesn’t mean you can’t catch back up. You could pick up an annual Member Sponsorship, which would provide you with enough tokens to unlock a year’s worth of content, which should allow you to catch up in your own time if you so desired. We just feel that it isn’t fair to those who’ve been running with the class the whole time to have someone come in late, skip a number of months’ worth of subscription fees, and thereby get some sort of discount. I know that if I was a student who’d been there from day 1, I’d get pretty mad to see someone come in 6 months down the road and start getting the same lectures I am, even though I’ve paid more than $200 more to get to that point.

And we’ve Already Begun

The really great thing is that if you wanted to get right down to it, you could argue that we’ve already started the MMO production, after a fashion. One of the things that will be critical to keeping the development moving forward smoothly will be some sort of project management software. Now, I’ve used several different project management system over the years, but I thought it would be cool, from an application development standpoint, to explore the creation of our very own project management system. We could then tailor it to our needs, we could add in the appropriate amount of flexibility to make it viable for any application we like, and we could even make the final product available to our Member Sponsors to help them keep track of their own projects.

To this end, we’ve already started the creation of such a project management system, and the process of development is being documented in our “Application Development with ASP.net” series that we already make available to Member Sponsors. So if you’ve signed up and are looking for something to do right away, you could definitely benefit from watching these!
转自：http://www.3dbuzz.com/