Wolverine
07-29-2004, 07:05 PM
Copied from the most recent developer diary entry (http://www.eagames.com/official/moh/pacificassault/us/diary.jsp) . This is an interesting read as it follows the development of the multiplayer interface of the game.
Games and Life - Origins of a Multiplayer Lead Designer #4
Interface Design 101
By Ed Moore - Multiplayer Design Lead
Chew on this for a second, Medal of Honor™ Allied Assault was on the top ten PC sales lists for almost a year and a half after its debut, and sold almost as much as Half-Life, yet if you look at online server statistics, it has only a fraction of the total number of servers. Without digressing too much into arguments over the myriad of possible reasons why this is true, would it be safe to say that a sizeable portion of the people who bought the game played through single-player, maybe tried multiplayer once or twice (if that) then put it on the shelf? Why weren't these players interested in multiplayer? Were they whiny, cranky, "don't like to lose" console-mongers like me that weren't quite "733T" enough to roll with the big guns online? Or could they perhaps be simply turned off or intimidated by the ornate bombardment of menus and screens that most games shove in their faces before they can have fun?
When I started working on the Multiplayer aspects of MOHPA, all that the Single Player GDD mentioned about the Multiplayer Interface was that when you clicked multiplayer, it would show a couple of Marines out by a table playing poker (of course, even way back then, we knew that poker was going to be the trend of new hotness that it is now). The document described some pretty basic options (find server, join server, options), but little else.
Now, the old MOH UI (from the original PS One MOH on up through the PC Expansions) had always been about generating the feeling that the user was in an underground war room or bunker, and by clicking and selecting different doorways or objects in the room, different functions would be revealed. In essence, the old UI, while certainly immersive and aesthetically interesting, is more like a graphical adventure than an interface, and its visual form dictated what a lot of the functions would be. To a certain extent, it went against a basic tenet of sound design principles, form follows function. Suffice to say, there was room for improvement.
I felt pretty strongly that with MOHPA Multiplayer, I wanted to give players a central nexus or community to return to, kind of like Blizzard's Battle.net service. Some place where players could go into lobbies, chat with each other prior to the game, talk some smack afterwards, or maybe make some friends and add people to buddy lists like in Instant Messenger. I had mentioned that it's more about the people, not the game, that makes multiplayer gaming interesting, and for many gamers, they don't want to have to work to have fun online, they just want to click play and start talking and fragging their friends. Anything we could do to remove obstacles, reduce and streamline complex, obscure processes, to make the most pertinent functions accessible, convenient, and to support greater human context and communication would become the crux of my multiplayer interface design philosophy.
Easier said than done! Having lofty goals and aspirations is one thing, knowing how to get there is totally different. Back in ancient times when I was studying Computer Science, one of the classes that was very influential to me was Software Engineering. All the prerequisites leading up to it may have taught me how to program, but this was the first class that I felt was really geared towards planning for and tackling big technical problems involving multiple people. Central to the precepts of this course was the role and importance of good technical documentation and specification. While some programmers have little use for planning or documentation, preferring just to hop in and hack away, keeping documentation maintained, current, and pertinent through all phases of the project's life, from the initial planning stages all the way through to final beta testing, was crucial.
I fell back on my vestigial software engineering instincts and adopted this approach to tackle this problem. First, I defined my toolset, all the UI elements, widgets, buttons, data displays, etc, that would be used to define the interface screens. From this I would lay out each screen in the interface, defining exactly which UI elements would be present on the screen, their total possible range of values, and their relationships to other widgets. Each definition of each screen would use a consistent format and set of conventions. So instead of just writing a paragraph or two that described what the screen should do (which could be subject to many different interpretations) I created specific mockups using the simple line drawing tools in Microsoft Word, along with detailed specifications of all the types of data and possible values.
It took me a while to find a "rhythm" but once I overcame the inertia, the Interface Spec really started to evolve. Through multiple iterations of layout, review, discussion, and revision between me and my senior producer, Matt Powers, we started to hash out what this was going to be. Neither of us really had any sort of background in interface design or really knew what we were doing. Although we had consulted with interface designers, as well as people in academia studying for doctorates in human/computer interfaces, we were driving relatively blind and it was slow going at times. One paradox we faced was making the interface convenient and accessible for casual gamers, while still offering the depth and complexity advanced or "power" users demand from their multiplayer games. Another big challenge was to constantly encourage users to "authenticate" or register to create online accounts or personas (necessary in order to provide buddy list and stat-tracking services).
Matt and I had lots of competing games to evaluate, but we wanted to disregard a lot of their bad habits and conventions but make something that was competitive and familiar, while trying to do some new things and to innovative. We both had some good instincts about what would work, what was intuitive, and what felt right. For example, we felt that the concept behind the Instant Action Utility from Breakthrough (one-click, you play, just like single-player) was a step in the right direction. Unreal Tournament again rears its head in this column, as the general direction of their interface design was based on tabs that grouped similarly themed functions together. It also provided many of the similar functions we were doing, and generally seemed to be well-thought out and accessible.
At numerous times I had suggested doing a prototype in Macromedia Flash (I had taught myself how to use it a few months prior to moving cross-country), but I never seemed to get that off the ground, it always seemed like there would never be enough time to do it right and it would only be useful to a certain point. Eventually, though, we put a lot of the Microsoft Word line drawings from the Spec into Powerpoint. This made possible a very rough but interactive walkthrough of the interface, allowing us to illustrate to our execs and producers exactly how simple it was to get to the most pertinent features for casual users, while still showing the ease of which power users could access the advanced stuff. Through numerous meetings and presentations we eventually settled into a feeling of cautious confidence that we had nailed this ambiguous problem and had made something special.
We've come up with some notable features that I think all players will be excited about. First off, there's Instant Play, which gives you one-click access either to a fast, open server that the game finds for you, or a preset IP address of your choice. Then there's the Server Wizard, takes an alternate approach to the process of hosting games. Inspired by the "gypsy wagon" method of character creation in the old Ultima RPG's, I designed the Server Wizard to guide you step-by-step through the most important and pertinent server options, making sure everything is thoroughly explained (kind of like how you install a program in Windows). Power-user features like Restrictions allow administrators to set limits on weapon and class usage, and filter out potential clients based on experience and skill stats, making sure that your server caters to newbies, experts, or anyone in between. Finally, incorporating a dedicated MOD Browser in our UI (that supports both auto-downloading from the server directly as well as redirected downloads to a web address) and removing a lot of the guesswork from mod authoring represents one of the key cornerstones of our Community Growth plans.
It sure took us long enough but by the time we figured out our plan for the multiplayer interface, the combined Multiplayer GDD and Interface Specification totaled more than 200 pages! Still think multiplayer is an afterthought now? Our goal from the beginning has been to expand the appeal and accessibility of multiplayer to get more people to see the joys of online play, and I believe that interfaces have a great deal to do with that. However, we didn't want to accomplish this by sacrificing the goal of preserving and streamlining the advanced functions that more experienced players, mod authors, and administrators need to help make the Pacific Assault community grow and thrive. Whatever your level of familiarity is with online gaming, I think users of all experiences will find a lot to like in our Multiplayer Interface.
-- Ed
Games and Life - Origins of a Multiplayer Lead Designer #4
Interface Design 101
By Ed Moore - Multiplayer Design Lead
Chew on this for a second, Medal of Honor™ Allied Assault was on the top ten PC sales lists for almost a year and a half after its debut, and sold almost as much as Half-Life, yet if you look at online server statistics, it has only a fraction of the total number of servers. Without digressing too much into arguments over the myriad of possible reasons why this is true, would it be safe to say that a sizeable portion of the people who bought the game played through single-player, maybe tried multiplayer once or twice (if that) then put it on the shelf? Why weren't these players interested in multiplayer? Were they whiny, cranky, "don't like to lose" console-mongers like me that weren't quite "733T" enough to roll with the big guns online? Or could they perhaps be simply turned off or intimidated by the ornate bombardment of menus and screens that most games shove in their faces before they can have fun?
When I started working on the Multiplayer aspects of MOHPA, all that the Single Player GDD mentioned about the Multiplayer Interface was that when you clicked multiplayer, it would show a couple of Marines out by a table playing poker (of course, even way back then, we knew that poker was going to be the trend of new hotness that it is now). The document described some pretty basic options (find server, join server, options), but little else.
Now, the old MOH UI (from the original PS One MOH on up through the PC Expansions) had always been about generating the feeling that the user was in an underground war room or bunker, and by clicking and selecting different doorways or objects in the room, different functions would be revealed. In essence, the old UI, while certainly immersive and aesthetically interesting, is more like a graphical adventure than an interface, and its visual form dictated what a lot of the functions would be. To a certain extent, it went against a basic tenet of sound design principles, form follows function. Suffice to say, there was room for improvement.
I felt pretty strongly that with MOHPA Multiplayer, I wanted to give players a central nexus or community to return to, kind of like Blizzard's Battle.net service. Some place where players could go into lobbies, chat with each other prior to the game, talk some smack afterwards, or maybe make some friends and add people to buddy lists like in Instant Messenger. I had mentioned that it's more about the people, not the game, that makes multiplayer gaming interesting, and for many gamers, they don't want to have to work to have fun online, they just want to click play and start talking and fragging their friends. Anything we could do to remove obstacles, reduce and streamline complex, obscure processes, to make the most pertinent functions accessible, convenient, and to support greater human context and communication would become the crux of my multiplayer interface design philosophy.
Easier said than done! Having lofty goals and aspirations is one thing, knowing how to get there is totally different. Back in ancient times when I was studying Computer Science, one of the classes that was very influential to me was Software Engineering. All the prerequisites leading up to it may have taught me how to program, but this was the first class that I felt was really geared towards planning for and tackling big technical problems involving multiple people. Central to the precepts of this course was the role and importance of good technical documentation and specification. While some programmers have little use for planning or documentation, preferring just to hop in and hack away, keeping documentation maintained, current, and pertinent through all phases of the project's life, from the initial planning stages all the way through to final beta testing, was crucial.
I fell back on my vestigial software engineering instincts and adopted this approach to tackle this problem. First, I defined my toolset, all the UI elements, widgets, buttons, data displays, etc, that would be used to define the interface screens. From this I would lay out each screen in the interface, defining exactly which UI elements would be present on the screen, their total possible range of values, and their relationships to other widgets. Each definition of each screen would use a consistent format and set of conventions. So instead of just writing a paragraph or two that described what the screen should do (which could be subject to many different interpretations) I created specific mockups using the simple line drawing tools in Microsoft Word, along with detailed specifications of all the types of data and possible values.
It took me a while to find a "rhythm" but once I overcame the inertia, the Interface Spec really started to evolve. Through multiple iterations of layout, review, discussion, and revision between me and my senior producer, Matt Powers, we started to hash out what this was going to be. Neither of us really had any sort of background in interface design or really knew what we were doing. Although we had consulted with interface designers, as well as people in academia studying for doctorates in human/computer interfaces, we were driving relatively blind and it was slow going at times. One paradox we faced was making the interface convenient and accessible for casual gamers, while still offering the depth and complexity advanced or "power" users demand from their multiplayer games. Another big challenge was to constantly encourage users to "authenticate" or register to create online accounts or personas (necessary in order to provide buddy list and stat-tracking services).
Matt and I had lots of competing games to evaluate, but we wanted to disregard a lot of their bad habits and conventions but make something that was competitive and familiar, while trying to do some new things and to innovative. We both had some good instincts about what would work, what was intuitive, and what felt right. For example, we felt that the concept behind the Instant Action Utility from Breakthrough (one-click, you play, just like single-player) was a step in the right direction. Unreal Tournament again rears its head in this column, as the general direction of their interface design was based on tabs that grouped similarly themed functions together. It also provided many of the similar functions we were doing, and generally seemed to be well-thought out and accessible.
At numerous times I had suggested doing a prototype in Macromedia Flash (I had taught myself how to use it a few months prior to moving cross-country), but I never seemed to get that off the ground, it always seemed like there would never be enough time to do it right and it would only be useful to a certain point. Eventually, though, we put a lot of the Microsoft Word line drawings from the Spec into Powerpoint. This made possible a very rough but interactive walkthrough of the interface, allowing us to illustrate to our execs and producers exactly how simple it was to get to the most pertinent features for casual users, while still showing the ease of which power users could access the advanced stuff. Through numerous meetings and presentations we eventually settled into a feeling of cautious confidence that we had nailed this ambiguous problem and had made something special.
We've come up with some notable features that I think all players will be excited about. First off, there's Instant Play, which gives you one-click access either to a fast, open server that the game finds for you, or a preset IP address of your choice. Then there's the Server Wizard, takes an alternate approach to the process of hosting games. Inspired by the "gypsy wagon" method of character creation in the old Ultima RPG's, I designed the Server Wizard to guide you step-by-step through the most important and pertinent server options, making sure everything is thoroughly explained (kind of like how you install a program in Windows). Power-user features like Restrictions allow administrators to set limits on weapon and class usage, and filter out potential clients based on experience and skill stats, making sure that your server caters to newbies, experts, or anyone in between. Finally, incorporating a dedicated MOD Browser in our UI (that supports both auto-downloading from the server directly as well as redirected downloads to a web address) and removing a lot of the guesswork from mod authoring represents one of the key cornerstones of our Community Growth plans.
It sure took us long enough but by the time we figured out our plan for the multiplayer interface, the combined Multiplayer GDD and Interface Specification totaled more than 200 pages! Still think multiplayer is an afterthought now? Our goal from the beginning has been to expand the appeal and accessibility of multiplayer to get more people to see the joys of online play, and I believe that interfaces have a great deal to do with that. However, we didn't want to accomplish this by sacrificing the goal of preserving and streamlining the advanced functions that more experienced players, mod authors, and administrators need to help make the Pacific Assault community grow and thrive. Whatever your level of familiarity is with online gaming, I think users of all experiences will find a lot to like in our Multiplayer Interface.
-- Ed