Articole vechi ArenaNet

Discutăm de toate

Articole vechi ArenaNet

Mesajde Tudy » 24 Feb 2012, 23:41

În timpul emisiunii de azi am amintit de niște articole foarte interesante care erau pe vechiul site al ArenaNet (site care nu mai e online).

Le-am găsit însă pe web archive și le iau pe rând:
http://web.archive.org/web/200502080201 ... 62602.html

Citat:
Great Tools Make Great Games
By Jeff Strain

Introduction

In most game development companies, there is a huge distance between the development staff and the customers. As developers, we are constantly striving to close that gap, to bring the development team into closer connection with customers by reducing the many layers of the process that involve the game moving from the developer’s mind to the gamer’s PC.

From the desk of an artist at a typical game company, each new art asset has to go through the usual approval process, after which it is passed to the programming staff who are responsible for placing it into the game. And it’s here that lengthy delays can develop between the time of actual generation and the time when one can ultimately see the asset in the game world, either internally within the company or externally, where it is sent out directly to the game testers or players.


The Challenge and the Early Solutions

A tool is the means by which you translate design ideas into a product. In the earliest games on which our team worked, such as Warcraft, we had virtually no tools at all. All four of the major game elements – art, sound, maps, and mission creation – had to be processed through a programmer and “hand placed” into the game. Because each element had to be built into the game engine by a small corps of programmers, and the amount of material they had to handle was overwhelming, the development process suffered constant delays.

It is typical in most companies that large numbers of design team members funnel all their work through a far smaller number of programmers in order to get the properties placed into the game. This “many working through few” situation creates a frequent and major bottleneck. The team members involved in the first wave of development such as the level designers or the artists might number in the dozens, and they are required to have all their work pass through the hands of the smaller programming staff, who might number five or six.

The fact is, the more you can decouple the programmers from the content of the game, the better the content will be. This is true because the content makers – the artist and animators and level designers – will see their work immediately in the game and then will be able constantly to improve upon it.

When Blizzard began development on Warcraft 2, the team decided to create a tool to aid in the mission creation process, which was called MapEdit. MapEdit allowed the placement of game assets, such as terrain art, units, and sound, to be handled by level designers rather than programmers. It significantly improved the process over Warcraft, in which missions were created in a very slow manual process. So part of the dependence on programmers was eliminated, but programmers were still necessary to add the game assets to the MapEdit database as well as for the mission logic.

We took the toolset a step further in StarCraft by including a trigger system that the designers could use to script mission logic, which eliminated the need for a programmer to code it by hand. This was a big improvement over MapEdit, because it put the responsibility for mission design into the proper hands: game and level designers. More importantly, it gave them the ability to iterate quickly and continually on the mission design, and problems of play and balance were spotted and fixed early in the creation process.

But we still had a bottleneck, because entering the art and sound assets into the StarEdit database required a programmer. During the time I was involved with StarCraft, we had an artist who came up with fantastic ideas for content and would bring art assets for me to make available in StarEdit so that he could place it them in the game world. But because all the assets had to be gated through the editor before they could be placed in the game world, it is no exaggeration to say that the artist often had to wait a couple of weeks before he finally saw his new art asset in the game.

After that long wait, if he found that there were tweaks or adjustments to be made, or if he decided to go back to the drawing board and come up with a completely new concept, he would have to take his place at the end of the line where he’d wait another few weeks before he could see his new or revised asset iterated in the game. And of course if the asset required further adjustments, or if other assets added later did not blend with the original art, it was back to square one yet again. This laborious process, and the length of time it took to get even the simplest of changes into a single piece of art, must have been tremendously frustrating to him. This sort of bottleneck is a major demoralizing factor where the entire staff faces the hurdle of a “hurry up and wait” in almost all layers of game production.

So while the Campaign Editor (StarEdit) was a major leap forward in tool design, I found I still had lessons to learn after I created it. The Campaign Editor allowed the team, and eventually the gamers themselves, to add individual assets and to get a look and feel for how they would work on a playable map. StarEdit may have been an evolutionary step forward for the development of StarCraft, but because the assets had to be added by a programmer into StarEdit, we had not completely eliminated the Programmer Bottleneck.


Improving on a Good Tool
A good game development tool makes its creator obsolete.

Tool development is an evolutionary process. While we used and benefited greatly from StarEdit, developers outside the company significantly improved upon the concept later. I was once hanging out with the Dev Team from Age of Empires, and we started talking about the StarCraft Campaign Editor. He told me they thought it was a great tool that allowed efficient building of game levels, and he admitted that his team used many of the concepts of StarEdit while creating the editor for Age of Empires. But they included a very significant improvement: They created a “Test Now” button.

StarCraft has a series of load (“glue”) screens – screens that allow the map user to select team settings, game type, etc. Each time our StarCraft team wanted to test something, they had to go through that whole sequence of glue screens before they actually got into the game. The Age of Empires team gave their designers the ability to iterate quickly with the simple addition of their “Test now” button. With that, a developer can build or alter a level and, by pressing the button, can be in that mission immediately. It may only take 30 seconds to go through the glue screens, but if each team member does 20 loads a day, and there is a team of 10 working on the game, that would be more than 1.6 hours a day lost to clicking through pointless glue screens! Given these hypothetical figures, the addition of the “Test now” button translates to a savings of nearly 500 work hours a year!


The Future and the ArenaNet Difference

Imagine an artist being able to create a piece of art and being able to see it in the game world and witness it undergoing game testing in a matter of minutes, not weeks. With our tools, this is not only possible, this is happening every day at ArenaNet. We don’t have a “developer’s build” and an “everyone else’s build.” What we’re working on, while we’re working on it, is what everyone is testing and playing.

And this is one of the things we are most excited about with our company’s process of game creation: The distance between the developers and the ArenaNet gamers is extremely short. Our artists are able to create an art asset, and because we’ve given them the tools that make it possible, the artist can place it directly into the world where within minutes it is compiled into the next build, and in as few as ten or fifteen minutes, is out to every one of our testers, being tested, being commented upon, and if necessary, being reworked. If there is a problem, the artist can institute and re-up a change that is dropped seamlessly into the testers’ games the very next time they play.

Giving our team the tools that allow them to perform as many independent functions as possible minimizes the Programmer Bottleneck. Our tools allow the team to place assets directly into the game world on their own, without jumping through hurdles and standing in line while somebody does the coding. We give them the tools that allow them to see their work nearly immediately, get feedback, and make changes in an extremely timely manner.


Tools as an Investment

It took us two years to build our game-development tools, and we know that they will never be truly finished. As long as we are using them, the tools will be refined and improved. We knew that this initial time was well spent, and that the investment of time would pay off in the end, because instead of waiting in a bottleneck for weeks, our team can see their assets in the newest build of the world on an hour-by-hour basis. This allows our team members to move on to the next project, or to reiterate the asset. What it all boils down to is this: Time invested early equals time saved later. Now that we’ve developed our tools, the game is coming along by leaps and bounds. From week to week, it progresses at amazing speed.

And as our game progresses, everyone is seeing the same build at the same time, and we are all commenting on that “universal build”. The benefit of everyone playing the same build is that you dramatically increase the likelihood that someone will spot an error and report it. The way most games are developed is that there is a global build that testers play, and multiple development builds that are only seen by one or two people at a time. Usually the tester build is refreshed once a week or so. By having one global build that everyone is playing, and posting builds multiple times per day, problems are more quickly spotted just due to the sheer number of people playing it. So, when, for example, a tester reports that a creature dies by falling to the left, and yet the creature’s corpse is shown lying facing the right, we’re able to step in and test that in the single world we are all viewing, and if the bug is verified and a change made, everyone will receive the update the next time they enter the game.

The ability to quickly iterate is particularly important when each asset builds on the others in a set. The look of a forest begins with a single tree, and our artist needs to be able to start on a series of designs and see via that first tree if his forest concept is sound. Using the old method, he might have spent many hundreds of hours on a series of tree and forest designs that all end up being dropped simply because that first tree wasn’t right for the world. Because he was not able to proof that first tree, because it was lost in the Programmer Bottleneck, he was unable to make an early judgment before proceeding with the faulty design concept. That simply doesn’t happen with our tools.


What do great tools make possible?

it·er·a·tion (\It`er*a"tion\, n.)
The act of saying or performing again.


It’s not just being able to see the assets in the game world on a daily, constantly-updated basis that is significant. The most powerful benefit of good game development tools is being able to iterate game assets repeatedly, quickly, and independently, and being able to iterate quickly and easily is the path to a great game. If a team member is able to generate a game asset such as a piece of art, a sound effect, or a quest, and after creation, to be able to iterate the asset again and again - to hone, refine and polish it – that ability makes a massive difference in the quality of a game. Whether iterating and reiterating a game asset makes it look more attractive, operate more smoothly, or perform a function more efficiently depends on what sort of asset it is. But in the end, iteration and reiteration is what raises the quality of the individual assets which in turn is what makes the difference between a good game and a great game. Time saved via the elimination of false starts is time that can be spent in including more content, or in perfecting the content already in the game.


Being able to iterate quickly and easily is the path to a great game.
Hard Truth about Timelines

All games have release dates. No matter how much we live by the “we’ll ship when it’s ready” credo, we also need to be able to make and keep commitments to our customers. So the more efficient the development process, the more content there will be. With game development, there are always trade-offs between making the date, including more content, or improving the quality of what has already been created. With good tools, you don’t need to make those choices or sacrifices.

A development team’s ability to change things disappears the closer they get to release. Even if a marvelous concept comes along at the eleventh hour, the team is not going to be willing to take the time to implement that change, or incorporate that asset, because with all the other layers with which the addition might need to interact, the time needed to proof it and make sure that it looks appropriate and works properly becomes daunting.

So it is essential that we are able to change things early, to see the game change daily, and be able to alter things “on the fly”. What really makes a great game is getting something up and running and playing it daily and being able to change it 20 times a day if needed.


From Release Day and Every Day After

From the day we release and every day after, the game will change. The release date is just one day, a tick mark on the calendar. We will be able to update, seamlessly and virtually at will. If someone reports a bug, we can fix it quickly. If we become aware of a balance issue, we can address it quickly. And as time passes, if there are improvements to technology, even those of a system-specific nature, we can exploit those improvements with an update. Say, for example, a new video card comes out that exceeds the capacity of the cards on the market at time of release. In order to allow those with the video card to have the eye-popping imagery their new hardware enables, we can create an update that makes this possible.

Part of the reason that our game system has integrity and stability is because everybody uses the system every single day. We “eat our own dog food” every day, and if we don’t like it, we change it.

We want to release a game that is as close to perfect as we can make it, and we believe that creating powerful development tools is a means to achieve that goal. The day we release our first title will be no different than any other day, and those who join us in the early hours of that first day will be playing exactly the same game that we have been playing at our office and in our homes for the last several weeks. Knowing that the more time you invest in your tools, the better the game will look and the better it will play, we’ve taken the time to make it possible for the development team to place assets directly into the game, and we’ve assured that everyone sees and interacts with the same single world on a daily basis. We believe that these are two major evolutionary steps in game development.
-------
I want to live forever. So far, so good.
GW2 Official Wiki - GW2 Wiki FAQ
Imagine
Avatar utilizator
Tudy
GW2.ro staff
 
Mesaje: 1401
Membru din: 14 Feb 2011, 17:07
Localitate: Cluj-Napoca
Nume caracter: Tudy
Zona de interes: World vs World

Re: Articole vechi ArenaNet

Mesajde Tudy » 24 Feb 2012, 23:42

http://web.archive.org/web/200502080206 ... 22102.html

Citat:
The Challenges of Making a Multiplayer Game
By Patrick Wyatt

Introduction

As you've probably noticed among your computer gamer friends, on-line gaming has grown by leaps and bounds over the last few years. Many more homes have Internet connections, cable modem and DSL are expanding into more neighborhoods, and the number and quality of games that involve people in the on-line environment have also grown rapidly. While many quote statistics from Jupiter Media and other research firms, we've seen firsthand how fast on-line computer games are growing by being directly involved in creating and running a gaming network.

As game developers, and as gamers, we're excited about this growth, and we want to satisfy the expanding market for on-line games. But as developers, we are acutely aware of the challenges involved in reaching our goals. In this article we discuss some of the issues involved with creating a good on-line game, and outline some of the challenges in making everything work.


What Makes a Multi-Player Game Great?

Depth: A successful game will be designed so that there is not a single "best" way to play. If there is one very effective "killer strat," or if one character or racial type is wildly unbalanced or has noticeable advantages over the others, then everyone will be tempted to play precisely the same way, which creates a dull play environment.

The ideal game will offer many different ways of winning, and will encourage exploration of different characters and strategies. A good developer can incorporate elements of the "paper, scissors, rock" challenge, where for every in-game choice - be it strategy, character type, item use, area of spell research, point placement - the exponential rise of variable interactions is dealt with. Balancing two spell types against one another isn't remarkably difficult. But balancing those same two spells against one another, when used by a variety of character types, and when used in combination with a multitude of other spells and items, becomes much more complex. This is an effect of combinatorics, where adding more elements to the game design causes the number of possible combinations to rise on a massive scale.

Ideally, no individual item, character, or strategy should be inherently better than any other. As an example, in StarCraft, if you run ten of the heaviest Siege Tanks into a base, you will nearly always lose in your attempted assault, despite that fact that the unit itself is very effective. Its effectiveness lies in the combinations you choose. If you layer your choice of Siege Tanks with other units - Vultures, Marines, Firebats - you'll have a far greater chance of success. So you have chosen one possibly successful strategy, and of course that strategy can be countered with a dozen defensive strategies. When we developed the game - and when we develop our future games - we have to consider all the combinations, singly and in multiples, so that any one choice isn't always victorious, but rather that a variety of choices are given a balanced opportunity of victory against different defenses.

The large number of strategies, counter-strategies and counter-counter-strategies means that it's incredibly important to have a long testing cycle and to include the gaming public in the testing process. No matter how much testing is done inside the company, any game that's complex enough to have many strategies and counter- strategies is also so complex that the developers cannot exhaustively test every possible scenario. By publishing via the Internet we expect to be able to provide immediate, incremental patches to handle play-balance issues both large and small rather than waiting several years for uber-patches as is more common with retail titles; our long development process (two years and counting!) is partially due to the effort we've spent on automating every part of the patching process.


Learning Curve: Another important factor is ease of use and the individual player's "learning curve." It's difficult to judge the quality of some games from an early view because the true level of game quality only becomes obvious after the investment of many hours of a player's time. Few players have the patience to master games with a difficult learning curve (myself included!), and the interest in those games quickly fades. Most good games, and most widely successful games, have a gentle learning curve so that new players aren't intimidated by the complexity of the overall game but can gain playing skills while having fun, while experienced players continue to add to their repertoire of tactics well after the game's launch.

Games that have "startup missions" or "walkthroughs" are essentially guiding players up the slope of the learning curve while entertaining them, but of course there has to be a careful balance between "easy enough" and "completely unchallenging". We've found that adding fresh testers all the way through the game development process dramatically improves the quality of the early missions. One of the difficulties we regularly faced in developing both the 'Craft and Diablo series was that our internal testers rapidly became the best players in the world, because playing 8 to 12 hours a day is like going to gaming college. We had to be careful about setting the difficulty level to meet their rapidly advancing skill level, and we frequently added new testers to the mix to ensure that the game difficulty increased only moderately for the early game missions.

Public beta tests growing from tens to thousands of gamers during the last few months of game development are an excellent means to squish bugs, validate play balance and check for hardware compatibility, but there is another form of trial that can be very useful as well, which is called "usability testing." This type of test requires watching individuals playing the game without providing any feedback to see how they navigate the interface, to learn how intuitively the interface works as they progress through the game. Standing back and observing a player move through the game for the first time is incredibly helpful to developers in discovering game areas that they need to improve in order to make things more user friendly or more logical to the average person.

The final developer's challenge related to the learning curve is to create a playing environment that establishes viable player match-ups so that novices can fight against others with a similar skill level, grandmasters can find a challenging game, and players of every other skill level in between can match up with others of like ability. Ladder rankings help establish viable player match-ups, and difficulty settings are an assist as well. Allowing players to choose individual difficulty settings is a big win, because there is no right or wrong answer; the players can agree on the game balance among themselves.


Fairness and Chance: Game balance should work in such a way that the better player usually wins, but the underdog always has a more than fair chance. Many games have a problem where the first few minutes of play determine the outcome, although it still takes a long time for the inevitable win. We called this the "Z-factor" at Blizzard, after the RTS game called "Z", by the Bitmap Brothers. While it was well- done in many regards, the game was generally a race to victory: as soon as one player captured one base more than his opponent, he would inevitably win no matter the strategy of the other player. With Warcraft and StarCraft, we tried to create a game where a good player will usually win over one who is average in skills, but where even the less-experienced player has a chance of winning from time to time with the use of novel strategies or even just a bit of game-generated luck.

It is difficult to work in elements of fairness and chance, because even small advantages tend to compound over time. Having one more Peon unit is like compound interest: if you don't start "investing" early, you won't be able to retire! An example of the developers helping out the underdog can be found in many racing games, where the racer who is behind is given a slight speed boost. Sometimes, that'll be enough to zoom to the front just at the finish line. Of course, some players learned to capitalize on this "underdog advantage," but games are generally better for its inclusion.

Another challenge is to create diversity rather than completely analogous units. A good game doesn't have units that are completely balanced one-for-one across the board, but it should have pairings that offer pluses and minuses that make them somewhat equal. Considering Warcraft's Archers versus Spearmen: we had tried to make them somewhat different, and so gave the Spearmen more damage points, but the Archers a bit more range. The problem is, of course, that the Spearmen can't do any damage at all if they don't get close enough to attack, and in a match of Archers versus Spearmen, the Spearmen are dead before they get a good chance to try to take out the Archers. In Warcraft II, we wanted the Paladin's Healing to be an excellent counter, pretty close to a "tit for tat," to the OgreMage's Blood Lust. However, due to the game mechanics and the spellcasting constraints of Healing (such as having to individually select each healable unit), Blood Lust will always take the day. It wasn't until we changed from Warcraft's "unit equivalence" to StarCraft's "race equivalence" that we were able to correct the most egregious play imbalance issues.


Social Opportunities: On-line gaming is a very social experience, and gamers want the chance to play in games with their friends, guild members, or acquaintances. Players sometimes desire to have places to meet outside the gameworld itself, which is why forums, chat rooms, guildhalls, and message boards are so popular. Multiplayer games should cater to these social desires, and make it easy to meet friends (new and old), and to keep connections with peers. The fewer barriers there are to this social interaction, such as divided game servers that separate people by geography, the better.

The reason that most games split people into separate "geographic" groups is because it's (relatively) easy to write a standalone server, but much harder to have the servers communicate, as they have to be designed to share workload, minimize communication overhead and resource contention, and minimize the latency between users. While banking software can take 5 or 10 seconds to approve a transaction, having a conversation with another person with 5 second lag is an exercise in frustration. The reason that most companies don't make the effort to correct this is because it is difficult and time consuming. And certainly, if you don't design a system that will handle these challenges up front, it's very difficult to correct the problem later.


Moderation: We feel - as gamers as well as developers - that expectations of a certain level of behavior are a good thing. Some level of anarchism in a game world is appropriate, but it's important that there's a fair set of rules so that antisocial players don't end up ruining other players' experiences. People can actually think their choices are "justified" by the amusing illogic of concepts like "I had to hit him because he was going to hit me first." While some games provide game moderators to attempt to correct "social injustices", it is a daunting task to successfully perform game moderation. There are probably a few thousand game developers and moderators in the world, while there are millions of game players, so the logistics of being able to create a well-moderated environment for a successful game are difficult indeed.

So, how do developers meet the desire for free choice that the gamers want, while not allowing any one group to run amuck and spoil it for everyone? They offer choices. One choice could be a selection of environments or game types. For example, if you have a game that allows player-killing, decide whether to establish a separate world for those players, or whether to allow them to play in their choice of game worlds but with limits, such as mutual acceptance of PK Mode, or whether there are no limits, but there is a warning system in place. Do you want to allow back-stabbing, like alliance switching or hidden partnerships? Then give people enough choices that they know what they're getting into. Offer melee-type games which allow these changing alliance options, but also offer free-for-all games that disallow alliances from the outset so that those who want to play "every man for himself" and want to avoid betrayal by allies can choose that mode. For those who like to play in a group environment, offer team games as well as melee games. Team games will offer fixed alliances and remove the option for "teammate betrayal," where melee games will always contain that "edginess of the unknown" that some gamers enjoy.

Giving gamers tools to choose play partners, including rankings and buddy-lists is a good start. A goal of ArenaNet is to give players the tools to perform a great deal of self-moderation by creating their own guilds. Each player will be able to select a guild (or several) appropriate to his or her own playing style, and have the expectation of playing against others with similar "social instincts."


Player Choices: Any game requires a player to make choices. Whether it's what character class to be, what strategy to pursue, what technology to specialize in using, or what area of the gameworld to explore, there are many questions to answer. A player needs to feel satisfied with his game choices; this long-term satisfaction is essential to a successful on-line game experience. Developers need to create an environment where each person has the chance to feel like "the hero" and where choices made early on are not constraining later in the game. After all, does anyone really want to be an armor maker, or is it that the game world is not creating enough rewards for a more heroic play-style?

This challenge can be addressed by considering what sorts of psychological rewards might inadvertently be given for unexpected behaviors. Do developers really want to encourage "spawn camping," where people spend hours a day in one spot, killing the same monsters over and over again, in order to level up or get great items? By rewarding players for trading items, do they want to encourage players whose sole occupation is making applesauce? These phenomena are preventable if the development team will forecast a consequence for each choice.


Replayability: After you've handled the factors listed above, then replayability and longevity are definite considerations. No one wants to spend his hard-earned cash for a computer game that ends quickly and doesn't encourage replay. The best games are those that invite you back again and again, to learn a new character type, explore a fresh area, investigate a new group of skills or abilities, or to try a totally different strategy. Some of the simplest concepts are the most long-lived. Examining the rules of chess is easy, but the game itself draws lifelong dedication to learning its intricacies and mastering its art.



The technical hurdles of multi-player games

A Lag-free Environment: Few things raise the hackles of on-line gamers more than "lag" in a game. Lag occurs when the multiple computers involved in the game become unsynchronized and fail to reveal the same worldview or begin to respond to player commands at varying speeds. The game must utilize as little bandwidth as possible in order to run on the widest variety of systems and to avoid the evil Lag Monster. In addition to real-world difficulties introduced by the light speed delay of packets sent over long-distances, re-transmission of packets caused by network "hiccups", and the narrowness of the pipeline through which packets are sent, developers have to avoid a whole slew of programming complexities that actually induce lag.

First and foremost, a game must minimize the number and size of packets that need to be sent. Since each packet has a substantial amount of overhead in the form of a "packet header", sending two packets with one command each has twice the overhead of sending one packet containing two commands. Furthermore, every "large" packet that has to be sent delays all the packets "behind" it in the transmission queue because of the time required for the hardware to transmit the data.

In addition, we need to search for induced latency, which is caused when the programmer has done something in the code that causes packets to be delayed, which is quite a bit more common than you might imagine. The bottom line is if we achieve greater efficiency in the code, and a more direct order of operations, lag will be reduced.

Finally, the most important thing is to test the game the way it will be played! A lot of multiplayer games are tested, not over the Internet, but exclusively on the internal high-speed local area network. This is a recipe for disaster, as you can only find out how things will work in "real life" by doing "real life testing." At ArenaNet we've made a point of developing and playing our own game over the Internet to ensure that we suffer exactly as much as our users have to.


Responsiveness: Once everything possible has been done to minimize latency, the next step is to minimize the appearance of latency (also known as "latency masking"). For example, the 'Craft engine "acknowledges" orders immediately with sound effects ("Yes, my liege"), and by changing the cursor graphic, for example showing a target reticule when you are in targeting mode rather than the normal selection cursor. But in both instances, it may be several game cycles before the order is actually carried out. Even when a serious network hiccup occurs, the game will still accept user input, and although the result of the input may be delayed, the game still "feels" responsive. Only as a last resort does the game halt temporarily to display a network timeout indicator.


Conclusion

While working on our first ArenaNet title, we're keeping our past experiences in mind, while working to build something even better in the future. The challenges of creating a successful multiplayer game pose interesting obstacles, but they also present fascinating opportunities. We consider ourselves fortunate to have the chance to build something we're really excited about, and we look forward to sharing it with you.
-------
I want to live forever. So far, so good.
GW2 Official Wiki - GW2 Wiki FAQ
Imagine
Avatar utilizator
Tudy
GW2.ro staff
 
Mesaje: 1401
Membru din: 14 Feb 2011, 17:07
Localitate: Cluj-Napoca
Nume caracter: Tudy
Zona de interes: World vs World

Re: Articole vechi ArenaNet

Mesajde Tudy » 24 Feb 2012, 23:43

http://web.archive.org/web/200502080203 ... ticle.html

Citat:
"Why does it take so long to make a game?"
By Patrick Wyatt


Games take a long time to develop, there are no two ways about it. The time from announcement until the day the game is in the stores - or the day the game is available for you to download and play on ArenaNet's gaming network - can seem an eternity. And that time lapse isn't just felt by those waiting for the game's release. That perception of time passing applies to those of us working on the titles, too.

So why does it take so long to make a game? There are three fundamental reasons:


Tools and Technology

With every new title, we are essentially reinventing the wheel by adding and rewriting substantial portions of the game engine. This is particularly true for startups like ArenaNet, which start with zero lines of code and no artwork! Every title has new core technology, which includes libraries for the game, the network, and the database. There is new technology involved, new platforms to adapt to (Intel's IA-64 is finally here!), and so on. With the rapid evolution in technology, every game has new systems to consider and new configurations to embrace.

Before starting on the game, the programming team has to take the time to develop the various tools that allow the artists and designers to create resources for the game. These tools include model and texture converters, map editors, network monitors, and program testing agents, all of which need to be complete well before the game is ready to ship.

Programmers need to create tools to help the designers and artists drop elements straight into the world. This takes time, but in the end, it helps open the "programmer bottleneck" that can be a major slowdown in game development. If a designer or artist can pop his/her materials directly into the game, where it's immediately assimilated into the gameworld with no delay, the changes can be tested and proved sooner rather than later, and the artist's time is freed from the delay of that infamous bottleneck. Making changes to maps in Warcraft I was a laborious process, taking skilled level designers from several days to a week due to the primitive tools employed, whereas play-balancing Warcraft II and Starcraft maps benefited from much more immediate turnaround time due to their sophisticated map editors.

The first six months of coding the ArenaNet game engine was primarily focused on building art and design tools, and completing the low-level networking code, so that later work could build on those foundations.


Scalability

So, in the instance of the programmer bottleneck, some might suggest, "Well, hire more programmers. If you have a team of, say, two programmers, add two more and double the output." Unfortunately, that's not exactly how it works out. Doubling the team will generally not double the output. Rather, with the increased number of people to whom every decision, direction change, or design modification needs to be communicated and through whom it needs to flow, the output is not significantly increased. It's much easier for a smaller team to have a consistent vision and participate in the design process, something that became a nightmare when the Diablo II team grew to over fifty people at two sites. At some point during game development, usually at a smaller number than most people think, the perfect balance between total output and speed is reached.

As interesting academic paper on the subject can be found here. In it, Professors Smith, Hale, and Parrish confirm, "It is a well-accepted axiom in project management that increasing the number of people working concurrently on a task does not result in a corresponding increase in productivity. They cite Brooks' Law: "Adding more programmers to a late project makes it later." Brooks' quote comes from his study called "The Mythical Man Month" - found here. Brooks' study appraised the management and planning of a large programming effort, and analyzed the successes and failures of the project. Future game developers take note: it's required reading for many Computer Science programs.


Testing, Testing, Testing

So after the game is developed, what's left? Testing. More testing. Testing yet again. Testing first by the individual or cluster of individuals directly involved in that particular game element - be it animation, character art, or level design. Then, testing by a larger in-house team. Because what we are creating is all new, and stems from our imagination, it never turns out exactly as we anticipated. We have to test it - again and again - to weed out the bad ideas and to keep and improve upon the good ones.

An example of the iterative nature of game design is the Alpha version of WarCraft II. War2Alpha was a pre-release version sent to magazines for game previews, but it "slipped out" onto the Internet several months before the intended release of the game, and certainly well before the game was complete!

In War2Alpha, the way oil was harvested was substantially different from the final release of the game. Oil has always been collected at sea, but did you know that at one time you had to send out a ship to scout for the oil by pinging, like sonar, until the petroleum was located? We thought that was a cool element in the early stages of designing WarCraft II, until we tested it and found it required a lot of "hands on" for the gamer, and distracted him from other more important elements of the game. It required too much unit monitoring to locate the resource. In the end, we discovered through testing that it was more fun to have your units locate oil by the now-standard "greasy patch on the water" method.

Another facet of WarCraft II that was significantly changed was the number of resources. We started with four resources: gold, wood, oil, and stone. In fact, you can still see evidence of stone as a resource when Sappers blow up near a rock pile and the pile is reduced in size, similar to how a patch of forest is reduced in size as trees are harvested by Grunts and Peons. We discovered during internal testing that resource management was too time-consuming and that the game wasn't as fun, so we settled on three resources for the game's release.

In StarCraft we reanalyzed the whole concept of resource gathering again and decided on having only two resources, but we instituted what we thought would be an intriguing change to the collection process. We began with the Vespene Gas resource being collected from random "clouds" on the map. But that, too, proved a hassle for the testers, so we went to Vespene Geysers situated near the bases, which made the resource's collection more logical and more fun.

Another dramatic example of how testing can utterly change the direction of a game design can be found in the original Diablo. Diablo was, initially, a turn-based game. Blizzard North was heading towards developing it in that mode, but after team consultation, they decided to turn it into a real-time role-playing game. The team also decided that, although the game could support as many as eight players, it wasn't nearly as fun with that many. Because of the narrowness of the dungeon passageways, eight players couldn't play and fight together, so they would wander off into different areas of the dungeon and either get into trouble or walk through long areas already cleared by others. It was only during testing that we learned of this problem and then decided to limit the game to a maximum of four players.

In short, good developers want to release a game with features that have been tested and which have been proven to meet the threshold of enjoyment - the "fun factor" - that gamers seek.


Conclusion

So, there's a bit of insight into the game development process. We sincerely appreciate your patience during our development time and hope that sharing a few insights with you will shed some light on why it takes a while to put out a good title.
-------
I want to live forever. So far, so good.
GW2 Official Wiki - GW2 Wiki FAQ
Imagine
Avatar utilizator
Tudy
GW2.ro staff
 
Mesaje: 1401
Membru din: 14 Feb 2011, 17:07
Localitate: Cluj-Napoca
Nume caracter: Tudy
Zona de interes: World vs World

Re: Articole vechi ArenaNet

Mesajde Tudy » 24 Feb 2012, 23:44

http://web.archive.org/web/200502060818 ... 40802.html

Citat:
Game Cheats and Cheat Prevention
By Mike O'Brien & Gaile Gray

Introduction

Cheating is one of the most hotly debated issues in gaming today. What is cheating? Is a cheat ever “not really a cheat?” Does all cheating affect the game world in which you play, or are some cheats totally benign? Does “everybody do it?”

A cheat is defined as a process, a code tweak, an exploitation of a glitch, or a hack that allows the player to engage in behavior that isn’t intended within the context of the game. Cheating is exploiting weaknesses in the game’s architecture to, for example, allow a player to kill another player’s character where or when he should not be vulnerable; to have items that the character isn’t supposed to have, either through duplication of legitimate items or by means of taking items belonging to another player; or to know information that isn’t intended to be known, which gives the person using the cheat an edge in competitive play.

In this article we'll examine how players are able to cheat in online games, and how game technology has progressed over the years to address this problem. We'll explore in-depth how cheating affected some of the very games that we helped to develop. Naturally, our observations about cheats in these games would apply equally to other games that use the same network architectures.


Early Games: Townkill in Diablo

How susceptible a game is to cheating is largely defined by its network architecture. The easiest type of multiplayer game to program, and also the easiest type to cheat in, is an “asynchronous peer-to-peer game.” In this network architecture, each player’s computer is responsible for modeling his character and all of his character’s interactions with the world, and notifying other computers of the results.

One can compare playing an asynchronous peer-to-peer type of game to playing a game via the telephone. If a player says, “I hit you for 20 points of damage” and there are no means by which that amount of damage can be verified as possible and reasonable for the attacker to inflict, the other player has no choice but to register 20 points of damage. So if the would-be cheater finds a way to send a message claiming he has inflicted greater damage than is actually possible for his character to inflict, he can quickly gain experience points and reach godlike character levels.

A famous example of this was the Townkill cheat in Diablo. The starting town in Diablo was intended to be a safe zone where players couldn’t attack each other. However, even though it wasn’t possible to attack other players through the game’s user interface, hackers were still able to force the game to send a message over the network saying essentially “I hit you for 20 points of damage”. With Diablo’s network model, other computers in the game would simply accept the message and dutifully subtract 20 hit points from their character.

There were a few reasons why people used this cheat. One gamer we talked to explained, “Pking was so easy in Diablo, it got old. But when Townkill came out I loved killing them in town, it’s just totally unexpected, they’re like ’WTF?’” Another, referring to the fact that characters in Diablo drop their equipment when they die, stated, “It’s a way for me to get good stuff without the hassle of finding it myself.”

What is the solution to this sort of cheat, or how can it be prevented? This particular cheat was possible for Blizzard to address. Since players weren’t supposed to be able to do damage to each other in any way in town, Blizzard made the receiving computer ignore any incoming damage messages while it was in town. However, the hackers quickly adapted and created other types of cheats that Blizzard couldn’t address, such as the ability to walk into any dungeon level and kill everyone on that level. As the cheats became more sophisticated, the receiving computer couldn’t know for sure whether the message it was receiving was generated by a cheat or by a legitimate action of another player, so it had no choice but to accept the result.

Eventually, as most gamers know, cheating destroyed Diablo’s economy, and forced honest players to avoid playing with strangers. There were many games released around the time of Diablo that used the same networking model, and they were all susceptible to this type of cheating. Diablo merely had the distinction of being one of the most popular online games, which made it one of the most popular targets for cheaters.


The Next Generation: MapHack in StarCraft

Blizzard’s Warcraft and StarCraft games use a different network architecture known as ”synchronous peer-to-peer.”’ In this architecture, every computer models every player in the game. The computers don’t send messages over the network like “I hit you for 20 points.” Instead, they send only mouse and keyboard input, such as “I right-clicked on your character.” This makes it fundamentally impossible to use the same types of cheats that were prevalent in Diablo. You can’t send a message to another computer saying “I killed you” because no such message exists. You can only send a message saying “I clicked on you.” There’s no point in writing a cheat program to do that, since you could just as easily click your mouse to send the same message.

As you can probably imagine, programming a synchronous peer-to-peer game is tricky. When one player clicks on another player to attack him, both computers must model the attack in exactly the same way and produce exactly the same result. If they don’t, then the game will diverge to the point where it’s playing differently on the two computers, and it will never get back in sync because the two computers never share any information except mouse and keyboard clicks. To keep the game in sync, both computers must start the game at the same moment and with identical starting conditions, and then they both must process mouse and keyboard input from each player at exactly the same time. This makes synchronous peer-to-peer games slightly more susceptible to lag than other types of games, because if one computer is not able to communicate even for a moment, the other computers can’t continue the game until they re-establish contact.

Unfortunately, even a synchronous peer-to-peer game does not solve cheating. It prevents players from taking actions that they couldn’t have taken legitimately, because the only messages they can send over the network are mouse and keyboard input. However, it requires that all computers in the game share their mouse and keyboard input with all other computers in the game, and this means that hackers can develop means to expose information that the player isn’t supposed to know.

For example, a common cheat in StarCraft is called MapHack. This cheat takes advantage of the fact that your computer always knows what the other players in the game are doing, even though it doesn’t normally display that information to the player. The MapHack cheat modifies StarCraft so that it displays the position and action of every unit on the entire map, whether the player has explored that part of the map or not.

There are those who argue that since MapHack doesn’t involve actual “damage” to the opponent it could be called harmless. Unfortunately, the truth is that map hacking creates a severely unbalanced playing field which is as damaging to the play experience as any other type of cheat. If a player has a full map view, he can look into his enemy’s base and judge precisely what the player will be sending his way in the form of an attack. In StarCraft, if you see a few Stargates going up, you can anticipate that your opponent is going to attack primarily by air, whereas if you see a couple of Robotics Facilities and their Support Bay, you might anticipate a Reaver Drop. What’s even worse is that with map hacking, the victim often doesn’t know that the reason he lost the game was due to cheating.

Why do so many gamers use MapHack? As Patrick Wyatt said in his article last month, this seems to be another of those “I had to hit you first, before you hit me” situations. Many players seem to believe that “everyone uses it,” and feel that if they are going to compete on a level playing field they should use it, too.

We asked a StarCraft ladder observer how MapHack has affected the community. He told us that top players have adapted by playing games on local area networks instead of on the Internet. When players compete on a LAN, there are often observers watching them play, and “if the player uses MapHack, it will be seen at a glance.” When asked about the official StarCraft Ladder, his response was, “Oh, nobody cares about the StarCraft Ladder any more… it’s all rigged.” This is just one person’s opinion, of course, but others have speculated that without observers, it is possible that any or all ladder players could be using MapHack and there is little that can be done to prevent its use.

Any game that uses a synchronous peer-to-peer network architecture is susceptible to map hacking. Since Blizzard can’t prevent map hacking in StarCraft, some have proposed that they level the playing field by including it as an option in the game setup screen, like “shared vision” or the choice of map. However, playing with the map revealed removes much of the strategy from the game. Blizzard may not be able to stop MapHack, but they’re not willing to embrace it, either.

Another concern with peer-to-peer games is that, since the computers communicate directly with one another, each player’s IP address is revealed to everyone else in the game. A sophisticated hacker can trace these addresses to find the real life identities of his opponents, sometimes even to the point of obtaining an address or phone number. Furthermore, if the victim’s computer hasn’t been patched with the latest security updates from Microsoft or Apple, a malicious hacker could attack the computer with the goal of crashing it, destroying important data, or accessing personal files.

This privacy concern has caused many companies to reevaluate the viability of producing peer-to-peer games. For Warcraft III, Blizzard is using a modification of the synchronous peer-to-peer architecture called “hosted peer-to-peer”, in which messages from one player to another are bounced off one of Blizzard’s servers rather than being sent directly between computers. This change doesn’t impact cheating, but it does prevent players from seeing each other’s IP address, which eliminates the privacy problem.


A New Kind of Architecture

The synchronous peer-to-peer networking model comes close to solving the cheating problem. Since computers only send mouse and keyboard input over the network, there is nothing that a player can do to give himself greater abilities than the game intended him to have. The remaining problem is that computers see too much information about what the other players in the game are doing. Is there a type of network model that would address this? Yes there is, and it’s called client/server.

In a properly written client/server game, computers still send only mouse and keyboard messages over the network, but they now send that information to a single server, rather than sending it to every other player. The server is the only computer that knows what all players in the game are doing, and knows the entire state of the game. The server then sends back to the clients just those events that they should be able to see. This way, the clients can’t do anything they’re not supposed to do, and they can’t see anything they’re not supposed to see.

Of course, the server can now do anything and see everything, so all of the players in the game must completely trust the person running the server. Games like Quake and Half-Life use a client/server network model and place no restrictions on who may run a server. When players connect to a server they haven’t used before, they will sometimes discover that the server operator is cheating. He may engage in obvious cheats, like summarily killing players he doesn’t like, or he may engage in subtle cheats, like giving his friends a slight advantage in combat. Either way, it is up to the players to discover that the server operator is cheating and stop playing on that server.

It would be much more damaging if a role playing game used the client/server networking model without restricting who could run a server. Role playing games usually center around character development, where players play the same character over many games, advancing his skills and finding new items for him to use. If a player connected to a server that was being run by a cheater, then the server operator could potentially steal all his items, or otherwise destroy his character, before the player was able to identify that the server was cheating and disconnect. Because of this possibility, when role playing games use the client/server networking model, they typically do not allow untrusted players to run their own servers. Instead, they use what is called a “hosted” environment, in which the game publisher uses its own computers as servers.

As you can imagine, setting up a hosted environment is both challenging and expensive. Depending on the popularity of the game, it may involve purchasing hundreds of computers, and operating them in data centers around the world. In addition to buying all the computers and hiring a staff to keep them all running, the game publisher must also pay for all of the bandwidth that they use. Despite the effort and expense, the industry is moving more and more in this direction, because it’s the only way to approach the ideal of a cheat-free environment. Examples of games that use a hosted client/server architecture include Diablo II, EverQuest, Ultima Online, Asheron’s Call, and Dark Age of Camelot.

Even when the game developer uses a well-written client/server networking model and controls all of the servers, it is still possible for cheating to occur, simply because games are written by humans, and human programmers will always make subtle mistakes that malicious users can exploit.

The most notorious type of cheating that takes place in hosted client/server games is item duping: taking a valuable item in your inventory and making an exact copy of it. To do this, players find and exploit a bug in the program. For example, they may try unusual combinations of actions that they don’t think anyone has ever tested before, hoping to find something they can do that will crash the game server. If they can find a way to consistently crash the game server then they can often use that knowledge to duplicate items. To do so, they simply hand a valuable item to an accomplice, who then immediately logs off, causing his character to be saved to disk. Then they crash the server before it has an opportunity to save their own character to disk. When the server comes back up, both players should have the item in their inventories.

In an online role-playing game, the most involving facet of character development and item acquisition might be rarity. It is rare to see a character over level 100 in Asheron’s Call. It is unusual to come across someone who has the entire Astrilite Set in Dark Age of Camelot. You don’t usually spot a character with +500% Magic Find in Diablo II. Being able to develop special characters, and having the ability, time and luck to acquire items that are rare and unusual, are two of the more rewarding aspects of a game. These two things set a player apart from the norm, and give him certain “bragging rights” in the game world.

When duping runs rampant in a game, suddenly the rare item that a player acquired legitimately is nearly valueless. Everyone in Diablo had the Royal Circlet; everyone had an Obsidian Ring of the Zodiac. In Asheron’s Call, the original Greater Shadowhunter Armor was removed by the developers because it was determined to be too powerful for the game. The removal created an even greater demand for this rare item, driving prices on eBay up to $500. However, heavy duping eventually destroyed the rarity of this item and forced the developers to return it to the game, so that the cheaters would not have a continuing unfair advantage.

So the greatest injustice perpetrated by those who cheat is that they destroy the game world’s economy for all players. And once corrupted, it is impossible to salvage the delicate balance of a game world’s economy and return to character development and item acquisition the value and the significance they once held.

Item duping can be solved. At one level, since it relies on players exploiting bugs in the software; it can be solved by fixing those bugs. At a more fundamental level, game designers can change the way characters are saved to disk, or the way items are assigned to characters, so that even if a player can crash a server, he can’t exploit that fact to duplicate items.

This is typical of the types of cheating that are possible with hosted client/server games. The client/server network model is the most secure that we as game developers have available to us. It isn’t fundamentally susceptible to cheating like other network models are. At the same time, it doesn’t guarantee a cheat-free game.

Mistakes in game design and implementation can always creep in and enable unforeseen types of cheating. At the end of the day, game developers need a lot of experience with network gaming so that they can foresee and avoid these problems, and they need to be able to quickly react to and fix problems that crop up after the game is released. At ArenaNet, we are committed to keeping cheat prevention and cheat resolution as one of the primary objectives of our game development process.
-------
I want to live forever. So far, so good.
GW2 Official Wiki - GW2 Wiki FAQ
Imagine
Avatar utilizator
Tudy
GW2.ro staff
 
Mesaje: 1401
Membru din: 14 Feb 2011, 17:07
Localitate: Cluj-Napoca
Nume caracter: Tudy
Zona de interes: World vs World


Înapoi la Discuţii generale

cron
Utilizatorii ce navighează pe acest forum: Niciun utilizator înregistrat şi 3 vizitatori