BMFontRenderer is under the MIT license, so you can use it as you like.

Here’s an example:

// Load the font.
var bmfont:BMFont = new BMFont();
bmfont.parseFont(font);
bmfont.addSheet(0, (new fontSheet()).bitmapData);
            
// OK, draw some text!
var out:BitmapData = new BitmapData(200, 100, true, 0x0);
bmfont.drawString(out, 0, 0, "Hello, world!");

(You can see the complete example in BMFontRenderer’s GitHub page.)

Great. So – why would you want to use this, given TextField is right there, waiting for you? (Translation: why did you get fed up, Ben?)

It comes down to control. TextField has a TON of knobs and buttons you can set. They all do semi-obscure things which are, in and of themselves, very exciting, but confusing to work with if you aren’t a font expert. Worst of all, it pulls font data from hard-to-inspect places that are populated by mxmlc at compile time or located on the user’s system, so you get different visual results depending on who is running your app, where and when you compiled it, and maybe even what browser it’s in.

The Flash IDE does a good job of hiding all this, and for beautiful animated vector text created by an expert in the tool, there is a great workflow. But when I need to show a high score at an artist-selected size in an artist-selected-and-provided font that has artist-approved antialiasing so it looks good on top of the artist-created background, it can be a lot easier to let the artist export the exact characters they want, how they want them to look, to a PNG. Then all I have to do is copy pixels around.

Fonts are less restrictive about licensing if you ship pixels instead of TrueType/vector data. Shipping raster data can save you a couple grand in license fees, nevermind cut down on your download quite nicely.

Doing it this way also puts 100% of the font handling code under your control. There are no parts you can’t debug, analyze, optimize, timeslice, or otherwise fiddle with. Never underestimate the value of this when you have a deadline. This is why I love libraries like Sean Barrett’s stb_truetype.h, which is a self-contained TrueType font renderer in a single C file.

There’s another fantastic bonus. Once an artist has characters in a PNG, they can open them up and tweak them – distress them, add glows or cutouts, or anything else that Photoshop can do. That’s a big realm of possibilities, and a lot easier than learning a font authoring tool.

To be sure, Flash’s built in font rendering has solid uses. If you need to dynamically animate, scale, or rotate text, you need vectors, and Flash has got you covered. If you want to display fully arbitrary unicode text, you may need to fall back on system fonts to fit in your download budget (PushButton Engine has a nice glyph cache for speeding up rendering, though). Or if you are working with people who are very comfortable in the Flash IDE, why not use a system they are familiar with?

For everything else, there’s BMFontRenderer. Enjoy!

I’m working at a technology startup and today I am talking to one of the founders. He looks at me and says, “Our main product is a declining asset.“

This is the product that generates 90% of our revenue and pays both of our paychecks. It’s the one that made our company a success, put us on the map.

Uh oh.

NOVEMBER 12, 2011 – ADOBE’S BIG IDEA

If you watched the Digital Media section of Adobe’s recent analyst meeting, you know that Adobe is putting a lot of focus on HTML5. Their recent announcement regarding dropping mobile web browser support for Flash Player caused a lot of turmoil, too, along with a shift in direction for the Flex SDK, their enterprise app framework.

If you look at the marketplace and the technologies at play, it seems that Adobe has realized that Flash’s position in the marketplace is eroding, that the erosion probably can’t be stopped, and they need to treat Flash as a declining asset. Just to review, here are some reasons that Flash’s position is eroding:

• The many 3rd party mobile, native, and web-targeted development tools like Corona, Moai, Unity and others.
• Non-Adobe Flash runtimes like Scaleform, Iggy. Companies like The Behemoth have their own Flash-compatible runtimes, too.
• And of course the big one – HTML5. It can handle more and more enterprise apps, animation/multimedia content, and 3D. Browser vendors are in competition but increasingly targeting Flash-like capabilities.

Long term, HTML5 and other non-Flash technologies are unlikely to go away. Adobe may as well be proactive about owning the space rather than fight an unwinnable battle to keep everyone on Flash.

One more point to consider: Flash is made up of three big pieces. You have the tools, like Flash Builder and Flash Pro. You have the runtime, like the web plugin, the standalone player binaries, and AIR for desktop and mobile. And finally, you have the platform itself – the file formats, AVM specification, compilers, and APIs that define the behavior of Flash content.

They are all independent to a greater or lesser degree. The only part that probably wouldn’t migrate to HTML5 is the actual runtime (but see Gordon). And Adobe has been rumbling about compiling AS3 to JS/HTML5 and supporting C via Alchemy 2.

LABELS AND COMMUNITIES

Now, the funny thing about that conversation from four years ago is that, because of the mental label of “declining asset” we assigned, (at least) two interesting things happened. First, the company got acquired and tried to diversify into a couple of new markets. Second, I along with a few other guys left the company and went on to start a new one.

But the “declining” product continued to make more money than ever before. And in fact, it lives on today, despite the original company getting liquidated by its owner when the diversification strategy didn’t work out. So what does it mean, exactly, to be a declining asset?

I think “declining asset” is a label you put on something to help you make decisions. In Adobe’s case, the decision they made was to move their long term focus toward HTML5 and away from Flash Player.

There are some important things to keep in mind with the communities that develop around technologies and products. First, realize that the conversation is often dominated by the vocal minority – so what is said most often and loudest often doesn’t reflect on the actual needs of your user base. Second, realize that the people who post on your forums are emotionally invested in the product, have it as part of their identity, and they will be deeply unsettled by any signs that support is fading. Finally, realize that users often have a limited perspective. Community members are not tracking major market trends, they are looking at how they can meet their immediate needs (like getting contract work or finishing a specific project).

In other words, the community tends to act like a mob.

And I saw no better example of this than when I was on a group video chat last week and saw Flash professionals practically weeping, calling out Adobe representatives, demanding, threatening to break up, over these announcements. It was more like seeing your drunk friend vent over his ex-girlfriend than it was watching a group of well-respected developers discuss their future. Everything is in a turmoil, it’s the end of the world, everyone is screwed, etc.

REPORTS OF FLASH’S DEATH

Ok, but that isn’t actually the end of “Flash” as a whole. Probably. Even though it really sounds like it. Let me explain.

Adobe has a ton of outs from this situation that let them preserve their and your investments. The most obvious out is replacing Flash Player with HTML5. You export from Flash Pro or Flash Builder and it runs directly on HTML5. In fact, they have been inching towards this in different forms for a while now (the conversion tool on Labs, Edge, Muse, etc.).

Even if they drop AS3 and go with JS, their tools can still be useful. If Flash Pro can still create banner ads and interactive experiences for a large audience, who cares what the output runs on? Life will continue relatively unchanged for a lot of Adobe customers.

There’s also a more subtle out:

HTML5 has its weaknesses. Lots of them. But public opinion supports it. Maybe it’s just a Betamax vs. VHS difference. Or maybe HTML5 is doomed due to the conflicting goals of vendors and the difficulty of the implementation task.

Maybe HTML5 ends up being great for less demanding uses – like basic enterprise apps, ads, motion graphics, etc. – but can’t get it together for highly demanding and integrated stuff like games. Adobe can keep Flash around and focus specifically on the game use case – which, by the way, is also highly beneficial for non-game apps, since they tend to use subsets of game functionality – and get as much value from it as possible for as long as possible.

Between the games angle and inertia, Flash could remain relevant for years. It could even end up totally dominating that space for a long time to come, even as HTML5 takes over the bottom of the market, due to being able to be more focused and agile.

CONCLUSIONS

Let me add two caveats. First caveat: At some point you can only expect so much out of a platform – you can’t get a guarantee that it will remain relevant for ten years. Even proven, still-relevant technologies like C have had their death announced many times. At some point you just have to say, “well, N years more relevance is good enough and I’ll re-evaluate in a year.”

Second caveat: Maybe Adobe screws the pooch and that’s that. Maybe they cut too many resources from Flash. Maybe they don’t build good stuff on HTML5. Maybe they ruin everything. So don’t bet the farm. Make sure you learn a few different technologies well. It will make you a better developer, even if you still just do Flash work day to day. And you’ll sleep easier knowing that if worst comes to worst you have an out. I’ve never seen a successful programmer regret having learned a new language or paradigm.

I don’t think Adobe is making bad decisions, just difficult ones.

Bottom line: Flash is a declining asset, but declining assets aren’t dead or even out of the fight. Everyone needs to look at technologies on their merits and see if it’s a good fit for your needs. There are a lot of places where Flash will continue to be a good fit for a while to come – and the places where it is ambiguous deserve careful consideration regardless of Adobe’s stated plans.

(Thanks for reading! If you liked this article, please consider voting it up on HackerNews or Reddit)

All 12 are now online again, thanks to Eric. I’m especially proud of the history of every MAME-supported baseball game from 1976-1985, the article we did for GameDev.net titled Learning from the 3000 Classics, and our review of the 90s arcade version of Aliens.

Check ‘em out!

You can find the code for the talk at https://github.com/PushButtonLabs/PushButtonEngine/tree/PBE2. They are fully explained via dokko, a literate code documentation tool. You can read the docs online at http://pushbuttonlabs.github.com/PushButtonEngine/v2/docs/PBEDemos.html.

A big thank you to everyone who came, and to Adobe for inviting me to speak! It was a real pleasure. MAX was great, and I’m already excited about attending next year.

I’m doing a session, Building the Best Gameplay, on Tuesday, October 4, 1-2pm at Adobe MAX in Los Angeles:

Take a dive deep into the techniques required to build the best games. Building games is fun, but building them well takes skill and experience. Ben Garney, core Flash architect at Push Button Engine and one of the most well-known names in the Adobe Flash gaming industry, will put some powerful tools into your game development toolkit: finite state machines, numerical simulation, components, data-driven definitions, and more. Build better, more interesting games faster and with less risk.

If you’re a Flash game developer and/or PushButton Engine user and you’ll be in the LA area around that time, I’d love to meet you. Tweet me at @bengarney or drop me a line via other means.

So developers like Ben Garney are opting to write their own renderers in order to gain better performance, but that is not an ideal long term solution. A much better one would be to utilize both multi-threading and GPU hardware acceleration for the standard flash Display List.

We are seeing an uneasy alliance between Stage3D and DisplayObject. They work together but not fantastically. How can Adobe reconcile these two different worlds? As Amos points out, it’s a lot like the bad old days in the early 90s when UI libraries were non-existant for OGL/DX and games got by with the bare minimum in terms of UI.

Flash is pivoting from a rich content web runtime to a platform. Things that were previously built into the player need, in my opinion, to become a minimal native API that is enriched by powerful libraries. The display list is a great example of this. 90% of what the display list does can be done as well or better by pure AS3 (in fact, if you look carefully, many of the native DisplayObject methods are actually implemented in AS3). So why not move all that functionality into an AS3 library that comes with the platform, and focus on making the remaining 10% as good and generally useful as possible?

It’s like how an operating system has just a few basic routines for working with the file system, on top of which people build a wide variety of powerful tools like Finder, Explorer, Google Desktop, Alfred, bash, and so on.

The Flash team and the surrounding community has done the software world a tremendous service by developing great ways to build rich interactive experiences. Tweening and the display list are key foundations to those techniques. But they can work anywhere, and in almost any language – take a look at Sparrow, for instance, which provides a lot of the Flash API on iOS.

If I was going to make a prediction for Flash’s future, it would be that long term the display list will take a step back in favor of core APIs like Molehill. Of course, there will still be a display list or display list like APIs, but they will be conveniences on top of fundamental capabilities. This not only follows the trends seen in OS X, Windows, Java, and other platforms, but also enables more innovation and choice on the part of developers.

I got some good answers back and wanted to save them:

On my todo list: Try processing!

Here is what is on my agenda:

• On Sunday, I will be at the Flash Gaming Summit. This year is not to be missed; Adobe is going to be announcing some great news, adding a whole new dimension to the capabilities of the Flash Player. As an advisor to the conference, I’m excited to see how it turns out this year!
• On Monday evening, I am speaking about “Building Gameplay with the PushButton Engine” at a FlashONGames event at 6pm on Feb 28 at Adobe’s SF offices. Some of my friends at Frima will also be there, showing off their awesome 3D Zombie game built on Flash.
• Monday and Tuesday I will be at the Social & Online Gaming Summit. It’s a natural point of interest, given that’s my career focus. And a bunch of cool people from Playdom (with whom we partnered to build our last game, Social City) will be presenting!
• Wednesday evening, I am presenting again: Building Gameplay with PushButton Engine at the Plug & Play Tech Center. The event starts at 5:30pm. (It’ll be similar to my talk Monday night but a bit longer. So if you miss one, come to the other! Or come to both, I guess. )
• For the rest of the week (thru Thursday), I’m at Game Developers Conference 2011, of course.

My schedule is busy but not crammed. If you are interested in meeting up, just shoot me an e-mail at ben dot garney at gmail dot com. I’m also on Twitter as @bengarney.

See you at the show!

Now, for the social game developers out there – let me help. You know that bad feeling you have in your stomach? That’s not embarrassment. That’s not inadequacy.

That’s guilt – it’s what other people feel when they are doing something shitty.

So, if you want to roll that way, fine. Just don’t waste your time justifying it to the rest of us.

– Jeff Roberts

Ouch. Before I respond, though, let me tell you about a recent trip I took to PAX in Seattle. It was a lot of fun; I got to hang out with a bunch of friends, play a great game of D&D and go to some awesome panels! However…

The most important thing I saw at PAX was Warren Spector’s keynote. The point that stuck with me comes about 32 minutes in, where Warren says:

When we go outside this room, when we go out the real world, I see people get sort of insecure. It’s almost like we yearn to get accepted by mainstream media and by normal people, you know? And yet, once they start paying attention to us, when casual gamers start flocking into our world, we start complaining about it. They’re diluting the experience. We get upset when developers try to reach a broader audience. Casual is perceived as the opposite, even the enemy, of what we do.

Social games are a billion dollar industry, maybe more. Farmville is played by approximately 1% of the earth’s population and it’s just one game. Farmville is free to play, yet Zynga is doing very well off of it.

Is this due to slimy business practices? Are companies like Zynga using viral marketing to get millions of people interested in a boring, brain-dead experience so they can drain their wallets one micro-transaction at a time? Are their games just vehicles for numbers driven, A/B tuned Skinner box tricks?

In a word: NO!

(At least, no more so than any other genre of game.)

Zynga’s designers have gone on record as saying that “Fun and monetization are synonymous.” Is that self-serving PR bullshit designed to reassure us? I don’t think it is. I worked on Social City, which won the Best Social Network Game at GDC Online. And we had the same experience. We focused on building a fun game, and it did better in the market than other games developed in the same timeframe by talented teams that focused on A/B testing, monetization strategies, or demographics.

Remember where I said that Farmville has been played by 1% of the earth’s population? Most of those people have never played games before. It doesn’t bother them, yet, that these games aren’t very sophisticated. That will come (this is where social devs are saying that “quality will increase”) as they become more educated. The audience will be more discriminating. Some will go on to play hardcore games, and that is cool.

Many will not. But that’s OK. Because the part of working on social games I like best is this: Social City is the only game I’ve worked on that my parents played and liked. I had a thirty minute phone conversation with my mom where she suggested new features! That didn’t happen with the twitch console game I worked on… or the networked PC space shooter I helped build… or even any of the hundreds of titles built on Torque (which I helped maintain). But a simple, engaging, accessible social game hooked her.

On Social City, when we had crunch time, the wives of the team didn’t mind (much). The wives wanted us to get bugs fixed and the new features pushed out so they could enjoy them! Some of the guys on the team had been doing games for twenty years, and this was the first time their wives really cared about the game they were working on.

A brief aside. What do I mean when I call something a game? Most people think of an interactive activity with a clearly defined goal and rules. If you fail the goal, you lose. Often, you accomplish (or fail to accomplish) the goal in one sitting. So, for instance, chess is a game, but painting is not. I think a lot of traditional game people come to the social space and look at the products with this definition in mind. Farmville isn’t a game, because you can never truly lose. Restaurant City doesn’t have a victory condition, so it’s not a game. Sometimes the term “activity” is used. Some people even use it as justification to reject social “games” as entertainment entirely!

But this is bullshit! There are very successful traditional game titles that don’t fit the win-lose model. Will Wright has done a lot of them. SimCity, for instance, only has “goals” if you choose to play a scenario (I never did… did you?). Nintendogs features dogs that will never die or run away. Microsoft Flight Simulator has done pretty well over the years, too. Most games, of course, do have win-lose conditions. But it is silly to view social “games” as an aberration because they often do not allow you to lose. Sometimes I feel like this lack of victory conditions throws people for a loop, though.

OK, enough with definitions. Let’s go back to Warren for a second:

And, you know, I don’t really understand it. As if non-gamers enjoying the things we have all grown up with, and we have all loved for years… As if non-gamers discovering that diminishes us somehow. … We have to get past this not wanting let more people into the club. “We don’t want girls and grandmothers.” “We don’t want normal people hanging with us.” … Basically, it’s as if we don’t know whether to fear or embrace the mainstreaming of gaming. And to my mind we have no choice. We have to embrace the fact that the world is catching up to us. Catching on to us. And starting to love the things that we’ve always loved.

I love working on social games because I am directly helping to bring millions of people into gaming, into experiencing the joy that games have brought me and that inspired me to get into the game industry in the first place. And I am doing it in a social space, where friends and families can play together. My favorite game experiences have always been social – playing Mario Kart, Quake, Tribes, D&D, or StarCraft with friends have always been joys, not because of the games but because of the way they bring us together. When my mom sends me a gift, or I get to see the cool farm, city, or restaurant my brother built, it is an opportunity for us to connect in a small way, and I value that.

Are social games a fad? I’m not sure. Maybe in five years “social games” won’t exist anymore. People might get bored or companies might get greedy or stupid. But I think that there is a legitimate place for games that are connected and browser based. Maybe it isn’t a $2B/yr space, but I think it is a viable market for at least a few companies to live off of.

Coming back to Jeff’s point: I don’t feel guilty about how social games monetize. Social games are free to play. No one is forcing you to pay. Facebook is very strict about how games can post to your wall or access your friend information. It might not be obvious but companies like Playdom and Zynga have teams of people whose job is to make sure that they conform to Facebook’s terms of service, because if they don’t, they are financially sunk.

Social games do want to spam through you, but at least on Facebook they must have your approval at every step – and they can’t gate the game on whether you allow spam or not. If you are concerned about it, don’t click yes. And if you aren’t having fun, you can disable the app. But millions of people do play, and continue to play, and some even spend modest amounts of money to add to their experience.

Should I feel any more guilt about making money than the guy at the gaming shop selling tabletop miniatures and Magic or Pokemon booster packs? Or the marketing guy at EA who sends ads to all the poor schmucks who filled out the registration form in their copy of The Sims? At least anyone who spends money on a social game has played it first, maybe for months, without paying.Doesn’t that put me in a better position, ethically, than the guys pushing box titles where you pay $60 up front to play what might be a crappy game?

Personally, I am grateful to work on products where I can build smaller scale, fun experiences and push them out to a huge audience. I am glad that it is a financially viable market where I can make a comfortable living. I love that I can be at a party and say I work on Facebook games and people have a clue what I’m talking about. I love that I don’t have to worry about licensing character animation, sound, or video libraries (although I have always been a huge fan of RAD’s products and highly recommend Telemetry ). And it’s fantastic that I can get realtime feedback on how people like new game features, pricing changes, and added content.

Are social games designed to keep you playing? Certainly. Do we tune them to try to make you want to spend money? Of course. Do we want to use your social graph to grow our market? Definitely. But the fact of the matter is that people are smart enough to identify and dislike games that take advantage of them. You have to give people experiences that make them want to come back, not ticking timers. You can’t force people to spend money right away and not lose your audience. And the thing that will make your game spread fastest is making a remarkable experience that people want to share with their friends.

Social games are taking their place along side many other successful kinds of games. Not every gaming experience needs to be a high-end single-player console experience or a twitch multiplayer FPS. Not every game player wants that. There is a place for accessible, people-oriented games in the world, too. No matter what type of game you are building, it’s a good thing for more people to be introduced to computer games. I’m pretty sure that people aren’t going to ditch God of War or Mass Effect in favor of Farmville or Social City – if anything, they’ll probably play both!

The demo at Adobe MAX 2010 was impressive, and it was a huge treat to see my friends at Mythos Lab and Alternativa get featured on the big screen during the keynote.

But let’s get back to reality. This is nothing that hasn’t been out on other platforms for years. Why is it worth talking about? Why does it matter when your PC can do way more?

It’s the audience. When Flash 3D drops, you will be able to create 3d content and bring it to all those billion people who have Flash Player installed. And I am sure that with Adobe’s focus on mobile, they will look towards mobile support, too.

If the model for AAA games like God Of War and Mass Effect is big budget Hollywood movies, then the Flash space is television. There are lots of short-form products (5-10 minutes avg playtime) produced by tiny and often independent teams (like much of what’s on Kongregate or Newgrounds). But there are also longer form products, updated weekly, that have huge distribution. In the TV space they call them series; online they’re called social games. The numbers are similar, too. Farmville gets 56M monthly players currently. How many people watch NCIS or another hit TV show in a month?

TV is probably still bigger for now, but social games monetize better per user.

So – 3d in Flash will have a big impact. And a lot of developers will be dragged kicking and screaming into the brave new world. I wanted to share a few lessons that I learned in my previous life as a 3d middleware developer at GarageGames. Some are big, some are small, but hopefully all are things that will save you, a Flash developer looking at this new hardware 3D, time and pain. They took me a while to learn.

Framerate and Performance

Don’t use frame rate as a measure of performance. It’s useless. All you really want is to target a fixed framerate of 30Hz, 60Hz, or 120Hz. Here’s how that goes down, by the way: your project will run at 120Hz until the artists get their hands on it. Then you will decide that 60Hz is a great target – looks good, feels good. But when it comes down to the deadline, you’ll hit some bumps and settle for 30Hz. Lucky is the project that can ship with 60Hz, and the only guys I’ve ever seen go out with 120Hz are doing VR, where you have to have it to avoid nausea.

What about variable framerate? It’s bad. Don’t go there. Humans are very good at compensating for fixed delays, and very good at detecting variable delays. It’s much better to cap to a fixed low framerate, because users will automatically compensate and cease to notice it. (This is how our nervous system works; your arms have a fixed delay for nerve signals to propagate, muscles to react, etc. So the capability is built into the brain at a very low level.) However, if it varies, the user will notice every little change in performance and be frustrated.

Back to the performance measurement issue, frame rates are not linearly comparable. What you want is milliseconds per frame (mspf). How come? Because Hz is not linear. It is harder to get from 90Hz from 60Hz than it is to get from 30Hz to 60Hz. How come? Looks like the same diff, right? Let’s put the same problem in mspf. Going from 30Hz to 60Hz means going from 32mspf to 16mspf. But going from 60Hz to 90Hz means going from 16mspf to 11mspf. In the first case I am cutting 16ms off my frame time, which is a big chunk, but I still end up with a relatively generous 16mspf. In the second case, I have to squeeze 5 mspf from an already meager frame budget.

Using mspf also makes it easy to discuss performance gains. If I have a task that takes 4mspf (say applying a full screen blur), and I can optimize it down to 3mspf, I know exactly how much of a win I’ll get no matter how the rest of the application is performing. Compare that to saying that the blur runs at 250Hz then I have optimized it to 333Hz. And when I am budgeting performance I can easily divvy up my available frametime to specific tasks. We might have 8mspf for physics, 4mspf for render calls, and 4mspf for the GPU to finish.

Bottom line: use milliseconds per frame not hertz for performance measurement and budgeting.

GPU Readbacks

(This advice and the advice in the following sections is general; it applies to OGL/D3D and console HW APIs, and I doubt Molehill can deviate from the fundamental hardware reality. Of course, Molehill’s software renderer probably has different performance characteristics – slower, but more permissive.)

Never ever read back from a GPU resource. Ever. Don’t. Stop it. Ok – you can maybe do this ONCE per frame, if you are careful and build your renderer around it.

Why is readback so incredibly bad? Because it forces synchronization (as do a few other things in the graphics API). Then, while the GPU is stopped, you do a slow memory read back to the CPU, which is also stopped and waiting for the data.

Normally, the GPU will run ahead of the CPU – you fire off some draw commands and it goes and does its magic. But imagine you issue these commands:

1. Clear framebuffer.
2. Draw triangles.
3. Read back from framebuffer.

Normally, you’d never see the cost of #2 on the CPU – it would immediately return and you’d go on your way. Say it takes 1ms to do that draw. The call returns in a few microseconds and you keep doing. But when you issue command 3, the CPU has to wait for the GPU to finish command 2. Then, because framebuffers are often stored in proprietary formats either for performance or quality reasons, the GPU has to prepare it for readback. Then it can finally stream the requested data back to the CPU, and subsequently continue on with its rendering. All this cost shows up as you waiting a long time on #3.

Readbacks are tempting to the Flash developer because copying stuff out of the Flash vector renderer is basically free. But on hardware, it gets you a triple whammy – you stop the world, you make the GPU do a bunch of extra work to prepare data for readback, and you have a data copy operation. Don’t do it.

Let the GPU Run Free

Ideally, you want to issue the minimum number of calls to the 3d API that will let the GPU do maximum useful work without interruption. GPUs are like bullet trains. They go really, really fast as long as they don’t have to stop or make right turns. Sometimes it is even better to do somewhat wasteful things because the gain from continuous operation is so big. GPUs are on track to have thousands of parallel processing cores. Just let ‘em run and you’ll be amazed at what they can do!

Compare this to the Flash vector renderer which is best when it is given minimal work to do. It’s a great renderer but it doesn’t have the benefit of powerful dedicated hardware that has been tuned for decades to run it fast.

If you have a big batch of geometry, it’s often best to simply draw it. You will want to figure out what the threshold is at which culling is beneficial, but it can often be on the order of tens of thousands of triangles.

Vertex shading is practically free when you’re looking at rendering 1080p at 60Hz. You’re going to be hitting 124M pixels every frame at MINIMUM – if you have any overdraw it can easily hit 300M or higher. If you have a million triangles in your scene, you’re only going to be doing 60M triangles in that same time frame. So take advantage of it when you can.

Don’t let the GPU run too far ahead, though – it introduces control latency. GPU drivers can often buffer several frames ahead, and if you aren’t careful you can add 50-100ms of latency between a user hitting a button and something happening. Introducing a small readback at end of frame can help force synchronization. (Molehill might deal with this for you, too.)

Performance Trade-offs & Maintaining Your Image

On the GPU, you have huge opportunities to trade space for time for quality. Lookup textures can replace costly math functions (or make them tweakable by artists). You can sacrifice precision (either using half precision or just being a little bit wrong) for performance, too, to get big wins. The great thing about graphics programming is that it only needs to LOOK right, not BE right. So pile on the hacks – if it fits your game’s look, it’s a good solution.

That’s enough on performance. I could write a whole book on optimizing 3d game performance. In fact, I have; it’s called Video Game Optimization. It covers the whole problem from scheduling for performance to measuring to identifying bottlenecks to fixing them. It even has a chapter on Flash optimization!

Stand on the Shoulders of Giants

Graphics are sexy and well studied. The fount of graphics research is SIGGRAPH (any further back than that and you’re tracking individual researchers). Literally every rendering problem you will encounter when working with Molehill has a solution that was published at Siggraph thirty years ago, played with at SGI twenty years ago, considered at 3DFX 15 years ago, and brought into the mainstream and shipped on a console or PC game 5-10 years ago. Around then it was also republished as a practical implementation in a Gems book, and also shipped as a card demo by ATI, nVidia, or Intel. If it’s really good, Carmack or Abrash prototyped it when they were working on Quake 1, Epic has it in Unreal, Crytek has some great demo videos of it, or Valve has published slides on it.

Am I claiming that there’s no fundamental research left in 3d graphics, or no expressivity? Of course not. But you owe it to yourself to be familiar with existing work in the field before you go reinventing the wheel, and the field is aggressively researched. So I would not expect to stumble on any huge break through right away, just like if you pick up oil painting you’re probably not going to reinvent the field…

I think the interesting part of graphics is finding the best fit for your specific problem and enabling artists. It’s a craft. Look at what Pixar does. Their research has always been in support of their story and their specific technology needs. Out of that they have ended up contributing a lot of great stuff, and innovating in a lot of ways, but they did it with a strong understanding of existing technology.

I encourage you to do the same. It is what I have done in my own projects and it has worked out well. When I have pursued tech for tech’s sake the results have always been less effective – good for a demo but ultimately ineffective in enabling my team to succeed.

It’s the Assets, Dummy

How do you make a good-looking game? Really, it’s not the technology. Shaders, complex rendering techniques, and so forth are all fine and they can enable good results. But great art is what carries a project.

Look at that video at the top of the article (it’s OK; I’ll wait). There are very few complex rendering techniques at work. Mostly, it is great art (and a great lightmapper) with just a few simple shaders and effects.

Look at Mass Effect. They use shaders, sure, but the real source of the game’s look is the tireless work of many talented artists.

Or look at one of our older projects, Grunts: Skirmish:

All the runtime is doing is compositing unrotated, unscaled bitmaps. But the great work of our artist, Tim Aste, makes it a memorable and interesting visual.

To that end it’s vital that you make it easy for artists to work with your technology. There are two lessons I have learned in this are:

1. Make it easy to see. Have an automatically updated live build somewhere and let the artists have the URL. That way they can check art in and see how it looks in the game, or tweak things as needed, without involving a programmer.
2. Make it easy to process art. Make sure that the inputs to your art pipeline are high-quality uncompressed files. Then process them into whatever format and quality level you require. Optimize the final format for very fast download and unpacking.
3. Your art needs and formats will change. Be able, at any time, to reprocess all of your source assets into their final form. Get everyone used to the system early on and you will have the agility you need late in the project to succeed. There’s nothing worse than asking your artists to hand-process dozens or hundreds of assets due to some technical change! (It’s not just unpleasant, it also introduces mistakes, since they are people, not machines.)

Art pipelines and processing is a subject worth of a whole bookshelf. Go out and learn as you need it. Not every project needs an all-encompassing solution, but… well, read the next section.

Trends & Closing Thoughts

3D changes the landscape of application development. Flash has tracked the console space’s evolution, on a much shorter timeframe. Looking at how consoles were affected by the introduction of 3D is very instructive:

• Art becomes more complex. Creating an animated character in the SNES days was the work of a single person for a few days. Creating a character for Mass Effect is months of work for a team.
• Asset size increases. A full SNES game is 16MB or so. 40 hours of gameplay, tons of content, music, visuals, cutscenes, etc. A typical XBox 360 title is 6gb, often compressed, and now 2 disc games are coming out. An asset footprint of 15gb is not unrealistic. It will be interesting to see how this plays out in the online space.
• Budgets and complexity swell. I bet you could make a complete, high quality clone of A Link to the Past for two month’s operating budget of Mass Effect or Halo. Teams will get bigger, projects will become more complex, and technical requirements will increase.
• Gameplay remains relevant. The hit titles in the console space are those with high technical quality – but they are also fun. Mass Effect is highly immersive. Halo has highly polished gameplay. God of War is a remarkable experience in an industry full of remarkable experiences. And indie titles that are genuinely fun and engaging – like Minecraft – are able to succeed without large marketing or art budgets.

Right now, Flash is at the same place the PC space was in 1998-1999. We can do compelling 2D or limited 3D content and teams are getting larger but not yet huge. Molehill will bump us forward to around 2001-2002, perhaps a bit further. It’s an exciting time to be a Flash developer.

The kinds of experiences we will be able to build are going to undergo a quantum leap, as will the demands on us as developers. We are in a unique position to leverage the lessons of the past to build the games of the future. What do you think the major issues will be? How can we build great content on this new feature set?