Realtime games are a different breed of software than data-driven websites. A harsh constraint for game developers is that, in order to get 60 frames per second, your game loop needs to execute in less than 16.66ms. If you know your target CPU and your execution time budget, you can work within this constraint. But when you’re writing a game for the browser, you have one more thing to worry about: the Javascript VM needs to pause periodically to collect garbage and manage the memory heap.

The good news is that modern browsers have vastly improved the efficiency and common-case runtime of their garbage collection phases. But are they good enough to make games with smooth animation today? How much garbage can your game safely create? Once your game loop fits into the CPU-time budget, can you know that it will be scheduled fast enough? Are you going to meet some target frame rate for the 99th percentile rendering time? The answers depend strongly on the client (hardware and browser), but we can make some measurements on typical computers and make some useful generalizations.

Methodology

Let’s assume a typical game will have an animation loop which is gated by window.requestAnimationFrame(), with the hope that the browser will schedule the loop at a stable 60fps. Also, assume that there is a single function which computes the next game state and “draws” it (to the DOM and Canvas). If we monitor the inter-arrival times of these requestAnimationFrame() calls while watching the JS heap size we can see if garbage collection pauses are responsible for dropped frames.

The following example runs in Chrome, which supplies window.performance.now() and window.performance.memory.usedJSHeapSize (when invoked with --enable-memory-info). Similar affordances exist in Firefox and Safari.

function() {
  var lastHeapSize = null;
  var lastFrameTime = null;

  var runGame = function() {
    requestAnimationFrame(runGame);

    var frameTime = window.performance.now();
    var heapSize = window.performance.memory.usedJSHeapSize;

    if (lastHeapSize == null) { lastHeapSize = heapSize; }
    if (lastFrameTime == null) { lastFrameTime = frameTime; }

    var dt = frameTime - lastFrameTime;
    var dh = heapSize - lastHeapSize

    frameDataList.push([dt, dh]);

    lastHeapSize = heapSize;
    lastFrameTime = frameTime;

    computeNextGameStateAndPaint();
  };
}();

We can also make some adjustments to the implementation of computeNextGameStateAndPaint() to see the effect of different amounts of garbage generation.

var makeSimulatedGameLoop = function(n) {

  /* Pre-initialize an array with distinct simple objects */
  var g = new Array(1000*n);
  var count = 0;
  for (i=0; i< g.length; i++) {
    g[i] = {count: count++};
  }

  var _work = function() {
    var i;
    for (i=0; i < g.length; i++) {
      /* For every game variable, double it's count property. */
      /* Implicitly create a new object, garbaging the old one. */
      g[i] = { count: g[i].count * 2 };
    };
  };

  return _work;
};

computeNextGameStateAndPaint = makeSimulatedGameLoop(20);  //  Try 2, 20, 200

After this runs for a while, frameDataList will contain a list of samples which are easy to analyze:

> window.frameDataList
[16.672734, 133128],
[16.183574, 128228],
[39.847293, -12158528],
[16.974714, 119222],
[16.672734, 140248]

Correlation between slow frames and GC events

Garbage collection events aren’t explicitly announced by the VM, but we can infer that one has just happened whenever the JS heap size decreases between two samples. We might undercount the number of garbage collection events by sampling too slowly, but we can’t overcount it this way.

Here are some plots showing the inter-arrival times of a series of animation frames, along with some decoration indicating changes to the size of the JS Heap. The bubble radius is proportional to the magnitude of the heap size change in the last frame, and color indicates the sign. This data was collected using Chrome 22 running on a high end laptop.

Here’s an example of an absurdly high amount of garbage generation with 200,000 anonymous objects becoming unreachable every frame. While this is an artificial and unrealistic memory-use profile, it still produces thought-provoking results. Notice how bi-modal the frame times are when there’s a lot of garbage being generated inside computeNextGameStateAndPaint(). It’s clear that the slow frames which do occur almost always occur in conjunction with a garbage collection pass.

As we dial down the rate of garbage generation, the situation improves materially. GC pauses start to fit inside the gaps between frames, and predictable 30fps is within reach.

At 2,000 objects/tick, 60fps is looking rock-solid.

Conclusion

Too much garbage will certainly cause stalls that impact frame rate, but the critical amount of garbage is discoverable early in the development cycle of your application. It is possible to get stable fast frame rates provided you stay inside your per-frame CPU budget and keep the rate of garbage generation under control.

Further Reading

1. Accuracy of Javascript Time
2. How to write low garbage real time JavaScript
3. Context around the window.performance.now() interface

[By Roger Paffrath]

A while ago I stumbled upon a talk submission form for an event called The Developers' Conference. It's a gathering of people who want to learn a little bit more about topics like architecture, digital marketing, Arduino and others. Sure enough, games were going to be discussed there too.

The event was close to at least four universities that have game courses, so I thought many young faces would show up. Right after I saw the submission form, I started thinking what I could tell those people that want to be a part of the game developing scene here in Brazil. It didn't take long before I realized I wanted to share with them the things I messed up on the past two years and maybe help them be more aware of some of the tricks you can fall for when you are too eager or too optimistic to do something.

When my talk got accepted I wanted to validate my arguments with other people's own experience. That was something I didn't have time to do and this post is an attempt to fix that. What this post is not, however, is a receipt to follow blindly. Feel free to disagree with me and bring your ideas to the table.

Here's what I've come up with:

1. Do not fall for survivorship bias.

For those who may not know, survivorship bias is the tendency to consider only successful cases when analyzing market data, behavior, etc. It even influences warfare.

How does that apply to game development then? Well, when I started, I remember being really optimistic and enthusiastic about building an iPhone game. I was reading article after article of developers that were making good money out of the App Store and I thought maybe I could get some bucks myself. I didn't stop to think things through and it did not go well.

"Resistance outwits the amateur with the oldest trick in the book: it uses his own enthusiasm against him." - Steven Pressfield, The War of Art

Take your time. Think of the obstacles ahead. Talk to people and ask for advice. Analyze every option. Then take some more time. Only after that make a choice and never look back.

To know more about survivorship bias I strongly recommend reading this.

2. Do not start with a complex idea.

I see a lot of guys that want to start out doing things like an FPS. They seriously want to start doing that. They have only the basic skills, but that's what they want to do.

When these guys sit down to actually do the job, they are easily defeated. That's because they don't realize the amount of energy you need to put into a project and they have even less idea of their own professional capabilities.

I am not saying your first game cannot be an FPS, but you have to consider all the things ahead. If you choose an FPS, it will take really long before it is finished and it will be on the market alongside Call of Duty. Isn't it better to start with a smaller project to get under the radar of the press and fellow developers earlier?

For me, the smaller the better. But, no matter the size of the project, I like to read this piece by Tommy Refenes every once in a while. You have to divide your project in parts, tackle those parts individually and every now and them step back and enjoy the progress you made.

3. Do not make a simple idea complex.

Do not overcomplicate things. This happened with Little Red Running Hood. If you start thinking about adding stuff, stop and evaluate if those things are really going to improve player experience and if they sit well with the core mechanics.

I found that the two next items on the list are important agents on avoiding adding useless stuff to a game you've been working on for months. You can also read more about this here.

4. Do not skip the prototype phase of development.

So, how do you keep from adding useless things to your game? You do this kind of thing on a prototype. That's why it is important not to skip prototyping, specially when you're really eager to start making something. It's an opportunity to let your big creative brain run on overdrive.

By making a prototype, you can find out if the mechanics created really work by their own. You can also get folks to play your idea and get decent feedback to improve it. Yes, you will probably need to improve it.

Discover if your game, in its simplest form, is fun before investing months of your time developing it.

5. Do not forget to make a GDD or write your ideas down somehow.

Ideas have this weird behavior. Sometimes they run away and are lost forever. Other times they mutate... it can be to something better - which is cool -, but they can also transform into something nastier than their original version. Writing them down is a way to avoid such messy scenario.

When working with teams there is also this strange thing that happens sometimes. You can try to explain your idea to me and I can choose what to listen or twist it somehow. Or maybe your explanation isn't clear enough. When the time comes to actually implement it, it won't turn out as you expected. Hopefully, a well documented idea can solve this situation.

A GDD also makes things easier when there is need to bring someone new to the team, specially if the person is working remotely. It gives a full perspective on the game.

6. Do not underestimate the power of good planning.

Deadlines are awesome. Most of the things done on this planet have only been accomplished because of them. Without them, we feel too comfortable and a comfortable creative mind starts wandering. Before you realize, you're taking double the time to complete simple tasks.

Other positive aspect of good project planning is that you are able to focus on one thing at a time. You don't have to worry about those awful bugs, because you will have the proper time to deal with them later.

Some people might think that's only for larger teams or projects. That's OK. In the end, if you sit down every day and do the work you need to do, it all falls into place. Me? I like a good old fashioned deadline.

7. Do not leave marketing to the last months of development.

Legend has it that when Brazilian cartoonist Maurício de Sousa started drawing, his father told him that there was no problem with that, as long as he learned how to sell his creation too. Thankfully, he listened.

Here is something I see most of indie game developers around me doing: they focus exclusively on the technical aspect of making a game, without even thinking about how to get it in front of larger audiences. Not even to play test the things they make. They worry about it much later, when the project is near the finish line. Alexander Bruce has some great insights on how that can lead to obscurity.

Hopefully, as the industry matures, beginner indie developers will become more aware of that and will start getting word out earlier and saving bigger budgets for marketing.

8. Do not play test only by the end of the project and/or only with friends.

Like stated before: it is best to have large groups of people playing your game as soon as possible. You followed the advice provided here and built a prototype? Show them to strangers on the street. Go to events with the latest build of the game and get as much feedback as possible. After that, make some adjustments and go to the next festival.

9. Do not start on the mobile market.

This one is the one I get most of people disagreeing with me. It's the first item on this list making young developers see everything optimistically. The real truth is: the good things on mobile are far less numerous than the bad things going on on the platform.

Seriously, if you are starting, with no fans, no press awareness and no big money to invest on marketing, forget the mobile market. This is something I learned the hard way. I saw months of hard work fall into the limbo of the App Store. Obscurity is a bitch.

Even if you forget the discoverability of games on the mobile market being all messed up, I really don't think you should start there. There are easier and faster ways to make and distribute games. Part of the reason we didn't play tested Little Red Running Hood accordingly was the fact that it was hard for us to send the app to people outside of our friend circles.

I realize there are two sides for that discussion and that there are down sides to any market, but I will remain encouraging people to start reading more about the problems of mobile and all the stories of other developers who fell for the mermaid's song.

10. Do not forget the budget for attending events and festivals.

Hands down, this is the best way to show your game to other people and starting networking with other developers and press. These are creative minds that gather on the same place at the same time because they love games. That's inspirational. At least I heard. I was stupid enough to consider only submitting my game to these festivals, but never thought of showing up in person. When I realized the benefits of attending these events, I had no money to do so.

11. Do not ignore the fact that you are part of an industry.

Starting out on any industry is hard. It is even harder if you are blind to all the topics and people that are relevant in the business. Luckily, this is the easiest tip on the list to follow. Just check this list Rami Ismail wrote with some interesting twitter accounts on the gaming world (don't forget to follow @tha_rami himself). Don't have a twitter account? Fix that now, it's free!

12. Do not wait for a diploma to start making things.

You are not studying to be a doctor, lawyer or engineer. Maybe if you were you would have realized something most of my colleagues at university don't.

You want to work in a certain field? Start thinking of your career early.

Stop throwing that unfinished project away at the end of the semester. Stop doing things for grades. Stop doing things for love, too. Do it for your career. Love your career itself. Become a professional and finish things!

13. Do not hide those things.

I know for a fact that there are a lot of people around me doing things related to game development. However, I know very few of those people and even less of their games. Why is that?

If you are working on a game and you hide it from people, you are being selfish. You are keeping them from having fun. You are also overconfident. Before spending more time working on the awesome idea you had, how about you let us play it and them we can give you feedback?

I am currently trying to organize meetings with developers to get something going. If you are a local indie working on a game, please get in touch. It isn't hard to find me. If you made it this far on the post you are truly persistent, therefore I would like, not only to play your games, but also to personally high five you.

Bonus for Brazilian developers:

This consist of only one tip, but it can make all the difference for people with tight budgets. Maybe it applies to other countries too, but for now I only know how this works in Brazil.

14. Do not open a company.

You are just starting out. You don't need to pay taxes, you don't need to have an accountant and you don't need fancy paperwork (and believe me, there is a lot of paperwork).

Focus on building something first. Make some games, get some word out and try to find your voice. Partner up with different people and get informed about their experiences. There are many other ways to start out other than opening a company right away.

Actually, those who encouraged me to start a business were the ones who were interested on doing the accounting for us. Coincidence? I think not.

The damage wasn't that much, but the money we put into the company could've been used to show our game on events. International ones.

Now, I only see a point on going through all the paperwork to register a business here if you are aiming to get a deal with an investor, join government programs or sign a contract with Sony or Microsoft. You have to really trust your gut to go for those things as a beginner. But, if you decide to do it nonetheless, let me know how it turns out.

Anyway,

Even if you don't take any of my advice, you are probably here because you are interested on game development. So, I wish you keep making great games. Maybe someday I'll get to play them.

Follow me on Twitter.

This text was originally posted on my personal blog.

I’ll start this week’s post off with an honest-John moment about money: I’ve always been a money-tracking nerd (I cried when Microsoft discontinued MS Money – especially since I thought I’d “won” by picking Money over Quicken and watching Quicken bite it a few years beforehand), so my cavalier attitude expressed in the graphic below isn’t really true. But it’s there for dramatic effect because something…well…dramatic really happens to the way you think about money when it’s your own business, and it feels to me like night and day enough to say that in comparison – I didn’t really give much of a hoot about personal burn rate before I opened the business.

Let’s show you the difference:

It’s impossible not to care when you’re talking about ALL THE MONEY YOU HAVE LEFT.

Now remember – I’m a new indie, a newbiepreneur, and I’ve been slathered in corporate BBQ sauce for over a decade. This has some detrimental effects.

Welcome to the Corporate World

In the Corporate World, salary was the law of the land. You got paid, on time, like clockwork, the checks cashed and you could save if you wanted to or not, you knew the sun would always come out twice a month and wash away the rain.

Naturally, spending habits flexed to fit, as Parkinson’s Law tells us. Once you had money coming in, the money going out would expand or contract as necessary and you’d breakeven and sometimes you’d engage the credit card on big stuff you couldn’t quite afford – there wasn’t a lot of discipline to it.

But I did one thing right.

I tracked my spending. I knew my averages, month after month.

Goodbye, Paycheck

Before I decided to leave Microsoft, I took that data and put together a worksheet that showed how much personal spend I had every month. And, it’s not zero. You can do a lot to reduce spending (and we did) but the cost of living is the cost of living.

With that, I understood what my “CEO Salary” looked like – and from there, adding in the basic business expenses of keeping the lights on at 4gency, I knew something critical: how long I had as an Indie CEO.

Why Burn Rate Matters

When you’re out of cash, your business is over. You can’t pay your people, you can’t keep the lights on, it all goes kaboom – and if you’re Donald Fagen apparently you throw a big party and get it on with Miss Fugazy in the service elevator.

Whip me up another one of those famous paper shredder margaritas.

It’s a well-known business metric – perhaps the most well-known one; hell, practically every other entrepreneur, mentor, investor or consultant, after asking me what I do for a living, follows right up with “what’s your burn rate?”

And right now – it’s my own personal salary to hit our monthly spending needs plus the monthly bills to keep the lights and internet going at the office.

Once you know the magic number, and you know how much you’ve got in the bank, your life isn’t about going from week to week, watching the line bob up and down like a lazy boat on weak waves.

It’s more visceral. More immediate. Like a roller coaster. One that’s mostly going down.

It’s Not Bad, Just Real

I think it’s a good first emotional reaction when we see a giant cliff to be concerned about going over the edge at high speed. It’s how we’ve survived this long as a species.

But there’s another effect that grows stronger the longer you face the reality of life-as-burn-rate rather than life-as-waiting-for-bonus-day: you get focused.

You see costs as belonging to two categories: investments and costs of doing business. You prioritize the former category and reduce the latter.

And, you look at costs as tradeoffs. Increasing investments steepens the burn and shortens your time to live, but without the investments you’re going to crater eventually anyway, so you have to pick the right ones, and you need to give them time to pay off. Can the burn rate post-investment give you enough runway to survive until the investment is paying back at breakeven? That’s the math you have to do.

Rules for Living in a Burn-Rate World

It’s true – I’ve got rules for this kind of thing. And if you’re thinking about taking the plunge or have already done so, I’d love to hear your thoughts on these.

1. Stay pessimistic about your spending. You may not always spend the same amount every month, so take the average and add 20%. Only one side of the breakeven line is generally considered a “nice surprise”.
2. Reduce costs but maintain agility. Ditch the second car. Ditch the cable TV subscription. Don’t ditch your smartphone – staying engaged and agile is the only advantage you have as a startup.
3. Deals are going to take 3 to 6 months. If you think investors will come to save you with just a month left of burn, forget it. You need runway to make your investments pay off – even your products. Hell, even the iOS App Store pays a month behind.
4. Once you have your numbers, let it go for a while. Even though plans will change, you have a forecast. Don’t panic. Go build your product, and come back to enter new data in a few weeks. Watching the money drain out won’t help you build better products.

It’s still a lot to take in, but I’m working my way through it. I’d be interested to hear any tips you have about making the transition to burn-rate thinking.