This year, unlike previous years, I’m taking notes in my iPad instead of in my notebook. That means that I can generally read my notes, which is good; but it also increases my tendency to just write down slides with minimal commentary, editing, or even formatting. (And I’m sure that amusing iPad autocorrects will slip through, too.) So I apologize in advance for such infodumps: I wish I had time to do a better job, but if I let these posts pile up, I’ll be pretty unhappy.
In retrospect, it was kind of amazing how many talks I went to today: two sessions were really three separate talks each, so that adds up to 11 talks! Wow.
This talk (or at least its first third) was my surprise favorite for the day: I’m pretty sure there’s a lot of object-oriented wisdom here, if I understood what was going on better. Anybody have recommended books on the approach presented here?
It was really three talks in one; the first, by Brett Laming on “Component Systems Revisited”, presented the basic foundation.
He started off with problematic approaches:
- The class hierarchy
Ogre : Monster is simply wrong.
- Next, he presented a complex inheritance diagram with multiple inheritance, including a diamond. Worse, you run into situations where you have existing classes A and B where A derives from B, but you want A’s behavior but not B’s. So “deep class” is a problem.
- Next, you push common functionality up, leading to a “fat class”.
- Or you use aggregation to get plugins; lots of indirection, though.
- A data driven approach comes next, but it’s hard to debug.
There are seeds of good ideas in all of these, but you need to know what to pick and choose from them. The metaphor that he suggests is that of a “component”, e.g. as on a circuit board: it gives a broad classification (diode, resistor, capacitor, …), with key properties (that aren’t visible in the class hierarchy!), with defined inputs and outputs, that are interchangeable.
He also added a note on reusable AI: its outputs feed to the gameplay, its inputs come from the gameplay world. And disciplined gameplay is naturally linked to good organization, purposeful data, and sensible lifetimes.
The body of his talk was on five aspects of a component architecture. The first was inheritance:
- Classify where necessary, to define key slots. (Surprising mention of RTTI, e.g. for sorting.)
- Name: RTTI Factory creation; ability to serialize.
- Combined: Data driven approach, with a shallow hierarchy.
This discussion of run-time type surprised me, because I generally see it as a smell. But he was pretty emphatic about its virtues: he called RTTI “as important a tool as a smart pointer or a weak reference”! I think naming is one key route into what he’s thinking: he wants to be able to serialize and deserialize objects in a very flexible manner, to increase the power of tools at game designers’ disposal, and sees RTTI as a key part to that. (But I don’t think that’s the only thing going on.) He also gave examples of macros to help with RTTI (as opposed to leaning solely on what C++ provides), which also makes it more efficient.
The next aspect was structure:
- Spatial: reference frame, world transform
- Functional: composition and aggregation
- Dependency tracking: conflict resolution, job ordering
The third aspect was data flow:
- Data flow: world state -> AI -> gameplay -> world state
- Changes to structure: messages upstream/downstream
- Changes to properties: signaling downstream/upstream, message for spatial barriers
The fourth was compartmentalization:
- Smart objects, reconstructable via RTTI
- This is nearly free, given good structure
- External instructions: AI, animation, etc., carried by signaling
And finally, parallelization:
- The ideal is still a way off
- But AI/gameplay still parallelizes, even in game graphs! (Mention of indirection, aliasing)
- Candidates for parallelization: Leaf output: animation, navigation, component update. Leaf input: sensory info, blackboards, ray tests
He ended with some design tricks:
- Remove temptation: minimal data (if per frame, put it on the stack), minimal lifetime (use new/delete boundary, object pools)
- Favor derivation: no equation contradiction, no duplicate data
- Potential deep class problem: generalize
- Locality of reference: abstraction+composition, placement new, embedded lists, object pools
- Minimize NULL checks: use Null Objects instead when necessary
- Non-virtual pathways: use RTTI filtering
- Many virtual pointers: package once and carry downstream
And his conclusion:
- Gameplay gives us fun buttons to press: tight gameplay leads to good, reusable AI
- Think: minimal classes, data lifetime, locality of reference
- Use: generalization, RTTI, placement new/delete, object pools
Next, Joel McGinnis on “AI Design Patterns”.
The pressures you’re under are: resources (compute cycles, memory), and design specificity (or lack thereof…). Component architectures give you flexibility, and allow performance balancing. He warned that it’s not a blueprint, though: you still need to architect, so it’s not a solution, but a framework for how things can get built.
One antipattern he mentioned was putting data on AI component. Instead, think about the data that the AI component needs to consume: focal point, targetable object, cover markup, interaction point, trigger volume… Granularity is great with component architectures, gives lots of flexibility.
Pattern: Component Matrix
Entities, behavior tree, pathfinding, targeting system, animation, standard movement. Makes it easy to substitute parts out: e.g. if going from lithe enemy to hulking enemy, prototype by swapping out pathfinding component. Lets you answer design questions with minimal investment.
Pattern: Find Via Registration
E.g. target selection looks for targetable objects; both halves register with the targeting system, so you don’t need to search all objects in the world. Reduces the search space by scoping, simplifies construction of behavior, easily done via lifecycle management.
Pattern: Late Construction of Types
Lets you change your minds late in the game, do load balancing: try it everywhere, keep it where most effective. Requires things to be light weight, and data driven helps
And the third talk was Alex Champandard on “Performance and Multi-Threading”.
His talk used influence maps as an example component. How do you make it high performance? You want to use vectorization: SIMD instructions give a 4x performance boost. Then parallelization might give another 4x performance boost.
The solution is to build your build your engine as modularly as your entities. And use the same breakdown in both cases.
He gave an entity example. Then he talked about the system, which does: batching and prioritization. Don’t process individual requests, instead schedule jobs. Custom allocation by jobs to allow interleaving, SIMD. (C.f. the mention of placement new in Brett Laming’s talk.)
Summary: very lightweight, simple interface, handles events, data-driven. Pay attention to memory allocation, computation limits, batching, prioritization. This leads to jobs that are computationally intense and support parallelization.
His question: what kind of ethical knowledge do future game developers need to know? But first, definitions:
- Morality: a public system, governs behavior towards overs and how to avoid harm. A system of rules, and principles for evaluating those rules; principles stem from ethics.
- Ethics: the philosophical study of morality. Framework for analysis of moral issues via a coherent, philosophically argued scheme. Provides evaluative standards for development of principles/morals, not only to avoid harm but also to help human flourishing.
There are moral issues of: profession, art form/medium, games in society, and play. We need guidelines. And his outline of a method for acting ethically was: Identify potential moral issues. Analyze and contextualize them. Deliberate about them, applying ethical theories.
He then talked about four ethical theories, linking each with a problem.
The first theory was consequence-based ethics: decisions should be taken based on consequences. Evaluate based on most desirable outcome for society. This is either act-utilitarianism or rule-utilitarianism.
Data mining and profiling raise moral concerns, especially profiling. Utilitarianism suggests: informed profiling is good as long as most players feel it as not harmful.
His second theory was duty-based ethics: centered on obligations towards others, trying to pursue happiness without harming others. The golden rule.
Duty applies to software and hardware dev: duty of developers to players (which is different from consumers!). Software must allow for play (anti-piracy software problems); some games (e.g. educational) need to be played on legacy platforms.
His third theory was contract-based ethics: contracts between individuals that form society. Often used in the case of right-based issues.
Community management shows how you can use this: a game is not just an entertainment product, but also an implicit contract between developer and players. Developers should understand that the way their communities are managed should allow for ethical reflection.
And his fourth theory was character-based ethics: instead of rules, consequences, contracts, we should focus on being good. Development of virtues and good characteristics leads to general morally good behavior, even in unexpected/new cases.
This helps inform our understanding of player behavior: it’s done within spaced created by developers. Developers should think about good virtues of good players, and create appropriate affordances in the design.
One approach towards ethical issues is via professional codes: these give guidelines for solving issues. If an issue affects the profession, professional codes should help. E.g. crunch, bad management, sexism. Do we need a professional code for game developers?
(Time ran out here.)
His basic thesis here is that coding is an idea generator: seeing how code behaves is a great way to confront yourself with surprising realities.
Exhibit A: A programmer making a game based on pentominoes, in order to explore a new computer. No graphics, text-based. He’d just implemented bit where pressing key rotates the piece, and spent a while playing with it: this real-time component is surprisingly powerful, opens up a new world.
He simplifies pieces, adds gravity, leads to Tetris. But: when he started programming it, he didn’t even have the idea yet!
Exhibit B: Jonathan Blow talking about how billiards would change if you could see the future. He did prototype, felt weird seeing it unfold, how the balls ended up where they were supposed to. He didn’t figure out how to make a game out of it, but it sparked ideas that led to Braid.
Exhibit C: A Game Mod workshop for graphic design students with no coding experience. He started by giving them a Breakout clone with no void at the bottom (so balls never went away), implemented in a relatively friendly language called Processing.
He told students to download Processing and the code, to change it, and to make something awesome in six hours. He then showed a video of students’ results, which I thought was really impressive.
Exhibit D: He talked about his background: started as graphic designer, evolved into coder, where in his game Eliss almost everything is produced by code rather than static images.
The takeaways:
- Code makes you stumble into ideas.
- Coding is: complex; precise; unpredictable.
- Code is already there: if you discover something while coding, it’s working right in front of your eyes!
- Simplicity first: you can feel the complexity of code, so it encourages you to keep things simple.
Finally, he ended with a live example using Ruby-Processing. Starts with static circle, adds random movement. Leaves trail, which is kind of interesting; then redraws background to remove trail. Makes background white, circle black.
Then does same thing with 100 circles at once: starts as growing blob, then individual circles emerge from it. Plays with size of circles: makes them small, more like particles. Large, makes everything a big blob. Random starting position, turns whole screen back, but then puts in outline. Then fills them with alpha, leads to smoggy cloud.
I really liked this example: at several points I was really surprised at shapes and behavior that emerged from such simple changes.
Lunch
I had a very nice chat with Ben Abraham, Jorge Albor, and Brendan Keogh.
Impossible 1.0: Red Alert 2: made by a team with no RTS experience, made it in 9 months.
Leading up to FarmVille: Zynga was “small”, Mafia Wars was the big dog. His team was trying to make a medieval RTS game, but was stuck in design limbo. Bing Gordon: “Wy don’t you just make a farm game?” Decided to take a small team and go for it.
Fast, light, and right. Single strong voice, passionate team, mission. 5 minute design: if you can’t figure out how to make something more fun, just go with the obvious solution. Only design screens and flows: what the player sees and does. Help from organization: took YoVille avatars, borrowed people.
Decision time: Zynga hardware or Amazon cloud? Zynga’s center ran out of space and power; would have had to wait 6 weeks for more servers, so went to Amazon, which turned out to be crucial for rapid scaling.
Minimal art content for shipping. RTS interface to remove friction, set context sensitive cursor, add queuing.
True Minimum Viable Product: no monetization, almost no metrics at launch! Not at parity feature-wise with other farm games, but a better user experience.
Team goal: 400k DAUs by June 30: 11 days after launch. SVP Biz Dev: if you hit 1M DAUs in 30 days, we’ll take you to the French Laundry. CFO: if you do it in 11 days, we’ll send you all to Paris! They hit it in 5 days; they got the dinner, but not the trip…
That’s Impossible 2.0: people kept thinking growth would stall at various points, it didn’t. Thank goodness that they were on the cloud. But still: had to watch the servers, had to scale the team.
Also unusual: keep the brand pure. Would Disney put this in Finding Nemo? Target audience is moms; don’t want anything in there that moms wouldn’t like; this led to tension with Mafia Wars ads.
One surprise: everything is much harder after launch.
Leading up to CityVille: Zynga was much bigger, they’d had another six games under their belt. FarmVille was still the biggest; Facebook had changed what was allowed, players’ expectations had changed, Zynga’s best practices had changed.
So: what’s Impossible 3.0? The wisdom at the time: FarmVille was a once in a lifetime success, Facebook policies mean you’ll never pass 10M DAUs, their internal model showed a city sim stopping at 5M. Lots of questions: gameplay style, who should develop it (send to their Austin studio?), full featured versus Minimum Viable Product. They spent too much time in paper design which led to imagining problems that might not materialize, so they switched to producing prototypes.
They set a date, locked in art style and rules. Lessons and features from FrontierVille: quests, stories, doobers (loot drops). Converged in Aug/Sep: narrowed scope, get real about date, push for quality. Still, story was missing, and fun wasn’t quite there.
Key mile markers:
- Aug/Sep: team gels
- Sep: game playable, but not fun
- Late Sep: first bits of fun emerge
- Oct/Nov: team plays the game
- Nov: hold for quality, public announcements. Was supposed to be launch date, but game wasn’t good enough. Very different approach compared to FarmVille launch.
Proactive launch steps: lined up external teams to help with live services. Quality high: easier to fix bugs before launch. Feature roadmap. Was smooth compared to other Zynga launches.
They reached 8M DAUs in 2 weeks, 14M in 30 days, over 20M now.
What turned out well: Social: people’s faces, franchising your business. Game loop: right balance of simple sim. Quests.
Could be better: Trains are only kind of cool. Simpler interface for franchises. Expansions were too easy to get. Longer runway on the simulation. More surprises and easter eggs.
Could be better in the process: Didn’t have single strong voice with clear vision. Bigger product, hence more test and integration time. Maybe should have done Minimum Viable Product; not at all clear, though. No scaling plan. No features in the back product, ready for quick deployment after launch.
Meta lessons for social game developers: It’s entertainment: good looking, fun art, fun core gameplay loop. You’re building a product, a team, a 24/7 business, a platform. The battle is won before the launch, fix bugs then. Learn the space, know key features/recipes, know the audience. Speed wins: get to market quickly, and it’s a web experience, so performance matters. Deliver fun: “you can’t make up for boring with volume”.
He started off with pictures from Fallout 3 that involved posing large numbers of teddy bears.
Is player expression for you? (I.e. indies, this was part of the indie games track.) Yes: indie attainable, indie appropriate, for the good of the art form.
How? Don’t have a string of pearls guiding users down a specific route. Don’t include single solution puzzles. Then a Scrabble example: the game looks expressive, but to do well you need to use words that never get used in real life and that don’t say annoying you’d want to express. So: scoring can harm expressiveness.
Example from in-progress Tiger Style game: need to grow biomass to progress. But: all lifeforms contribute biomass, not much is needed to progress. So: tell the player “just play the game”, but there’s also depth on demand.
Also, units have multiple functions: can be enemies or allies depending on the context, depending on what you’re trying to accomplish at the time.
Empower the user to generate data; I didn’t quite catch the example here.
Finally, let the user use the generated data. (E.g. players sharing screenshots of avatars / levels.) Achievements also help acknowledge what the player is trying to do. Stats can do that, too: largest web, longest jump, not just a single score. (In particular, these stats in Spider never block your progress, they’re depth on demand.)
Indie developers work at a job that can cause stress, overwork, being unhealthy, being poor, being lonely. And there are also potential personal causes of depression. So: some indie devs are depressed! Not always easily solvable, so need techniques for developing while depressed.
Being unproductive and being depressed reinforce each other. Or: if you can be productive, this gives control over our work, our lives. So, ways to increase productivity.
1) Work on rewarding projects
These are good to build. Get to the gameplay, don’t get bogged down. But be careful: don’t front load the fun stuff to the extent that there’s only slog left over. Instead, make as much of the project be reward as possible!
Complete vs. progressive gameplay. Progressive is semi-playable almost at once; a complete game needs almost all the systems before its playable. Lean towards the latter.
Awesome/crazy ideas are more rewarding, easier to keep the faith.
And: design for yourself. Keeps up day to day interest.
2) Try to stop being a perfectionist.
Don’t overthink everything. Get other people to play the game. Skype somebody else to tell them about the flaw you’re worrying about, they tell you you’re worrying too much. Play lots of games (Steam, XBLIG, demos.)
3) Shorter projects
That way you spend more of your building time in the phase where you’re excited about the game. So: small bad is no good, want small awesome!
4) Measure your hours
Otherwise, you’ll work less and less when depressed.
5) Design the game to suit your abilities
What do you love? What do you hate? Use the resources that are available to you. The trick is understanding what you have.
Finally: how does being depressed change how you work?
A game is a thousand tiny choices. These are affected by your mood, your priorities. The distinct choices of a personality can be an advantage; bad experiences can be a particular advantage. (Artists in love are boring, ones that have gotten screwed over in love aren’t.) And depression is an experience.
Another three-speaker talk. First was Jake Kazdal: “From AAA to aaa”. I mostly napped during this.
Next, Daniel Cook: “Spry Fox, Year One: Lessons Learned”
A portfolio approach is key. Great games are not enough: have to hit right platform at right time with right theme. Portfolio model helps reduce that risk.
Flash portals are so used to taking games essentially for free that they don’t understand your asking for money. Very few portals that respect the needs of developers at all. They also don’t understand payment systems, microtransactions. Most important: bring people off of portal back to your website.
Too many designers are like too many cooks. His teams converge on the fun so much faster now that there’s a single creative director for a project.
Teams should aspire to iterate daily. A week is bad; two week iterations and your design may never converge.
Building meaningful hobbies is hard, but worth it. Want people to be playing ten years from now. Tend to be multiplayer, tend to be a service, tend to monetize well, tend to build relationships. But really, really hard to build. And game developers don’t traditionally have those skills, that’s why web developers are doing better in the social game space.
When hiring people, make them do a real project: that lets you see if they can finish. Great teammate: reliable, able to see big picture, works well with others, respects the game designer.
Missing from list: willing to work long hours. (Crunch is wrong.) Passion isn’t enough, and can mean obstinate. And no need for people to be located in North America.
Finally, Ichiro Lambe; I didn’t catch the name of his talk.
Think holistically. Conventional wisdom: wear many hats. True, but the mistake is thinking of things as separate problems, instead weave them together. (E.g. marketing + bug support.)
Tie marketing into design. Conventional view: marketing = getting people to buy crap they don’t want. Instead, create a game that people give hard-earned money for it, and that is remarkable! Make a game that’s both a game you want to make and a game that people want to buy. So: create a game that we’re excited about, and that will sell for stated reasons.
He ended with a bit on postmortems / retrospectives.
Posts