Bowling Bash

Graphics cards on Ubuntu

noreply@blogger.com (gentimouton) — Sat, 11 Feb 2012 20:21:00 +0000

Problem

My configuration: Lenovo T410, Ubuntu 11.10, Nvidia GT218.

OpenGL does not seem supported by default. Running nvidia-settings in a console says You do not appear to be using the NVIDIA X driver. Please edit your X configuration file (just run `nvidia-xconfig` as root), and restart the X server..

After following these steps, the environment does not show up anymore when rebooted - only a console-like frozen screen. An actual command-line console can be found using ctrl+alt+F1 to ctrl+alt+F6. Ctrl+alt+F7 goes back to the console-like frozen screen. The screen is frozen most likely because the x server did not start.

It turns out the actual problem is the hybrid graphic card configuration. Hybrid cards configurations for laptops have 2 cards: one for performance (e.g. Nvidia GT218), and one for battery life (usually integrated graphics, e.g. from Intel). The switching is supposed to be done automatically by Nvidia's Optimus software. But Ubuntu 11.10 does not support, by default, the switching between integrated graphics and Nvidia graphics.

Quick fix: to discard permanently the integrated graphics, in the BiOS (F1 at computer startup), pick Config > Graphics > Discrete. Problem: heavier battery consumption, and Windows, which is has no problem using Optimus, will now be forced to use only Nvidia. Not good.

Fixing the problem: Bumblebee

Bumblebee is a solution for Optimus on Ubuntu, and they have a tutorial to set it up. But in case it one day disappears, here are the steps.

1) Check hybrid config and support

Determine graphics card(s): lspci | grep VGA


00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02)

01:00.0 VGA compatible controller: nVidia Corporation GT218 [NVS 3100M] (rev ff)

So there's an Intel integrated card and an Nvidia GT218 card: that's a hybrid configuration. Check Nouveau's supported cards to see if the opensource driver supports your card. If it does not, maybe the proprietary Nvidia driver supports it?
Anyway, the next step is to check that the Nvidia card is not doing its part; run glxspheres. This outputs:


Polygons in scene: 62464

Visual ID of window: 0x97

Context is Direct

OpenGL Renderer: Mesa DRI Intel(R) Ironlake Mobile 

21.494593 frames/sec - 23.987966 Mpixels/sec

21 frames/sec is quite lame, so Nvidia is most likely not picked.

2) Installing Bumblebee 3.0 (as of February 2012)


sudo add-apt-repository ppa:bumblebee/stable 

sudo apt-get update 

sudo apt-get install bumblebee bumblebee-nvidia 

sudo usermod -a -G bumblebee $USER

sudo reboot

3) Testing

Any program to be run with the Nvidia card should be prefixed by optirun; for instance, optirun glxspheres outputs:


Polygons in scene: 62464

Visual ID of window: 0x21

Context is Direct

OpenGL Renderer: NVS 3100M/PCI/SSE2

101.341234 frames/sec - 113.096817 Mpixels/sec

Although it takes a tiny bit of delay for the program to start, it's much better than the 21 fps of earlier. Running optirun -c yuv glxspheres shows even better performance (145 FPS). But the CPU consumption remains high: Bumblebee only has the Nvidia card compute 60 frames per sec and send those frames to the Intel card anyway.

References

Unity and games don't work on new Thinkpad T420
Thinkpad T520 - problem detecting nvidia card after enabling it after installation
Bumblebee FAQ explains how the two cards share a frame buffer.
.desktop files: To launch an application using optirun without having to type it in a terminal, edit the .desktop file of that app, located globally at /usr/share/applications and locally at ~/.local/share/applications (make the folder if it does not exist).

Influence - Cialdini, 1993

noreply@blogger.com (gentimouton) — Wed, 08 Feb 2012 04:47:00 +0000

Weapons of influence

Fixed-action patterns: the response behavior always happens in the same way. We're interested in the trigger of that response. Most of the time, the trigger is valid, but sometimes it's misleading. This response is triggered because the load of information in our society is too big for our lazy brains, and we need shortcuts.

Give a reason/explanation when asking a favor; it increases its chances of being accepted. "Let me pass you because I'm in a hurry."

Expensive = good. Make the customer think "it's a bargain!". Pretend to discount an item from $100 to $50 while the actual price really is $40.

Contrast principle: When buying a $30k car, a $1k radio does not seem like much. Show a $500 suit first, then a $50 shirt to make the shirt look cheap. Also works the other way: clients won't buy if you first show the cheap item and then the expensive item.

Reciprocation

Reciprocity rule: We feel obliged to return favors because society looks down on ingrates. You can increase compliance by providing ... a small favor prior to a request. Benefactor-before-beggar strategy.

Why it works: The reciprocity rule promotes the initiation of trade without fear of loss. It is too socially beneficial for us to want to violate it. It's also hard to reject gifts, even unwanted ones. Since society looks down on ingrates, feeling obliged is disagreeable, and that makes us ready to give a lot to get out of such a disagreeable situation. Examples: political favors, "you don't bite the hand that feeds you".

Concessions: the basis of trade and negotiations. Example: Boy scout in the street sells expensive lottery tickets for $10 apiece. When we tell him no, he asks "what about a $1 lemonade then?". We're likely to say yes because we think he did a concession to us. Add the effect of the contrast principle: $1 is nothing compared to $10.

Commitment and consistency

Once we make a choice (e.g. bet on a horse, or pick one of two lovers), we stubbornly stick to it and back it up ("despite all his flaws, he has lots of qualities").

Why it works: Lazy brains use consistency so that they don't have to re-evaluate a decision all the time. We are under pressure to bring our self-image into line with our past actions. Hence, any request that goes in that direction will be accepted. Example: Phone call and ask people how they're doing. They answer "Great!". They just made a commitment. Continue with "Glad to hear it, because I'm calling in support of a charity for Orphans in Hospitals during Christmas ...".

Foot-in-the-door strategy: sell an undervalued item to transform prospects into customers. When they realize that they are customers of yours, they will come back to buy any item, even overpriced ones, by self-commitment.

Active, public, and effortful commitment is the most effective at changing the self-image. We accept responsibility for a behavior when we think we've chosen to perform it in the absence of strong outside pressures (ie rewards or threats did not justify the participation, yet you participated). Examples: Customers who write the sales contract down themselves are less likely to cancel orders or ask for refunds. Undergrads who choose to endure a fraternity hazing convince themselves it was worth it.

Low-balling: Promise people a reward (e.g. money or fame) if they do something repeatedly (e.g. save energy, take out the trash), and cancel that reward after a while. They are likely to keep doing it because in the meantime, they have built other reasons to support their new image (e.g. "I am the kind of person who saves the planet or helps someone").

Social proof

We find correct what people similar to us find correct (social evidence). Example: canned laughter in TV shows to signal that it's funny, or herd behavior.

Pluralistic ignorance: Lots of people, none of them knowing what's going on, are all looking at each other for clues of what to do. Since they can't find any, nobody does anything because everyone wants to stay poised in public. Even more efficient when people are in unfamiliar contexts (e.g. abroad or in fancy receptions).

Liking

Tupperware parties and obligation of friendship: people twice more likely to buy because from a friend than because the item is useful. Door-to-door marketing: simply mentioning "your friend X recommended you to us" is enough: turning the sales person away ... is almost like rejecting the friend.

We like and are more likely to favor good-looking people and people similar to us. We generally believe compliments and those who give them.

Cooperation: when cooperation is required to achieve common goals, and each party has a part of the solution, it can turn enemies into collaborators, and then friends. For example, Bad Cop puts pressure on the interviewee, so that Good Cop looks like he's cooperating with the interviewee, and makes him comply with his requests.

Association: we hate people who bring bad news, and we tend to prefer products who are advertised by good-looking people. The association does not have to be logical, just positive. See also Pavlov's dog. Similarly, when our national team the soccer world cup, we feel associated with their success: "we won!". But when the team loses, "they lost!". We are particularly eager to bask in reflected glory when our image has been recently diminished.

Authority

Milgram experiment and its addition: instead of a single authority figure asking to give shocks, have two authority figures giving conflicting orders (shock vs don't shock). The subject tries to see who is the boss of who.

Clothes and titles: an actor disguised as a doctor in a TV ad gives more credibility to the medicine. Security guard uniform doubles the rate of people who give a dime to another person for parking. When jaywalker in business suit, people are more likely to mimic him.

Important things and people are seen as taller. Yet the more a category of people is concerned by a mark of authority (e.g. students by teachers, or males by cars), the more that category underestimates the authority's impact on them.

Scarcity

We are more motivated by not loosing something, than by gaining something of equal value.

Reactance: as we're losing opportunities, we feel like we're losing freedoms. Since we hate losing freedoms, especially those most recently acquired, we'll fight to keep them. We'll also give those freedoms more importance or qualities than before. Example: 2-year-old kids discover they have a body of their own (a form of freedom newly acquired). They'll say no to everything to check their new boundaries. Same with teens realizing they can be independent of their parents: they fight parental authority.

Scarcity works on objects: ban phosphate use and people start finding it more useful. It also works on persons: cf the Romeo and Juliet effect: because their parents forbid it, their love is bigger. It also works on information: tell supermarkets that beef is scarce and that it's rare to know that beef is scarce increases sales by 6x. It also works on rights and ideas: forbid a book to minors and 1) they want to read it more, and 2) more of them think they're going to like it.

Temporal scarcity: examples include "available only this week" or pausing a face-to-face conversation to take a phone call because "he may not call again!". Being put in competition with other people (e.g. auctions) is even more efficient.

Scarcity creates a desire that has little to do with the merit of the commodity. The joy is not in experiencing a scarce commodity, but in possessing it.

Scaling League of Legends

noreply@blogger.com (gentimouton) — Fri, 03 Feb 2012 20:57:00 +0000

Notes from a 2011 Qcon talk about scaling the non-gaming server side of League of Legends. They are not worried about persistence during a game, but rather in the match-making, lobby, or store. They have soft real-time requirements: not the order of 10ms, more the order of a few seconds. [Twitter and Facebook are soft RT too]

Scaling

Scalability: it's easier to constrain what the logic developers are allowed to do, than to define what they are not allowed to do. Examples: Map/Reduce is a whole paradigm (you have to make your logic fit into a map() and a reduce()), NoSQL's unstructured data is a double-edge sword (you lose the ability to join, but queries come back faster), and when you're partitioned, you pick to be either atomic/consistent or available

46:50: Scaling should be dynamic/elastic; you need cluster recomposition and stateless growth patterns. Hence the system should be dynamically configurable. On the fly, you should be able to adjust the thread pool size, add/remove roles to machines, and switch logic or system algorithms.

Food for thought: list all the benefits/tricks a load balancer can provide to your system.

Caching

Caching provides flexibility: failovers, distribution of workload (hot code updates or restarts). Coherence is a distributed cache used between Hibernate and the DAO layer as "cache-through". If the DAO asks Coherence and there's a cache miss, then Coherence asks Hibernate (itself using a Coherence cache, or calling MySQL over the network if cache miss).

24:00: How to be sure that cache and DB are consistent? Do not cache! Query the DB directly, latency of few sec is OK for soft RT.

11:30: Serialize the work, not the data. It's faster to serialize the work to the data, than to unserialize the data, work on it, then serialize the result. Avoid moving the data all over the network towards where the process is. It's also easier to distribute the work to all the DB nodes than to send to/receive from all the nodes.
The objects sent on network between server and DB should be small: if you have to edit only one field, you should not have to send a big object of 1MB.

Logging and Testing

42:30: They log each function call with how long it took; overhead of 1% performance, but huge value if able to graph/plot the logs. Compare the average call duration in the last few minutes to the usual average to detect problems.

17:15: Keep in mind that the code will be used/executed in a data center, not on your laptop. 51:25: They use EC2 for load testing. 1000 threads per node, each thread simulating 1 user. Realistic because not all clients (threads) are same speed in real-life, and EC2 network is not always the best/reliable. It's not the most performant, but it looks like a quick-and-dirty way to load test. One of their scale testing environment has more than 50 machines.

Event Manager and MVC

noreply@blogger.com (gentimouton) — Wed, 01 Feb 2012 06:47:00 +0000

After mentioning MVC a few times, I've stumbled, like many others on Sandy Brown's pygame guide. The guide contains three parts: MVC for single-player games, using Twisted for multiplayer games, and GUI widgets. You can also find the code on github.

Event Manager

The problem: Multiple heterogeneous components, say the network controller and the model, are interested in an event such as a user click from the input controller. The code in the input controller would look like this:


nw_ctrler.send(click)

  
model.perform(click)

If a new component, say the audio output, becomes interested in user click events, then the input controller code has to be modified. This is not ideal.

Two design patterns exist to help us here: the observer and the mediator. The differences between the two are very subtle , but combining the two allows 1) the possibility to add or remove components from the system without touching the other components, and 2) a component to notify all the others through an intermediate. In our case, an Event Manager is the intermediate receiving events from all components, and notifying those interested in that event. See the diagrams below from Sandy Brown's guide.

Improvements

A stackoverflow post remarked that isinstance() is not quite Pythonic : instead of using isinstance(), one should appropriately use duck-typing.

Moreover, listeners should tell the Event Manager which events they are interested in, so that they are not notified for all of the events.

MVC and modularity

noreply@blogger.com (gentimouton) — Fri, 30 Dec 2011 02:11:00 +0000

More on the MVC pattern.
I wrote in September 2011 about which type of MVC would be more appropriate to make games, but this was all quite abstract. Here are more concrete thoughts, after having had to implement it myself using Pygame. But first: a diagram!

Main loop

Pygame provides a ticker that regulates the game loop with a 10-ms precision. The elements that need to be awaken by the game loop are colored in pink on the diagram above. In more details, they are:

Mechanics: Some events independent of the player have to be triggered at some points. For instance, the screen could turn red after 5 minutes in a scenario, the player's money could generate interest every 10 seconds, or monsters' AI needs to process the game state to determine what to do next every 50ms in fight mode but every second in idle mode. That's why your mechanics have to be called every loop iteration.
Renderer: In Pygame, this corresponds to blitting sprites onto the screen, and then flipping the screen, and/or playing sounds. With the architecture displayed above, the frame rendering rate (say, 60 FPS) is independent of the main loop frequency (say, 100 iterations per second). This is useful for machines with a decent CPU but a weak graphic card because the view could be configured to refresh the screen only 30 times per second, but the logic could still run at 60 or more iterations per second. But there's more! since the renderer accesses the game state, it can determine if the load is going to be too heavy with 30 fps, and decrease the frame rate gracefully without having to slow down the mechanics or input controller.
Input Controller: events such as clicks or keys pushed are processed one after another during each loop iteration. The input controller then sends a translated version of these events (e.g. 'Q' stands for stop the game) to the Main Controller (e.g. MainController.stop_game()).
Network Controller: events may be sent by the server at any time. The client may also need to send actions to the server at any time. Therefore, the network controller is called every loop iteration. This is done using PodSixNet: ConnectionListener.Pump() for the pulling and EndPoint.Pump() for the pushing. Under the hood, PodSixNet uses asyncore (which apparently calls a normal poll).
Note: When the network controller needs to send a part of the game state on the network, it calls the Main Controller to return him the data from the game state itself.

Keys vs Clicks

When the player pushes a key, the scenario is very easy to follow:

Input controller translates
Main controller calls the appropriate mechanics
Mechanics update the state
Next frame, the renderer displays the state.

The scenario is slightly different for clicks.

Input controller receives click type (left/right/middle/both/...) and click position (x,y)
Input controller gives the view controller the click type and the position.
From the click position, the view controller parses the list of sprite coordinates and dimensions to detect which sprite(s) has been clicked.
For each click type, the clicked sprite has a callback to the main controller. This callback was set by the view controller when the view as a whole was created. Hence the solid arrow from view controller to main controller (true dependence), and the dotted arrow from sprites to main controller (blind callback set by another component).
Main controller calls the appropriate mechanics, etc.

How good is this?

From the two scenarios above, I see at least two aspects of this architecture breaking the traditional MVC. First, the view is not selected by the controller. Rather, the view looks at the model to know what subview or view mode to switch to. For instance, if I push the escape key, my MainController will ask the model to store it, and the renderer itself will decide what to do with that new information stored, whatever it means for the model.

Second, clicks require the controller to ask the view what those clicks mean. I was at first reluctant to affect the button behaviors dynamically because it decreases understandability. When you read the button code, you don't know what the button is doing at all. In fact, all you see in the code is a raise(NotImplementedError). You have to go look inside the view controller to see what is being affected to that button's on_left_clicked(). On the other hand, the gain in modularity is pretty sweet: you can change the presentation of an object, whether in the HUD or in the game world, independently of its logic. If you want to try another view (say 3d instead of the current top-down 2d), then that new view only needs to provide 2 "services": render() for the main loop, and process_click(pos,type) for the input controller.

Edit 31 Dec, 2011: Just saw this example from Shandy Brown on using the Mediator pattern as a middle-man that views and controllers pubsub to. I like the "loggers as views". However, I'm not sure the clock-triggered events should be in a controller; the model should have some game logic in it.

Play Money - Dibbell 2006

noreply@blogger.com (gentimouton) — Wed, 21 Dec 2011 00:29:00 +0000

Play Money, Dibbell, 2006

Notes from the book, re-organized in sections by myself for easier summarizing and reading. Below, UO stands for Ultima Online, and OSI stands for Origin Systems Inc, the game company who developed and ran UO. OSI was owned by EA.

Playing

Players keep playing because they want to go up the player ladder the same way RL people want to go up the social ladder. At some point, you have to decide either to leave the game cold-turkey or to give the game a point: make it productive. Giving the game a point is easier because the game is addictive. Although flow happens 3 times more often at work than during leisure times, play makes flow more enjoyable.

Huizinga: play has always been part of society. Weber: the Protestant Ethic of Puritans considers productive activities as recommended by God, and sports and leisure as wastes of time. Capitalism principles come from Ethic of Puritans, hence a capitalist society considers play shameful. Dibbell: Games are symptoms of post-modern rampant abstraction and transformation of wealth creation. Marx: solidity melts into air. Dibbell about games: production is melting into play.

Troy Stolle is a RL carpenter who played a grandmaster blacksmith. When fired IRL, he decides to sell his 52-month old account on eBay for $500, when the account is going to be resold for $2k. He thinks it's all fake anyway and does not realize there is demand for virtual items.

Being part of UO's virtual economy

Virtual economies require and implement constraints and scarcity. Castronova: in MMOs, scarcity breeds market, and markets cross realities at their onset. Dibbell realizes there's a complex supply chain of warriors who drop, artisans who craft, hagglers who buy/sell IG, brokers who buy/sell on eBay or on their own website, and finally the clients. Example of a client: a Mum buys a $25 virtual item for her kid's Christmas. Why people sell for so low is the mystery that lies at the center of market economics: it generates profits at all levels of the chain.
Lesson: Theory of ludocapitalism, where play is a latent force waiting to be tamed the same way steam was the energy of the industrial revolution.

Julian Dibbell: born 1963, starts playing UO in early 2003. Weekly play time: 20 hours per week. First step in the economy: farming and selling batches of leather suits to another player. He Starts a blog in March 2003 to track his business adventures. A journalist VIP pass grants him earlier access to maps of the next update; he uses it to avoid the rush on new houses and buy 2 houses. Why keeping an uber house worth $600? I wanted to be envied. He accepts to share his house with a 17 year old kid, who sells IG some items for him and brings him a small profit. Unusual/weird "friendship". He plans to sell the other house for 30m gold, but a famous player on his shard asks for 20m and he accepts, honored and intimidated.

IG runebooks let players memorize places to teleport to them later on. Memorize all the mining spots in that book. Once the spots have been written in the first book, duplicating that book takes little time. Dibbell sells each book $3 on eBay. He quickly realizes this is too little profit for too much time spent. Some "rares", on the other hand, can sell on eBay for $75. Rares, along with other luxury items such as hair dyes or houses, are often only sold by NPCs to implement gold sinks.

Although virtual economies enable players to bond, when you get too deep into it, you're not a player anymore. The social aspects and the fusion with fiction disappear. Yet vendors of virtual gold are still immersed in some ways: Dibbell has no idea what he's doing at DiGRA or State of Play, talking about virtual economies and law, because he's more eager to live in [MMOs] than to understand them. He has self-doubt and wonders if the study of virtual economies has an intellectual substance about as substantive as pot smoke.

Scams and (lack of) protections:

Kids buy from their Mum's PayPal or credit card and receive the item within 15 mins. After a day or two, Mum reverts the transaction, but the player still has the item in his inventory, or even sold it to someone else.
Scammer advertises selling an item for half its market value. When buyer comes, the scammer sends him a link to a Paypal-looking phishing website in an email, and then empties the buyer's Paypal account.
A seller advertises a rare item. Using a thief character, another player goes to the seller's house, steals the item, and sells it IG or on eBay. Dibbell knowingly buys from the thief: in-game robbery is part of the game.
eBay and Paypal do not provide insurance over "intangible" goods. They provide insurance for soccer match tickets, presumably "tangible". Still, they say they can't insure a real paper ticket with a code written in real ink for virtual gold.

In 2004, the IRS said:

Declare as income anything you receive IRL, be it work of art, real dollars, or virtual gold. Illegal income such as stolen or embezzled funds must be included [...] if from your self-employment activity
For normal players, prizes won in lucky number drawing must be included in your income at their fair market value
Organizations that facilitate the trading of goods and services, such as OSI with virtual gold, should send tax forms to and withheld taxes from its players.

In 2005, an IRS specialist on the phone said there's no legislation yet on Internet barters or virtual economies.

UO vendors

IRL, dozens of monetary startups create "fake" money. E-gold backs their virtual currency with real gold stored in private vaults. An artist draws custom dollars and sells them, as art pieces, for more than their face value. Dibbell: We live in an age of money hackers. Make-believe [is] required to establish monetary value.

Blacksnow Interactive is located in Orange County. Business model: gold farm of 8 Mexicans in Tijuana, Mexico, paid $19/day, generate $30k profits per month. They play according to scripts given to them daily by their on-site supervisor. $800k sitting in inventory. Blacksnow trialed Mythic after they asked eBay to shut down Blacksnow's DAoC's gold auctions. Too bad Blacksnow vanished after being trialed by another game company, because justice would have had to determine who owns the IG wealth: players who spend the time, or companies who make and own the games?

Bob Kiblinger used to work as a chemist with decent pay. After playing UO nights and weekend, his wife divorced him. He bought and resold Troy Stolle's tower to Dibbell. Bob is a popular broker with 10k+ ratings on eBay. Has list of furnishers for each shard on IM. Spends 14 hours per day trading accounts and items. Belongs to the Markee Dragon conglomerate of the top 7 UO brokers. Markee Dragon provides server transfer, lets you pay your game time by gold instead of real dollars (they own the account and pay it for you), and brokers IG gold. Markee Dragon's ethics say: don't buy from bot farmers because they cheat. In 3 months of 2003, Dibbell bought $3700 of discounted gold from bot farmers, so he felt kind of unethical. Later, Rich the bot farmer gave him the list of his top 10 clients for 2003: Dibbell is 10th, all Markee Dragons belong to the top10, and number one is Bob who bought a total of $35k of gold in 2003.
Lesson: you need to buy from bot farmers to make a living in the US as a gold broker.

Using DeepAnalysis, an eBay market research tool, gives the market state and the list of vendors in a particular eBay category:

Weekly sales of UO items and accounts: $160k
Yearly sales of UO items and accounts: $4.2M
Change rate: $16 for 1M gold

And there are other sources of revenue for vendors that are not visible on eBay:

buy whole accounts for $300 and sell all the items in them for a total of $1200 = 400% profit
IG gold suppliers run big malls
A Guild has the monopoly on mining spots in a shard. Its guild leader sells gold to his broker.
Camp houses that will soon be re-opened for sale because their owner has not logged in for a long time. Can be done with a bot. Then resell houses for a lot of gold or dollars.

Working for Bob, in a solitary and obsessive interlude of 3 weeks in mid 2003, Dibbell made $1100 of sales by taking his share on buying and delivering suits on his shard. In the next 3 weeks, he only dedicated 2h/day selling packs of 100k or 1m gold and suits on eBay or to Bob. His sales remained around $850 per week. On average, brokers make 20% profit from their sales. After 3 months, Dibbell made $800 profits and ranked 65th out of 800 in terms of sales of eBay UO vendors. Bob is ranked first with $8k sales and $2k profits per week. Dibbell compiled those results thanks to the DeepAnalysis tool.

Gordon, a Cantonese exec, just opened a 10-man gold farm. He asks for partnership with Dibbell and Bob: his farmers would bring items that Dibbell and Bob sell to clients, and they all share profits. Predictions of $1600 sales per week. Gordon says he pays his farmers $1.5/hour and they can generate $5/hour. However, a NYTimes article in 2005 revealed that Chinese farmers are usually paid $75/months in 12-hour shifts, ie less than 30 cents/hour. Anyway, Gordon never generated the profits he mentioned. However, Dibbell, on a road-trip from Indiana to California, reached a max of $1k/week of profit for 4 weeks, mostly only selling 1m gold packs.

Bot Farmers

The game allows the use of a macro API provided players stay in front of the screen. Bots use macros on exploits such as 1) buy clothes from NPC 2) tear down clothes into tissue using basic tailoring skill and macro 3) sell tissue for more than the clothes. This technique generates 350k gold per hour. A Georgia man used it and amassed 20b gold, ie $300k. The total wealth of UO on all English shards was estimated at 35b, hence huge inflation wave coming up and detected by GMs. OSI fixed the exploit and wiped the extra gold by banning the bots.

Richard Thurman: 30 year-old software engineer. Leads the hacker group who developed EasyUO, a UO bot program. Rich's bots on 20 machines brought him 60k gold per hour using cartography exploits. Competitors denounced him to GMs and he was banned. Came up with a more defensive strategy: 1) eBay is too risky, hence build network of IG wholesale gold buyers. They get gold for 40% less than the eBay price. 2) to check for bots, GM wear a colored stick and ask the player "what's the color?". The bots would IM or SMS Rich when they were faced with a GM, and receive text to say to the GM by IM or SMS from Rich. 3) Plug A.L.I.C.E so that bots talk by themselves.

Blacksnow's leader and Rich meet in October 2003. Blacksnow proposes to agree on gold prices in return of receiving a dll used by EasyUO. Rich says it belongs to his group and refuses. Blacksnow discovers the hacker group had been blackmailed in the past by a player and had had to give the dll to the blackmailer. Pissed, Blacksnow reports Rich's bots to GMs.

An updtate from OSI on the merchant NPCs implements an offer-and-demand scheme, but assumes that players won't buy more than 500 items. Rich and another bot farmer find the glitch: buy 2k items at a time, the NPC believes you only bought 500 so the price does not increase as much, then resell the 2k items for small profit. Bot farmers use the exploit for a while, making millions of gold per hour. Blacksnow finds out they're making a lot and blackmails them for their technique against not denouncing them to GMs. The 2 farmers decide to stop their scheme and tell OSI about the exploit so that no other benefits from it. They made a total of $150k profit from 20b gold.

PS: Dibbell thinks that designing a single-shard MMO for 100k players is an impossible dream, and that's why MMOs stay sharded.

Netgames 2003

noreply@blogger.com (gentimouton) — Fri, 02 Dec 2011 07:16:00 +0000

Modeling player session times of online games, by Chang and Feng

network traces of a popular CS server for a week in April 2002
16k user sessions recorded
99% of players play less than 2 hours
play session follows a Weibull distribution with k = 0.5 and λ = 20 (shape similar to 1/x exp(-x))
For play sessions from 10 to 100 minutes, the chance of disconnecting (ie failure rate) remains constant at 2.5%.
For play sessions shorter than 10 minutes, 10% chance of disconnecting. Possible reasons: connection problems, kicked out or leave because of server rules (such as friendly fire allowed, but kicked out if you kill your team-mates too often)

A Fair Message Exchange Framework for Distributed Multi-Player Games, by Guo et al.

Assumptions: independent clocks with no synchronization mechanism, players react to server updates, updates only consist of creation and/or removal of object(s) (and NOT object position updates)
Users have reaction time to act in response to server update messages. Ignore latency induced by network and only compare user reaction times to determine which update to actually run on the world state.
the Fair-Ordering Service [...] dynamically enforces a sufficient waiting period on each action message to guarantee the fair processing of all action messages. But practically, the waiting period is bounded to ensure a relative level of interactivity.
Proxies are game-agnostic and located near players (ie low latency between a player and her proxy). Proxy receives action message from user, then forwards that action message with a message identification number (to deliver messages in order) and the reaction time to the game server.

Causality and media synchronization control for networked multimedia games: centralized versus distributed, by Ishibashi et al.

Causality control preserves the order of events of game data (keyboard inputs). No need for causality in voice or video
Media synchronization control = intra-stream (temporal relation between MU such as voice or video packets) + inter-stream (timing among multiple streams) + group (timing among multiple end-points to ensure fairness) synchronization controls
Compare C-S to P2P architectures in terms of success of the 4 previously mentioned control schemes. Voice and video don't need to go through the server (they're sent in P2P mode in both scenarios).
Adaptive Δ-causality control used on game data in both scenarios: the recipient considers a packet still valid Δ = 50 ms after its generation timestamp. [That means the latency automatically increases by Δ ms for all packets]. Adaptive means that the value of Δ changes based on the network load. Smaller Δ = game more interactive, large Δ = less packets are discarded for being late/misordered. Unfairness appears when terminals have different Δ, hence need group sync control.
Piggy-back an MU on the succeeding k=4 MUs to recover from lost UDP packets
Experiment: two terminals in both C-S and P2P scenarios [only two?!]. Terminal 1 is connected to an overloaded hub with delay jitter, Terminal 2 is connected to its own hub. Connections are 10 Mbps ethernet. Server connected to T2's hub. Additional delay of 100 ms introduced between the two terminals by a data link simulator between T1's hub and T2's hub. Game MUs = 20 Bytes, sent 10 times per second, while voice MUs = 400 Bytes, sent 20 times per sec, and video MUs = 5kB, sent 20 times per sec [hence most of the load on the network comes from voice and audio, not game data]. Experiment ran for 2 minutes.
For heavy loads (8Mbps), C-S is better for causality, but worse for consistency, fairness, and interactivity.

Bandwidth requirement and state consistency in three multiplayer game architectures, by Pellegrino and Dovrolis

Compare C-S, P2P and PP-CA (= P2P with central authority/arbiter receiving moves from all players and notifying them when it detects inconsistencies)
Tu = Duration of client loop, Lu = size of update messages
CS: client upstream = Lu/Tu, client downstream = N.Lu/Tu, server downstream = N.Lu/Tu, server upstream = N(N.Lu)/Tu
P2P: client upstream = client downstream = (N-1)Lu/Tu
PP-CA: client upstream = N.Lu/Tu, client downstream = (N-1).Lu/Tu + f.N.Lu/Tu with f = ratio of inconsistencies to be corrected, arbiter downstream = N.Lu/Tu, arbiter upstream = f.N(N.Lu)/Tu

Access network delay in networked games, by Jehaes et al.

Look at delays introduced from access networks (aka last mile links), not from back-bone. Goal: how to dimension the network to reach minimum delay possible.
Network delay can be caused by propagation (mostly only in the case of back-bones though: 5µs/km), serialization (putting all the bits of a packet on the link), packet processing (route and DNS lookups, error correction), and queuing (other packets have to be treated before; differs from packet to packet, hence jitter, defined as 95% percentile RTT - 5% percentile RTT). AND = minimal RTT (packet processing delay) + S (packet size) / Reff (effective link rate) + Tque (total queuing delay in up- and downstream, results in jitter)
Experiment: for 5 different values of S, throw 100 pings. Get RTT and jitter (= Tque) from 100 pings. Obtain Reff from taking the inverse of the best-fitting trend-line through the 5 points (S, average RTT). Obtain min RTT from the intercept of the trend-line through the 5 points (S, top-1% RTT).
QoS improves RTT by separating game traffic from other traffics

A Zone-based Gaming Architecture for Ad-Hoc Networks, by Riera et al.

Assumption: ad-hoc networks are going to multiply, but C-S and P2P architectures are not well-suited for them. Most interesting part of the job is to determine which device can/should be Zone server.
Even the nodes that do not play the game assist the other nodes in delivering data
Nodes are mobile: they do not always stay within reach of the same other nodes. Discovery of Zone servers is done through the SLP v2. When latency to a zone server gets too high, a client can pick another zone server, which in turn notifies all the other zone servers of its new connection. When a client does not reply for a while, a zone server can drop it.

A service platform for on-line games

Middleware as transparent as possible to the game developer. This middleware sits on top of an existing grid infrastructure from IBM called Globus. Globus decides when to spawn a new game server instance based on current resources and demands.
Player services are in charge of authentication, account handling, chat rooms, locating games/selecting a server taking into account player preferences (e.g. team or region), and actually playing the game.
Publisher services deal with software deployment and updates, billing, monitoring server performance, service level agreement (e.g. no more than 5% of players suffer from more than 100ms delay)
System services include resource management and directory services. These services are accessed by the grid provider.
Clients submit jobs using a format containing the executable, its arguments, and resource requirements. Jobs can require spawning instances at different grid locations (e.g. different regions).
Various services such as resource informations and information providers (CPU, OS, RAM, connectivity, ...) are indexed in an LDAP. Game-specific services (tracking player stats, server load, ...) could also be added on top of existing services.

Bottom-up game design

noreply@blogger.com (gentimouton) — Fri, 25 Nov 2011 02:59:00 +0000

Existing definitions

Adams defined bottom-up game design in 2004 as turning a simulation or a real-life mechanism into a game. It assumes that any process that is subtle or interesting to program is also going to be interesting to play with. If the simulation has too many variables, many of them end up being useless, and this results in possible dominant strategies and the game being dull.

Lopes and Kuhnen redefined bottom-up game design in 2007, as applying a particularly fun gameplay verb or mechanic, complementing it with the appropriate setting, content and story. Developers think first about the elementary game actions, called verbs, that the player can execute (move, attack, ...) and then about the aesthetics (fantasy universe, ...). Examples are games in the Doom series, which were built barely as excuses for the brutal, over-the-top shooting gameplay; the oppressing universe and mood simply fit well with the gameplay.

In 2010, Deleon focused more on the medium constraints with his definition: concept inspired by or chosen partly by its form of representation. For instance, Bubble Bobble is about shooting a ball into balls of similar color, and the little dragons or fruits are merely decorations. Same for Bejewelled. Bottom-up designed games also include games made for particular platforms with limited hardware (like Bogost's games for the Atari 2600).

More theory: ludemes

Ludeme was a term coined by Berloquin or Dawkins in the early 1970s, as a portmanteau of ludic meme, because a ludeme can be found in many (classes of) games. Ludemes are described by Parlett as conceptual elements of the game, most typically equivalent to its "rules" of play. For example, whereas the material piece shaped like a horse and designated "knight" is a component of the game, the distinctively skewed move of a knight is a ludeme of the class "rule of movement". But other types of ludemes also exist. For example, the name, referend and associated connotations of "knight" - those of a chivalric courtier - may be said to constitute a thematic ludeme.

At GDC 2005, Koster presented his vision of a grammar of gameplay, referring a lot to ludemes. For Koster, ludemes are atomic mechanics with at least 2 possible outcomes (e.g. moving a Checker piece to capture, prepare, or force the opponent to capture (which is actually a kind of preparation)), among which at least one is failure (even if failure only means closing some of the player's opportunity doors). Synonyms of ludemes are: verbs (Crawford), choices (Meier), or conflict. Each ludeme involves a UI action (e.g. pressing button). In terms of complexity, Chess is more complicated than Checkers because each of the 6 types of Chess pieces has its own movement and capture ludemes, while all Checker tokens have the same ludemes.

Bottom-up game design in practice

As Lopes and Kuhnen pointed out, designing games with a top-down approach is somewhat of a dark art when it's time for the designer to bridge the gap between the high-level concept (e.g. in terms of experience, emotions and feelings targeted to the player) and the routine tasks of the player (e.g. drawing a card, moving their avatar or attacking). Current game design textbooks such as Adams' Fundamentals or Schell's Book of Lenses, putting forward player-centricity, suggest a top-down approach by focusing on the experience the entire game should convey to the player.

But a player-centric bottom-up approach is also possible. I'm trying here to provide prescriptive rather than proscriptive steps. In the bottom-up process, the designer should ask the following questions:

What are the elementary actions the player can do? (define the ludemes)
How can these actions be fun? (feeling of latent power, fiero, schadenfreude, aesthetic pleasure, ...)
What are the transitions between these actions? (for the ludeme "roll a dice", it is when the dice is rolling)
How fun are the transitions? (surprise, feeling of progression)
Sanity checks: how do the actions fit together as a whole? (pointing to shoot in FPS should not be followed by a dice roll, the intense mechanical ludemes of Doom should be matched with horror-aesthetics ludemes such as the lack of light, ...) Does the overall feel of the game match the feeling of all the elementary actions put together? (ludemes should add up, not negate each other)

This process is tentative, possibly flawed, and therefore feedback is most welcome.

For the win - Doctorow 2010

noreply@blogger.com (gentimouton) — Tue, 22 Nov 2011 06:31:00 +0000

Doctorow C. 2010, For The Win

Notes from For The Win from Doctorow. The book's license is Creative Commons NC-SA. No spoiler here, only some interesting concepts mentioned throughout the book.

Part I: The gamers and their games, the workers at their work

Some players in developing countries like China or India farm gold or are paid to raid with richer solo players from the West to drop them gear or level them up. Western players want to keep up with their friends gear- and XP-wise.
The parents, whether Indians or Americans, don't understand how their kids can spend so much time playing online games. American parents talk about addiction whereas Indian parents about waste of time.
There are multiple, competing interworld exchanges: want to swap out your Zombie Mecha wealth for a fully loaded spaceship and a crew of jolly space-pirates to crew it? Ten different gangs want your business. Even RL traders place money on the value of virtual gold, because virtual gold fluctuates a lot and can be exchanged against RL money through the official in-game banks. RL criminal cartels also turn IG gold into real money.
Big gold farming businesses hire hardcore gamers to kill other farmers. The biggest sellers of virtual gold are game companies themselves and they hire killers too.
Dungeons are made so that farmers make less and less money: grinding gold gives 12k the first hour, 8k the second, 2k the third, and 100 at the end. Then, a GM appears and bans them, but they've already collected as much as they could for the night before going to sleep.
Mechanical Turks were an army of workers in gamespace. All you had to do was prove that you were a decent player -- the game had the stats to know it -- and sign up, and then log in whenever you wanted a shift. The game would ping you any time a player did something the game didn't know how to interpret -- talked too intensely to a non-player character, stuck a sword where it didn't belong, climbed a tree that no one had bothered to add any details too -- and you'd have to play spot-referee. You'd play the non-player character, choose a behavior for the stabbed object, or make a decision from a menu of possible things you might find in a tree.

Part II: Hard work at play

Mushroom Kingdom is a Mario-based MMO from Nintendo-Sun. You can play on the side of Princess Peach, or on Bowser's.
Prikell equations: a certain amount of difficulty plus a certain amount of your friends plus a certain amount of interesting strangers plus a certain amount of reward plus a certain amount of opportunity equalled fun
virtual currency tended to rest pretty close to its real value, plus or minus five percent
Socio-economics experiment about envy: lock 25 grad students in a room for 8 hours. Give each of them a poker chip and say "Every hour I'm going to give each of you $20 per chip you hold". At the beginning, each chip is worth 8*20=$160. After 2 hours, chips start being exchanged against dollars, and at the end of the 8th hour, some chips even get traded for $50, while they only bring $20 to their owner. Each of them started and kept trading because of the fear that he was missing out on what the rest of them were getting: the sirens called Someone else is getting richer, why aren't you?. Greed is "if 1 is good, then 10 is definitely better". Envy is about what other people think is good, and being part of the crowd.
Gamerunners spend most of their time in the Command Room, watching the world through logs, screens, chat channels, or charts, to get a feeling of the game worlds - Fingerspitzengefuhl.
the game soundtrack has its own AI that creates more dramatic moments

Part III: Ponzi

Gold farmers used to login from Asian IP addresses, give all the gold from an account to a newbie without speaking a single word, who in turn would give it silently to a bunch of other newbies from guilds with names like "afasdsadssadsa289". Later, gold farmers logged in using American proxies, started speaking broken English, and became indistinguishable from profitable Western kids.
After their 12-hour shift, some gold farmers relax by playing some more with a separate avatar that they only use to play, not to work with.
Pacific protest: ask everyone to gather in downtown and eat ice-creams. Recruit people passing-by in giving them ice-creams.
If you nuked every account involved in a gold-farming buy, we'd depopulate the world by something like 80 percent.
Coke ran games that turned over more money than Portugal, Poland or Peru.

Rules of Engagement - Pardo at GDC 2008

noreply@blogger.com (gentimouton) — Thu, 17 Nov 2011 08:08:00 +0000

Pardo R. 2008, Rules of Engagement: Blizzard’s Approach to Multiplayer Game Design

A talk from Rob Pardo which was actually first delivered at GDC 2008. The talk has already been covered elsewhere. You can also find the slides with Q&A of GDC 2008. Anyway, here are my take-aways.

Implement the multiplayer part of the game first, then the story and single-player components.
In PVP, focus on balance, skill differentiation (e.g. reflexes for FPS, multitasking and strategic thinking for RTS, knowledge of the mechanics for both RTS and FPS, economic dominance), and ladders/ratings. For co-op games, focus on the communication between players and complementary classes. Ex: in Warcraft 3, a mine is considered 'full' when 5 peons work on it; the economic part is dumbed-down to encourage the players to focus on the micro-management of fighting units.
Avoid differentiation on map knowledge: it's not really a skill. Instead, reveal the map but keep a fog of war (like in Starcraft 2), so that players know the flow of the map and where the resources are, and can pick their strategy accordingly.
Everything should feel overpowered, not mediocre.
Balance first for the expert, then for the novice.
Balance is affected by the maths, but also by the UI (e.g. WoW's UI mods, or the possibility to select only up to 12 units in Starcraft 1 as opposed to an arbitrary large number of units in Starcraft 2), maps/level design, special effects (e.g. too much blurs the vision, cf the War of Emperium of RO set /mineffect by default to limit the visual flood of skill effects)
Players hate loosing, hence make games shorter so that they can play more games per play session, and eventually win some.
Reward the behaviors you want people to do/make it a bonus
Tie art and game design together. The appearance of Heavy of Team Fortress is explicit: tough, lots of HP, and lots of damage.
Spectatorship enables empathy with the players, cf Poker became more popular when hole cameras were introduced because the audience understands better what's going on.
It does not make sense for warriors to cast spells, therefore they don't have mana but rather they have rage.

21st Century Game Design - Part I

noreply@blogger.com (gentimouton) — Wed, 02 Nov 2011 06:44:00 +0000

21st Century Game Design, by Chris Bateman and Richard Boon, 2005.

Part I - Games exist primarily to satisfy the needs of an audience

ch1 - Zen game design

Zen Buddhism can not be learned, it can only be experienced. There is no objective perspective on anything. Hence zen game design's tenets: game design reflects needs + there's no single method to design + there exist methods to game design. These methods are:

first principles: what you want to do -> game world abstraction -> design -> implementation
clone and tweak: most common method. existing design -> tweak -> implementation
meta-rules: goal = provoking debate. meta-rules -> design -> implementation
expressing technology: in teams without actual game designers. technology -> game implementation
Frankenstein: art or technical materials -> design -> implementation
story-driven: narrative -> design -> implementation

Participants in the game project: audience, publisher, producer, programmers, artists, marketing/PR, license holder. Example: saving for causal audience is vital; for hardcore audience, it should not break gameplay; for programmers, it's a technical detail; for producer, it's looking at how other games do it.

ch2 - Designing for the market

The commercial success for a medium clears the way for artistic expression, not the way around

A game design is successful when the target audience is satisfied. This justifies the need for an audience model. Existing models: simple distinction hardcore/casual, distinction by genre (but genres are too vague), EA's model, and ihobo's model.

Simple hardcore/casual distinction
hardcore	casual
plays lots of games	plays few games
game literate	game illiterate
plays for the challenge	plays to relax, kill time, and just for fun
segment can be polarized: many can buy the same title	hard to polarize, diverse and disparate

EA's model:

EA's model take-away: do not ignore hardcores because they are the ones pushing a game to broader segments. Corollary: no TV ads are needed if the game is not made for casuals.

iHobo's model:

Evangelist clusters = gaming press, mainstream press, and the 3 million of hardcores in the world. Target clusters = Testosterone (9M players worldwide), lifestyle (30M), and family (90M) gamers.

Design tools for market penetration (aka demographic game design):

Looking for good gameplay (ie the game being performance-oriented, with stats, clear goals and victory conditions) vs good toyplay (unorganized). Hardcores are driven by gameplay, but lifestyle and family gamers are driven by both.
Controls should remain accessible for casuals.
The minimum play session length is usually expressed in terms of the duration of a level or the time between two save points. For casuals, it should be below 15 minutes, but hardcores do not mind core activities of a game taking at least an hour or two. Ex: a typical DotA match takes 45 to 60 minutes, whereas a (small size) Mine Sweeper can take less than a minute. Nintendo games are also famous for allowing the player to quit at any time and provide core activities of at most a few minutes.
The average play session length is also lower for casuals: they may complete one level at a time, whereas hardcores can aim at 10 levels per play session.
Play window: total time spent playing the game. The longer the play window, the longer hardcores will spend evangelizing the game. Therefore, despite most of the players not completing the game, content is crucial! The play window can also be extended by introducing hidden features, higher difficulty levels, variety in characters to play with (to increase replayability), and online PVP (although that only works for Testosterone and hardcore gamers).

Phases of penetration: taking the example of The Sims.

Hardcore penetration: the game needs challenge, progress, and depth.
Hardcore evangelism: the game needs to appeal to the Lifestyle gamer, easy to reach fun, strong marketing, and a strong license.
Casual penetration: the game needs fun, toys, short minimum play session.
Casual evangelism: the game needs to get the attention of the mainstream press.

ch3 - Myers-Briggs typology of gamers

Assumption: nature of games people enjoy and frequency of play vary with player personality and reaction to situations. The Myers-Briggs model was developed in the 1940s and indicates how an individual would prefer to react to situations in general. See the Myers-Briggs type frequencies in the US. Four pairs of traits:

Type	Opposite type	Game design
Introversion (50% of pop) think then act, needs private time, 1-to-1 communication and relationships	Extroversion (50% of pop) act then think, likes people, deprived when alone	Most games are played by introverts. Extraverts can take long breaks from the game, so provide a todo list for them when they come back to play, otherwise they'll forget what they had to do in their previous play session. Extraverts like DDR because of its performance aspect.
Sensing (70% of pop) live in the present, apply common sense, based on prior experience, likes clear and concrete info	iNtuition (30% of pop) live in near future, new and imaginative approaches, based on theory, comfortable with fuzzy information, seek for patterns)	Learning and problem solving are frequent gameplay elements in many genres. Learning: in tutorials, S will accept linear series of lessons, but N would rather guess by themselves. Problem solving: S will use trial and error, while N will like to use their lateral thinking skills. Therefore, make lateral thinking puzzles (at most) secondary objectives, or allow the player to progress without having completed all of them. Ex: Super Mario 64 only requires 30 stars to unlock new levels. S want simple and usual mechanics, while N won't mind having to guess the rules and a steep learning curve.
Thinking (30% of women, 60% of men) decide from facts and logic, objective, focus on task, think that conflicts are sometimes unavoidable	Feeling (70% of women, 40% of men) decide from emotion, subjective, focus on consequences to people, wish to avoid conflicts	Clear goals for T. Personal encouragement for F, but T may feel patronized. Solution: useful AND aesthetic/fun items are rewards that will satisfy both T and F. Gathering collectibles give goals to T, but should not be a grind. F are motivated and rewarded when they see their actions have impact on the world or other characters. T enjoy receiving critical feedback (a game over with tips), but F will take it personally. Ex: Zelda gives clear goals (good for T), falling or getting hit results in losing half a heart (and not instant death) and Link has an impact on the game world (good for F).
Judging (55% of pop) plan then move, single task at a time, ahead of deadlines, targets and routines to manage life	Perceiving (45% of pop) plan as you go, multitask, work better before deadline, avoid routine and commitment	J want to beat the game (get all the secret bonuses) and complete objectives. P want to improve their abilities, and enjoy the process. For P, goals completed = feedback that they're on track. Non-linear structure is good for P because if they don't like a level, they can try another and keep progressing. J needs to know what to do to progress. Ex: in Tony Hawk or GTA, players need to collect points (good for J) but they can collect them the way they want (various kinds of skate figures or driving/killing missions or sandbox play, good for P).

TJ vs FP: TJ want challenges to overcome (what most current games provide), FP want easy fun (cf Sims or casual games).

Study hypothesis: hardcore player is a 14-28 year old tech savvy male who plays up to 8 games per month. Supposedly, he plays on his own (hence I), is methodological, goal-oriented enjoys conflicts (T), plays games until completion and looks for perfect score/overachiever (J). Previous quantitative work from the Bartle test by Andreasen showed the average hardcore MMO player is IST. Therefore, let's suppose hardcores are IT. Overall, 15% of women and 35% of men are of type IT.

ch4 - DGD1

DGD1 is intended as a tool to aid in market-oriented game design.

Methods: between 2002 and 2004, ask 408 participants (incl 122 women) to answer a 32-question Myers-Briggs personality test, as well as questions on purchasing and playing habits, and do you consider yourself hardcore, casual, or no idea?. Only look at people who play at least one game per year. Survey advertised on hardcore and casual websites/game portals + university students.

Results: clustering gave a sketchy and incomplete result, and FE and SI dimensions did not help to cluster, but 4 clusters appeared anyway: conqueror (TJ), manager (TP), Wanderer (FP), and participant (FJ). Hypothesis rejected: hardcores are found in E and S (and not only I and T). Still, I and N are higher for hardcores and MMO players than casuals. For each of the four types, twice more respondents reported they were casuals than hardcores.

The DGD1 demographic model
Type	Hardcores Desc	Casuals Desc	Progress	Story	Social
Conqueror	ITJ. Want meaningful challenges, strategies and puzzles, want to complete the game. Want lots of content, try to beat themselves. The game is too easy if they don't die at least a few times. Anger, frustration, boredom, and fiero.	ISTJ. FPS and racing games, they play to compete and win. Rely on genre conventions and do not like deviations from the genre. Fiero (although it's oblivious to them) and schadenfreude in PVP, or in GTA for rampages	Rapid advancement: stats in RPG, better gear in FPS	Focus on plot twists/events, not on characters	Online: vocal hardcores from forums and blogs. They also like to win discussions
Manager	ITP. Strategy and tactics. Winning is less important than mastering the game systems: process-oriented, not goal oriented. Conquerors consider them rivals and targets. Patient. Look for challenging but not impossible. Don't look for hidden features but rather refine their current knowledge. Fiero. Civ series.	ISTP. Want familiar settings and realism. Like construction and management games like SimCity. Hate being stuck even if they suck. Hate interruptions and like smooth difficulty curves.	Steady. Give up if no reliable strategy is found quickly.	Plot, not characters.	None?
Wanderer	INFP. Easy fun and toyplay, not challenges. Variety keeps the fun going. Complete levels in aesthetically pleasing ways. Cf Puzzle Bobble/Bust-a-Move: simple controls, bright colors, and actions with direct and satisfying changes to the environment. See also Mario Party and Super Monkey Ball. Need to be able to give up the current task for another different task. May turn to Conqueror or Manager relatives for help. Emotions: finesse, aesthetics, wonder, awe and mystery, but no fiero.	ENFP. Want to accomplish something in the game world without the need for challenges. Games = way to relax. Feeling of progression or else boredom. Lack of market vectors to reach them [although nowadays there's Facebook]	New toys, colorful and imaginative environments	Emotions. Empathy to characters or investment in world/immersion.	Talk about what they like but avoid arguments
Participant	FJ. Games as social entertainment. Cf DDR, The Sims. Little survey data about this group.		Narrative of group of players	Characters and emotions, but in control of them, not just spectator.	Multiplayer, but must face other players in person, not just online (no MMO)

ch5 - Player abilities

Flow = subjects believe they can complete their activity. Subjects have clear goals and direct and clear feedback. Effortless involvement. Goals should be short-term for participant and conqueror, but long-term for Wanderer and manager because they like to figure out the short-term goals themselves.

Caillois' table of the four categories of play helps understand how flow is related to toyplay. In the table, there really is a continuum between Paidia and Ludus.

The relation between the four play styles of DGD1 and Caillois' categories of games
Conqueror Agon	Manager Agon (Alea tolerated)
Participant Mimicry	Wanderer Mimicry (Alea tolerated)

Caillois' table of the four categories of play
-	Agon (competition)	Alea (chance)	Mimicry (simulation)	Ilinx (vertigo)
Paidia (spontaneous play)	Spontaneous races	Counting out rhymes, coin flipping	Masks and disguisement	Children whirling, swinging
Ludus (structured play)	Sports	Betting, lotteries	Theatre	Skiing, mountain climbing

People with high Myers-Briggs Feeling scores prefer avoiding conflicts, therefore they don't like Agon. They're also more likely to like Mimicry since they focus on people. For example, Wanderers appreciate finesse, which is a component of Mimicry. Ilinx resembles immersion, it appeals to everyone.

Temperament theory gives patterns of behaviors, while Myers-Briggs gives patterns of perception or judgement.

Temperament theory
Temperament	Core needs	Myers-Briggs traits	Skills	% of pop
Rational	Knowledge, competence	NT	Strategic: Think and plan ahead, identify the means to achieve a goal, coordinate actions strategically	10%
Idealist	Unique identity, search for meaning and significance	NF	Diplomatic: Resolve conflicts while recognizing individuality, empathy, find similarities through abstraction	15%
Artisan	Freedom to act and ability to impact	SP	Tactical: Read the current content and manage the situation, work out the next step and take action, improvise to overcome problems	25%
Guardian	Belonging and sense of responsibility/duty	SJ	Logistical: Organizing and meeting needs, optimizing and standardizing, protect and ensure safety	50%

Temperament, Myers-Briggs and DGD1
Type	Myers-Briggs traits	Hardcore temperament trait	Casual temperament trait	Flow provenance	Examples
Conqueror	TJ	strategic	logistical	Capacity to see in advance how to address problems (strategic) and iterate/repeat to improve/optimize the solution (logistical). Willingness to fail and repeat	Production of units in RTS, monsters or bosses with patterns (cf Doom monsters)
Manager	TP	strategic	tactical	Planning ahead (strategic) and reacting to rapidly changing situations (tactical). Hardcores like to get lost in their thoughts, ideally without time limitations. Casuals have flow in the action, and need short-term goals.	RTS have both spontaneous maneuvers and long-term strategies. Civ, Chess or puzzles for hardcores.
Wanderer	FP	diplomatic	tactical	Immersion, explicit short-term goals (tactical). Completion of goals is not a big thing, it happens almost as a side-effect of exploration. Give them time to explore.	Platformers (goal is obvious and challenges relatively easy)
Participant	FJ	diplomatic	logistical	Feeling of belonging, toyplay, optimize relationships (logistical) with other characters or players, immerse themselves in social situation	The Sims, Animal Crossing

Casual audience is best approached with familiar settings and content, and with gameplay that revolves around optimization or thinking on your feet (tactical). Hardcores prefer original games that give them a sense of identity (diplomatic), and problems to solve (strategic), e.g. Final Fantasy focuses on story and strategic battles.

Panel on MMOs from Netgames 2011

noreply@blogger.com (gentimouton) — Wed, 19 Oct 2011 00:13:00 +0000

Panel at NetGames 2011 about the future of MMO research.

Cheating (no control of the client-side) and performance (weakest node performance conditions the other nodes' performance) are issues in p2p architectures. I could p2p when I play with friends, but not competitively. Even with friends, the developer has no control over the network, NAT traversal problem. Potential solutions: match-making on server, then one peer hosts the game. If host disconnects, the game migrates to another peer. Problem: how to partition and replicate the game world between peers?

How to integrate scaling into game mechanics?

Researchers can get data from companies if they show that it is worth the company's time (taken to fetch and anonymize data).

Problems shared across p2p, client-server and cloud architectures: scalability, cheating, latency, concurrency, synchronization, and replication.

Using the cloud is cheap for small user bases, but very expensive for very large user bases.

Casual Connect and GDC Online are industry conferences that also deal with network and system support for MMOs. But they're expensive.

MMO player research methods

noreply@blogger.com (gentimouton) — Sat, 08 Oct 2011 04:46:00 +0000

Types of data of interest in MMO player studies:

demographic data: country, gender, age, job, psychological traits, tech-saviness, happiness, revenue
marketing data: how much spent on games per month, how many games bought,
play data (applicable to all games and game genres): weekly play time, average play session duration, game and genre literacy,
genre-specific and game-specific data: for MMOs and WoW in particular: who you play with, guild position, achievement/immersion/social motivation scores

Challenges of player studies: using tools and methods to convert data into useful information, and avoiding erroneous conclusions by crossing results obtained from various methods.

List of qualitative tools.

Methods	Qualitative	Quantitative
Data collection tools	Note taking or recording during open-ended interviews, lab studies, think aloud, or participant observation/ethnographic play. All methods gather all types of data - you just need to ask. Snowball sampling is useful to collect more people concerned by the same phenomenon (eg people from the same guild).	Questionnaires can gather multiple types of data together, but beware: what people say they do differs from what they actually do. Non-obtrusive logging of game data has the advantage of being objective, and can be done using programmable game add-ons that players need to install. It's even possible to cross game and marketing data together from the developer/publisher side (cf the EverQuest dataset from SOE).
Data analysis tools	Note tagging and affinity diagrams are methods used during the note parsing phase. Stop interviewing when respondents do not say/show anything new anymore. Preferably, do not wait to start parsing the data; parsing as notes are taken gives an immediate feedback loop useful to detect useless interview questions, and to know when to stop accumulating data.	The most popular tools to use for stat analysis are SPSS, R, and Excel. Obtaining causal relationships is usually quite hard. On the other hand, simple comparisons and correlations are often successful. Regressions can work too. Data mining/machine learning using Weka or Matlab. Clustering (PCA, LDA, and even KPCA if small dataset) can identify patterns during exploratory phases. Feature selection or decision trees to identify the most important features. Poisson process or Markov chains for temporal evolutions. Bayes, neural network, SVM, random forests, and others for classification.
Pros and cons	Deep, and useful to hint at the reasons explaining a particular phenomena, especially in MMOs, where the metagame (forums, blogs, chats) has a huge influence on the actual game. Snowball sampling in WoW brings lots of players from the same guild(s), or with similar opinions. Therefore (and also because of small sample size): poor ability to generalize. Qualitative methods can also be used as exploratory studies to help build a quantitative questionnaire with relevant questions.	Broad and useful to detect surface trends. Sample bias/representativity: it's very hard to select a representative sample of the player population. For example, selecting players from wow.com brings a lot of hardcore players (since hardcore players read forums while the most casual players don't). Very hard to explain completely a phenomenon because there's always important features missing from the dataset. Machine learning is also difficult for that same reason. It's very easy to get lost in post-hoc effects, or to simply not be able to explain a particular number because you've never played the game. Generally, demographic data can not be caused by game-specific data: it's not because people are hardcore that they're young, but rather the opposite.
Researchers	Bardzell, Bartle, Kow, Nardi, Pace, Pearce, TL Taylor	Andreasen (= quantitative Bartle test), Bateman, Ducheneaut, Seay (not working on that domain anymore?), Williams, Yee,

The aesthetics of gameplay: a lexical approach

noreply@blogger.com (gentimouton) — Thu, 15 Sep 2011 06:29:00 +0000

The aesthetics of gameplay: a lexical approach
Zagal and Tomuro
MindTrek'10

See the PDF or the ACM page.

Primary Elements of Gameplay Aesthetics
Aesthetics cluster	Words in cluster	Description
Pacing	fast, stressful, dull, tedious	The perception of how often game events occur.
Scope	endless, vast, immense, minimal	The size of the possibility space afforded by a game.
Complexity	simple, short, complex, uncomplicated	The measure, or sense, of the number of parts in a system and how they are interrelated.
Demands	hardcore, experienced, retro, demanding	The requirements imposed upon the player by the gameplay
Cognitive Accessibility	deep, unusual, twisted, intricate,	The measure, or sense, of the opacity of a system and the challenges it poses in understanding it.
Impact	addictive, boring, overwhelming, visceral	What we feel games “do to us” when we play them, and how they make us feel.

Analyzed nearly 400k user reviews posted before April 2009 on gamespot.com. 8k games covered by reviews from 112k users.
40% of user reviews contain the word gameplay
Method: Stanford Parser to perform part-of-speech tagging. Matrix of (723 adjectives total that precede and modify the word gameplay) x (5000 most frequent words that occur before or after the adjective, ie context words, ie words that give a context to the adjective). Cells of the matrix contain number of occurrence of an adjective with a context word. Run kmeans on the matrix to obtain k=30 adjective clusters. (Compared to k=10 or 20, k=30 generated better-looking clusters). Two adjectives are similar (and put in the same cluster) if their context word distributions are similar. Then, give a name to each cluster based on the adjectives it contains.
Only 2 clusters about narrative elements. Therefore, players have no difficulties separating the formal or mechanical aspects (game mechanics) from their narrative interpretations (representation).
AI does not emerge as a cluster. Possible reasons: no language to describe game AI, or games AI are not sophisticated enough, or a too recently marketed topic to feature in reviews.
Genre does not emerge as a cluster.
Limitations: Gamespot population = 95% males, lots of colloquial words disappeared in cleaning phases.

My remarks

A group like "fast FPS gameplay" may have been considered as "fast gameplay" because FPS is not an English adjective, and the Stanford parser only looks at English adjectives. Since genre adjectives are not English but rather specific of gamer communities (e.g. "FPS", "RTS", "JRPG", etc.), genre did not appear in clusters.
It'd be interesting to know which game names occurred most often next to gameplay. For instance, "gameplay like Civilization" may be quite rare, but very meaningful when talking about a niche genre.
If genre is a label of the dataset, then it could be interesting to cluster a matrix like adjectives x genre. Goal = see which adjectives are explaining most a genre.

MVC for games

noreply@blogger.com (gentimouton) — Tue, 13 Sep 2011 04:01:00 +0000

Second thoughts on MVC (following a first article about the use of MVC by game developers). Let's assume that the user inputs are first caught by a controller, and a view is displayed to the user at the end. What are the communication possibilities in-between?

Vanilla MVC

As seen on Wikipedia, the theoretical 'vanilla' MVC refers to an architecture where the controller updates the model, then notifies the view, which in turn fetches the data to display from the model.

Application for games: the system is event-based: it is only awakened by the actions of the user. If the world has NPCs, they can not act independently of the user. It may be OK for turn-based games like Chess, but not so much for games with living worlds like Morrowind or Harvest Moon.

Web MVC

In web development, the "logic" is often split into multiple controllers. To determine which controller the user's action is targeted to, web frameworks such as ASP.NET or Spring use a front controller pattern. The front controller maps URLs to actions to execute (and which controllers to call). I'm not entirely sure, but compared to the vanilla MVC, it seems that the (front) controller is now giving the model to the view, instead of having the view fetching the model by itself. Therefore, the model to be displayed is carried from M to C, and from C to V, twice more data going around than in vanilla MVC (where it used to be moved only from M to V).

In games, the model can get quite large, and moving it around can get costly. It would not be so costly if only resulting differences to the model (instead of the whole model) were exchanged, but it depends on the modernity of the rendering. Alpha compositing makes it possible to render variations of the game state (ie the model) by layering image elements. Many games/game frameworks such as pygame still use bit blitting, which requires to erase and reprint the whole screen.

Game MVC

This nice article about MVC for games explains:

The controller handles the input and flow of the game logic. This is akin to the states your game can be in. My primary two controllers are main menu controller and an in-game controller. They are responsible for converting input into something the game world (model) can understand. Eg "Create unit x at base y".
The model handles all game logic. It has nothing to do with input, rendering or networking. It is a pure view into the game world. Designers need only worry about what’s in the model.
The view DOES know about the model. The [view] has read-only access to the model. This model can be anything. For my main menu it’s a list of UI controls the controller has built. For the in game view, it’s the game world. Rather than "reusing views in different controllers" what is more important is "having multiple views on a single controller". For example there might be a 2D and a 3D view of the game world.

What is still missing from the picture is the game loop. In games, the model is rendered by the view 60 times per second, and the inputs of the user are processed at the same frequency. As mentioned in the quotes above, some component, be it a controller or something else, still has to determine which view should be active at any given frame, and which controller it is associated with.

Fundamentals of Game Design, ch 15: RPG

noreply@blogger.com (gentimouton) — Sun, 11 Sep 2011 01:07:00 +0000

Inventory can be:

a grid where player can position items in empty cells, like in Diablo 1 or 2
one ore more simple list(s) of items, with an eventually limited number of slots, like Pokemon's backpack
items have weight, and the inventory is limited to a certain weight, like in Baldur's Gate

Functional character attributes = characterization attributes (stats: DEX, STR, INT, ... skills that change unfrequently, a class system pushes players to specialize) + status attributes (XP, different classes can have different amount of XP required per level (e.g. Baldur's Gate), but players should know it when they pick their character).

Instead of having levels giving sudden bonus, we could have no levels and stats would increase directly proportionally to the XP. After all, levels harm immersion. However, levels add achievement goals and let players spend regularly newly-acquired points in skills they choose.

Skills

Spells can cost mana/SP, or they could just disappear from caster's memory until she sleeps (a la Baldur's Gate/DnD). Unpracticed skills could gradually decline in efficiency, while frequently used skills could get "mastery" bonuses (like for WoW's crafting skills). Or the opposite: frequently used skills could eventually wear out of power.

Skills can be learned right away when levelling up, or when a skill point is spent in them, or the skill could be obtained from an NPC ("training" with masters), or from other players/NPC by watching them do the skill (e.g. the creature in Black and White learns spells after they have been performed a few times in front of it).

If a character has 10% chance to unlock a door independently of the previous tries, then the player will try until the lock eventually opens. Then the 10% chance only slows down and annoys the player. Instead, the better at unlocking doors the character is, the faster the door will be opened. If the lock is too complicated for the character's unlocking skills, then the door unlocking progression bar simply does not increase.

Stories and quests

If the overall story is "save the world", then give meaningful reasons why the character would be ready to do side-quests like delivery boy. Good example: helping a hermit to find his lost dog because the collar hides a key to an important door that the player needs to take. Bad example: helping a hermit simply to get XP, or just to help him out by pure generosity (but really, players are not solving NPC problems by pure generosity).

Anyway, stop writing stories about saving the world.

Fundamentals of Game Design, ch 14: Strategy Games

noreply@blogger.com (gentimouton) — Fri, 09 Sep 2011 03:15:00 +0000

Strategy = planning series of actions against the opponent(s). There's usually a large variety of potential actions. Analysis paralysis happens when players have to wait for the other to be done thinking about his next move. In RTS, decisions have to be taken quickly. The basic mechanics of strategy games involve units and the factories that produce them. There can be diplomacy if the scenario is long enough. The attributes of units can be: (max) health, (max) armor, atk, ammo, aspd, area of effect, range, and others ...

Melee unit's value (eg footman) = max HP * shot power * aspd * accuracy * range * walk speed
Ranged static unit's value (eg tower) = max HP * shot power * aspd * accuracy * range^2/2. Squared because the area defended increases quadratically. Halved because units can generally only cover one side/half, the one side towards the enemy.

Most RTS make little use of line of sight and terrain realism; a unit on top of a hill could see further, a unit behind a hill could be hidden from those behind it, units have atk/def/... bonus when they are in their favorite terrain.

Gold is too important for war for mines to be spread out randomly. Spreading randomly means randomly-chosen players get a random advantage from the start, which is unfair. Mines randomly spread also means that players will hunt for mines instead of fighting strategically against each other. Large mines should be positioned symmetrically if they are decisive. Random mines should be smaller and not be decisive for winning.

Lanchester's laws: 1- In melee combat, army strength is proportional to number of units because each fighter can engage only one enemy at once. 2- In ranged combat, units can concentrate their power on a single enemy. When 1 unit is attacked by 3 archers, its life decreases 3 times faster, and it can only attack one of them, ie 1/3 of the enemies. Therefore, 3 ranged units are 3*3=9 times stronger than a single unit (whether ranged or not).

Imagine the tight and strong negative feedback loop: "wounded units attack weaker". Then players have to play sub-efficiently all the time, and they're going to wage attrition skirmishes, not big epic battles.

Do not block or forbid certain units or skills in a particular level. Instead, make the level so that this unit or skill is very inappropriate. Ex: to prevent the player to use air units, give the opponent lots of anti-air missiles. To prevent the use of iron, set the victory condition to "collect lots of iron".

Upgrades

Upgrades can apply to a single unit (veteran units have +1 dmg), all units of a particular kind (grunts get +2 atk), all units of all kinds (Iron Age = +2 def to everyone), or even the whole mechanics (production speed divided by 2). Upgrades can be unlocked by spending resources, time, achievement, ... The tech tree can be:

totally open: player spends point in any tree she wants, like in WoW
constrained: finish one branch to start another
fixed: once player starts in a tree, only this tree is available for the rest of the game

Production and distribution

Production process should be concrete and visible, while the distribution process should be abstracted. Ex: plant farms for food = concrete food production. No supply lines as long as there are roads = abstract supply distribution. There are different shades and techniques for supply lines: troop caravans between cities in Heroes of Might and Magic IV, trade caravans between cities in Civilization series or Age of Empires, or Armored Personnel Carrier that transports troops and fuel in Advance Wars. Another approach is to have cities within a zone of influence to be supplied: cf the influence zone mechanics of Populous (you can only build in your area of influence), Civilization, and Black and White (you can only exert your god powers within your zone of influence).

AI techniques

Game tree search, as used in games where there is a finite number of possible moves, such as Chess or Checkers. Problem: the search space increases exponentially, which is a problem for games like Go which have too many possible moves.
Neural networks: patterns are identified after repeated exposure. Problem: training takes time, the system can hardly be tweaked, and adding new patterns means re-training the whole system.
FSM: units transition from one state (walking) to another (shooting) because of events (enemy appeared in sight). Problem: the unit can only be in one state at once.
Hierarchical FSM: FSM of the commander gives orders such as "take this hill" to captains. Captains have an FSM that gives orders to soldiers in the squad, such as "cover fire" or "make diversion". Each soldier has its own FSM as well: "if I see an enemy, run for cover". hFSM can create emergent behavior.

Human-Currency Interaction: Learning from Virtual Currency Use in China

noreply@blogger.com (gentimouton) — Fri, 26 Aug 2011 17:36:00 +0000

Yang Wang and Scott Mainwaring, 
“Human-Currency Interaction”: Learning from Virtual Currency Use in China, 
CHI 2008

50 semi-structured interviews on the use of RMT in China during Summer 2007. Respondents of all ages, playing WoW, Mir2, MapleStory ,Second Life and others.
Gateway currency = legally convert real money into IG time or currency: Q coin, WoW 66-hour play card. Game-specific currency = in-game gold.
Realness: students and young professionals consider gateway and game-specific currencies as both virtual and real. For older adults, the currencies are purely and solely virtual. Virtual currencies are dishonest, they are masquerading as an innocuous, too-easy-to-spend plaything, while in fact they represent a lot.
Trust: face-to-face cash transactions. Need to meet sellers/buyers in person to be sure they are doing their part => meet in a wang ba, both avatars and human beings face each other. Online trusted third-parties require credit card => not for kids. Face-to-face = hassle, but it's also fun to meet IRL other players.
Account sharing: Pros = with friends, try other characters. Cons = they can steal your stuff, you give them the password you use in many other applications, including RL ones (e.g. email). How to allow account sharing without compromising player security and privacy?
Fairness: small buyers ($10/month in RMT) find unfair that some players can spend 10-100 times more than them. Buying from other players is felt as less unfair, and seems to alter the game balance less, than buying from the game company.

The life of the Chinese gold farmer

noreply@blogger.com (gentimouton) — Fri, 26 Aug 2011 02:22:00 +0000

Notes from a June 2007 New York Times article about gold farming by Dibbell.

Julian Dibbell, June 2007, The Life of the Chinese Gold Farmer,

100k Chinese workers are involved in RMT. RMT market = $1.8 billion worldwide
80 MMOs and 30M players worldwide. WoW brings $1bn/year to Blizzard.
The Gross Domestic Product of the MMO player population is between $7bn and $12bn.
The gold farming wang ba given as an example has 10 employees and generate $80k/year. 12-hour day/night shifts. Dormitories are in the second floor of the wang ba.
Farmers collect 25 gold/hour. For 100 golds, the farmer receives $1.25 by his boss, and the boss receives $3+ by the gold selling website which sells those 100 gold for up to $20.
After Blizzard banned 50k gold farmers, the exchange rate went from 6c/gold in Spring 2006 to 35c/gold in January 2007.
Differences between power levellers and gold farmers: bigger teams (25 per 12-hour shift), less sweat-shop-like, have a company tee-shirt/polo, team spirit, less ban (because they use the customer's account and act nearly like actual players). Some leave gold farming to power levelling to have more room to play for themselves. They like the game/work because playing WoW = learning. Some even buy gold because they don't have time to grind.
Raids have drops bound when picked. Therefore, gold farming/power levelling for high-end content is hard. Solution: make a guild, invite the customer in it, raid with him, and have him pick the loots when a boss is downed. Problem: too few customers buy it => cancelled.
Gold farmers too want to play.

MVC and game developers

noreply@blogger.com (gentimouton) — Mon, 22 Aug 2011 00:07:00 +0000

MVC in software engineering

The model stores data, and runs domain-specific logic. An example of domain-specific logic in the banking domain is if customer's account is below zero, refuse withdrawals. The view gets data to display from the model. Some MVC have the view pull data from the model itself, others have the view notified by the model, and others have the controller tell the view to update itself. The controller receives and converts user inputs in actions understandable by the model. In web development, such as ASP.net or Java servlets, the controller picks which view is going to be displayed, and then the selected view is actually in charge of displaying information on the screen. If this description is not clear enough, the wikipedia page about MVC has a scenario that helps explain how the model, view and controller fit together.

MVC in games

Many amateur game developers say ideas from MVC can be applied to games but in general it is just a waste of time. For many, there is no such thing as game architecture: The only difference with classic MVC is that in a game, the graphics data, logic and game algorithm is fused together. Others argue that in a rapid prototyping context, where iterating is key, one should not waste time conceiving a modular/maintainable system, but rather focus on testing the game as fast as possible.

Many non-indie games are made with MVC in mind. Splitting data from presentation induces extra work on the code and managing slightly more objects in memory. However, this is exactly what allows an easier testing and debugging of mechanics, UI, and network components. In fact, MVC has been applied to game programming since at least 1998. A blogger at TigSource states that MVC can be applied in any part of a game. Taking the example of a network connection: The input view in this case is a network receiver running in it's own thread and listening for data from a socket. When the view receives data, it's translated into an internal class and sent to a controller for processing.

Middle ground

I find that explicitly implementing an MVC pattern for the network connection is a bit of an exaggeration. Heads-up displays and other UI input perfectly fit as controllers, and are naturally decoupled from the model. On the other hand, there is a strong tendency by many game developers to ignore software engineering practices. Some even put forward the Extreme Programming side of rapid prototyping to justify their ignorance of any architecture. Agile methods do not contradict the use of any architectural pattern.
That may explain why so many of pygame's projects contain a single file with thousands of lines of code ...

[Literature] Fundamentals of Game Design, ch 12: Level Design

noreply@blogger.com (gentimouton) — Thu, 11 Aug 2011 03:48:00 +0000

Level design = determine level's initial conditions, pacing (stressful or calm, genre-dependent) challenges, win/loss conditions, cut scene locations, aesthetics and mood (lighting, color palette, weather, special visual and audio effects, music, ambient audio), through tools.

Level design process

Determine level features: events, objects, NPC
Plan the gameplay: layout, challenge areas, win/lose conditions. Plan also the art: textures, styles, moods, ...
Prototype: requires that the game engine is at least partially working. Use mockups to place triggers and document what sets triggers off (= rigging).
Keep reviewing (with other people) and refining the level's size, pacing, objects, triggers, NPCs, and aesthetics.
Hand off the level to the art team with requirements and documentation.
Integrate visual and audio art assets, bug fix, and tune.

Guidelines

tutorial = included in the first levels of the actual game (not as a side) = hands-on learning. Start explaining the most used features one by one. Disable unused features to avoid confusing the player. Explain UI elements and point at them visually (blinking or glowing). Let player go back and try the tutorial examples again. Allow the tutorial to be skipped.
vary pacing within a level
after player surmounts resource-consuming challenges, player should be given resources to come back
avoid things that do not make sense/inconsistencies
scope: do not get too big, adapt levels to team's capacity
do not show all the challenges to in one level - introduce features gradually
know your audience
atypical levels should be optional: either they break suspension of disbelief or the challenges are foreign to the genre, and are therefore not exciting for players who like the genre. Atypical levels should be unlockable, hidden levels, or side missions, but not in the main progression.
inform player of short-term goals
be clear about risks, rewards, and consequences of decisions
reward for skill, imagination, intelligence and dedication
reward a lot, punish a little
The AI is here to lose
provide multiple difficulty settings
action games: vary the pace/players must be able to rest
strategy games: reward planning, give advantageous locations but let the player find them
RPG: allow character growth and player self-expression
sports: verisimilitude
vehicle: reward skillful maneuvers
construction and management sims: provide interesting variety of scenarios (= initial conditions and goals)
adventure: challenges consistent with their location and the story
artificial life: offer a lot of interactions between creature and environment
puzzle: give time to think

Layout patterns

Pattern	Indications
open	player's movement has no constraints
linear	works well with linear stories
parallel	works well with foldback stories, shortcuts possible
ring	mostly only for racing games
network	maze, good for explorers, hard to tell a story because the path is quite free. If all major spaces are connected, then exploration is easy: it's good for FPS deathmatches.
hub and spoke/star	start at center, challenges and rewards in branches
combination	many kinds of games!

[Literature] Fundamentals of Game Design, ch 11: Balance

noreply@blogger.com (gentimouton) — Mon, 01 Aug 2011 16:20:00 +0000

Balance deals with fairness as perceived by players, difficulty, and ensuring that skill (and not chance) is the main factor in player success. Players left-behind should be able to catch up. Stalemates should be avoided because they make some players feel like they played in vain (in other words, better players should always win). No sudden drops or peaks in difficulty. No sudden loss of the game without having previously given the player adequate information about his decisions. Respect genre: no logic puzzle inside a flight simulator.

Avoid dominant strategies

If entities are perfectly balanced and the player can see it obviously from the entities' external stats, then the game looks bland. Therefore, there should be shadow costs. Shadow costs are eventually learned by players after a while if they are not completely hidden. They should not be completely hidden, otherwise the player wonders why his performance fluctuates. More on shadow costs from Ian Schreiber.

Transitive relationships (A>B and B>C implies A>C) are good for player upgrades (sword A gives more atk than sword B). Intransitive relationships (rock paper scissors) are better with unequal costs and gains because players may take risks (and be rewarded for the risks taken). In fact, ideally, all units should be orthogonally different: they should differ in at least 2 dimensions, or have at least one capability that no other unit in the game has. Orthogonally different units prevent dominant strategies because all units are needed to reach the goal. Ex: in Chess, using the Queen only because she's the strongest is a losing strategy.

Chance

Chance can be used in frequent low risk and low-reward challenges. Allow the player to choose how much to risk. Skill is taking the good risks with enough information given: Poker players can decide to lose very little if they have a bad hand this turn: they do not bet much. Good luck cancels bad luck over time. In the end, skill makes the difference. Do not use chance for large issues unless the player knowingly takes the risk.

PvP

Symmetric PvP games can get boring: players end up using the same strategy. It can be hard for some symmetric games (Go or RTS) to have a non-cheating AI better than humans. Players accept a cheating AI (able to see units in fog of war, faster production, ...) in very hard mode, not in easy. Basically, the game becomes asymmetric when players accept a handicap.

Difficulty

At least two factors are outside designer's control. Players have a previous experience acquired by playing similar games of the genre. Players have also a native talent (hand-eye coordination, reasoning, ...). Other factors that the designer can control to adjust the perceived difficulty are: intrinsic skill, stress, power provided and IG experience.

Absolute difficulty of a challenge = skill + stress required compared to the trivial case (static, harmless, one-shot-killed enemy in an FPS)
power provided = avatar's strength, subject to feedback loops. Ex: spell, powerful sword, HP, ...
relative difficulty = absolute difficulty - power provided.
IG experience = how often the player has been exposed to similar challenges throughout the game.

perceived difficulty = absolute difficulty - power provided - IG experience.

Problem with adaptive difficulty: player may learn to trick the AI in pretending to be bad throughout the game and play well at the very end to crush the AI. Moreover, finding a relevant success metric is sometimes hard. Adaptive difficulty should not be obvious to the player, otherwise it feels like patronizing. Adaptive difficulty can be used to make the game harder for players who choose it, though.

Positive feedback

Discourages stalemate and rewards success usefully (not just cosmetically). To control positive feedback,

Rewards should not be too big
increase absolute difficulty as player gains rewards, so that relative difficulty stays in control
allow players to team up against the leader
make victory conditions unrelated to player power
use chance to decrease player rewards (random loot, ...)

Tips

Stagnation happens when the player does not know what to do because she does not have enough information. Ex: finding a secret exit door hidden somewhere in a Doom level. To avoid stagnation, give hints.

Players should not have to waste time on trivialities (micromanagement) when they want to take higher-level decisions (strategic positioning of armies), unless they ask for it. Ideally, the game should let the player decide the levels she wants to be in charge of. Experts can choose to micromanage.

How to tune easily:

Factorize mechanics shared by multiple entities,
Modify one parameter at a time to see its effect,
To measure the effect of a parameter, double or halve it,
Keep track of the tuning done so far, so that you do not do the same tweak twice (saves time)

[Literature] Fundamentals of Game Design, ch 10: Mechanics

noreply@blogger.com (gentimouton) — Mon, 25 Jul 2011 15:58:00 +0000

The mechanics are the data and algorithms that define the rules. Mechanics implement the internal economy inside the game engine and present challenges to the UI perspective. Mechanics are also in charge of the NPC AI, mode switching, and links to story engine. The mechanics define how resources can be created/deleted/exchanged, the state or attributes of entities, and the relationships between entities.

Economy

Quantifiable entities are produced by sources at spawn points (health pack in FPS or gold mine in RTS), consumed in drains (shooting consumes ammo, units cost resources), and exchanged through traders (exchange A against B, both A and B exist) or converters (A is consumed, B is produced). Players do not mind getting money for free, but they want to know why they lose some. Explain the drains. A resource is tangible if it takes physical space (space- and weight-limited inventory in Baldur's Gate vs potion stacking in RO vs limitless inventory in JRPG).

If the player has no way to get into a feedback loop, there is a deadlock. Example: when player has no money in Monopoly, she can't buy properties, and can not get money.
Mutual dependency happens when two production mechanisms require each each other's output as their input.
Equilibriums relieve pressure from the player: she can just sit and watch what happens. Therefore, there should be a mechanism to break the equilibrium or require player's intervention (e.g. farms in Age of Empires produce food automatically but expire after 3 harvests). Static equilibrium happens when offer = demand. Players can see their impact instantly in static equilibrium. Dynamic equilibrium happens when the same production cycle repeats itself over time (offer and demand follow patterns). Players may have to wait to know if their actions disrupted the equilibrium.

Mechanics and gameplay

Passive challenges do not require the mechanics to operate (e.g. climbing over a wall). Active challenges (solving a puzzle) have the player progress between states to reach the solution state. However, the player often has the same actions to solve all challenges (jumping, shooting, running).

Guidelines for designing mechanics

Strive for simplicity: do not make more mechanics than necessary. Occam's razor.
Do not try to get it perfect on paper. Playtest instead.
Give enough details to programmers, but do not waste your time going too deep. Minor bugs and misconceptions can be fixed at tuning time.
From higher-level game design documents, detail what the player is going to do, the flowboard of the game's modes, outline of the story, level ideas and progression, and victory and loss conditions.
Do your entities: store resources? Are affected by processes? Have state and transitions? Have relationships with others? interact with or by the player (and how)? Also, find verbs these entities will enact.
Resources: detail how sources, drains, and conversions work.

Debugging tip: always use the same seed in random number generators.

[Literature] Fundamentals of Game Design, ch 9: Gameplay

noreply@blogger.com (gentimouton) — Sun, 24 Jul 2011 15:52:00 +0000

What makes a game fun

50% from quality assets, UI, and code. 35% tuning and polishing. 10% imaginative level design. 5% innovation. A pinch of luck.
Guidelines

Gameplay before story and graphics
get a feature right or leave it out
player-centric, know your audience
abstract or automate the boring parts
be true to your vision, do not add stuff for marketing or in hope of getting more players
aesthetics matter

Challenges

Gameplay is in the challenges.

Challenge hierarchy: to complete the game, the player has to complete chapters, levels, missions, and atomic challenges. Atomic challenges are what player focuses on at the moment. The game victory condition should be explicit, as well as the atomic challenges. Intermediary challenges can and should be implicit: the fun comes from figuring out how to use the atomic tools to reach the end goal. That's why the player should be rewarded whatever path she took or means she used.

Many simultaneous atomic challenges put stress on the player (e.g. Impossible Super Mario levels). Difficulty = intrinsic skill + stress. Intrinsic skill = level of skill required to overcome a challenge without any time limit. Sudoku is pure skill. Stress = perception of time pressure for a given skill level. Tetris is pure stress. Therefore, to make the game easier, give more time to complete skill-based challenges.

Commonly used atomic challenges:

Physical coordination (hand-eye): speed, accuracy, timing and rhythm.
Logic and maths: challenges solved by reasoning power alone. Rubik's cube, puzzles
Race: time pressure reduces strategic thinking.
Factual knowledge: Trivial Pursuit, quizzes
Memory: French Tarot
Pattern recognition
Exploration: spatial awareness, locked doors, traps, mazes, teleporters. Should still have challenges, otherwise it's sightseeing.
Conflict: strategy, tactics, logistics, defend weak units, stealth. Checkers, chess, Heroes of Might and Magic.
Economic: accumulate resources (RTS), balance a complex economy (SimCity), care for living things (Black and White)
Lateral thinking: there is no obvious solution.

Actions

Actions are IG events directly and immediately influenced by player's input. Player spends most of her time using actions to overcome atomic challenges. Therefore, particular attention should be given to how actions can overcome basic challenges.

Some actions do not overcome challenges, but provide hooks for unstructured play (honking in a racing game), creation/expression (customizing your avatar), socialization (emotes), and story participation. There are also meta-actions: loading, saving, configurations, exit, ...

Saving

Save files are good for testing and debugging. In general, saving harms immersion and story flow/discovery (player can see different branches by reloading and taking different choices). Always allow the player to save and reload the game. Saving can be implemented through:

level passwords (levels of Lucky Luke for Gameboy),
save slots (player can keep copies of his progression and try different things, Doom),
quick save when pushing a key (Baldur's Gate 2),
automatic save/checkpoints (mid-level checkpoints in Mario platformer series).