MVC and modularity

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:

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

The scenario is slightly different for clicks.

1. Input controller receives click type (left/right/middle/both/...) and click position (x,y)
2. Input controller gives the view controller the click type and the position.
3. From the click position, the view controller parses the list of sprite coordinates and dimensions to detect which sprite(s) has been clicked.
4. 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).
5. 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

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

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.