Key Properties of a (Game) Prototype

Prototypes can be analog or digital, made out of paper, assembler, clay or python. They can take any shape or form, but still share some key properties. The reason for a prototype is always that you want to test a specific feature, technique or design decision as cheap as possible. In order to make the prototype cheap, it needs to be easy to create and fast to get started. Use whatever is at hand or, even better, create a prototyping environment. The environment can mean a box of crayons and some sheets of paper or setting up Processing. The ultimate fate of every prototype should be the trash can. Once you’ve created it, tested it, and noted the results of the test, you best throw away the prototype. Of course you might keep it around in case you want to iterate it, but that should be the exception rather than the rule. It is especially dangerous to create a prototype that could potentially be used in the final product. Most production environments are too complex to allow for agile prototyping. As soon as you run into a technical problem, you are most likely working in the wrong environment (or really clumsy with scissors). Also, a prototype should never be optimized. Since prototypes might be used for all kinds of experimenting, different tools are appropriate for different prototypes. Always remember that a prototype should test one specific aspect of your design. Don’t make it holistic. Don’t let any feature creep hamper your agility.

In summary, a prototype has the following key properties:

• Easy to create, fast to get started
• Cheap to work with, so that you can throw away the results
• Should not produce something you can use in finished product
• Should not allow optimization
• Be made with the right tool for this specific design challenge
• Allows to judge one specific aspect of design

Why Should I Build a Prototype?

The problem with prototypes is that they sound like extra work. Most people have trouble throwing away anything that required an investment from their side. To overcome this, a prototype needs to be as cheap as possible. Throwing away something cheap is easier than trashing something expensive. If the prototype requires too much work to be worth the effort or to be thrown away, you are most likely building it with the wrong tools.

The key benefit of building a prototype is that it enforces design decisions. Once you put a design to paper in the form of a testable prototype you have to settle for the behavior of the system. Also, if the team plays the prototype together they are confronted with those design decisions. The prototype fosters team communication. If the prototype is played by people other than the designers, those inevitably find loops in the rule set. The prototype then acts as a coverage check for your rule set.

Different Prototypes for Different Experiments

Different prototypes for different aspects of a game sounds great in theory. But what exactly can you test with a prototype? The easiest part is game design. Most game rules can be formalized and written down on paper. It’s a bit difficult for action-intensive games, but still doable. I’ve even read about first person shooters that were prototyped on paper. Basic game systems like resource systems, character progression and enemy balancing can be easily abstracted. More obscure game systems like loot frequency and item properties can be tested by building specific prototypes, e.g. card games, that focus on those sub-systems alone. If you build a paper prototype for a highly interactive part of the game, don’t shy away from Wizard-of-Oz’ing. Remember, AD&D is all smoke and mirrors.

Things might get more complicated if you want to prototype more technical elements of a game. Game controls are a classic example of where a prototype is helpful, especially if you’re trying something new. Novel interfaces, the Wii Remote or the iPhone’s touch screen, can be tested for specific interaction forms before integrating those controls into the game proper. A.I. is another area where it makes sense to prototype a new algorithm before rewriting the engine. If you have e.g. a plant growing algorithm in your game you can develop a Lindenmayer-System in a dedicated piece of software before carrying over the rules that work for your game. Arranging audio before putting it into the game is so common I wouldn’t even call it prototyping, but what if you build an interactive dedicated audio-prototype?

Making Game Design Prototypes

Stone Librande gave a wonderful talk about paper prototyping at GDC09. Apart from numerous examples of paper prototypes he has built, one of his slides listed the do’s and don’ts of game prototyping. Here’s the gist of it:

What To Do

• Focus on one key idea at a time
• Abstract as much as possible

What Not To Do

• Don’t worry if the paper version is not “fun”
• Don’t try to duplicate the whole game
• Don’t simulate computer functions (physics, math, …)

Make Rules, Not Boards

Apart from prototyping my own games, I’ve taught this technique in game design and interaction design courses over the last six years. My students usually fall into expected traps when building their first gameplay prototypes. What goes wrong? They start with a board.

If you’re not experienced with prototyping, a game board is a bad starting point. A card game game is easier to create because it requires less assets and is faster to balance and iterate. Also, boards restrict character movement and thus have the tendency to make games slower and rounds longer. Think of popular card games and board games and compare the average match duration. It is far easier to build card games where the system escalates from a stable into an extreme state (I am resisting the urge to make a pun about the board leveling the playing field). That means it makes the game shorter, allowing for more iteration in the same time frame. It also makes for a better test setup for your rules because they are tested more intensively for their dynamics.

Another thing I learned through having students fail at assignments: Avoid using dices in your first prototypes. Balanced random makes it too easy to create a good game dynamic. Try to make a game without random first, and introduce dices when you need them.

Design as a Process

It is an engineer’s dream to structure the design process of a product into discreet steps leading from idea to finished product. Many disciplines of engineering, be it software engineering, bridge building, or product engineering, shared this dream. Take a problem and solve it by dividing it into sub-problems that can be tackled in succession. The steps are: generate an idea, make a plan, follow the plan, ship. At worst, the product is mistaken as the process, with “the plan being organized so as to make the structure of the design process reflect the structure of the sub-components of the resulting design product.”[2], which is then called the product-process symmetry.

Yes, the waterfall model is a famous result of this thinking. But there’s a reason why most game studios utilize agile methods instead of the waterfall model. Games do not lend themselves to this style of strict planning. This is especially true if they are innovative, but even games with a marginal degree of innovation might have development challenges that are difficult to take into account in advance. The same is true for product engineering. I’m not very familiar with bridge building, so I won’t talk about that. In design, iteration became the new paradigm, and with it came a plethora of new design and development methods – from rapid prototyping and pair programming to interaction sketching.

Wicked Problems

The core of games is interactivity. Games are rules systems that only flourish upon interaction. The dynamics and aesthetics of play is what we design them for. In design thinking, the notion of “wicked problems” was introduced to describe those mostly user-centric problems that are so hard to solve in a step-wise problem-solving manner. Rittel and Webber described wicked problems in 1973 as problems where the following list of conditions is met:

1. There is no definitive formulation of a wicked problem.
2. Wicked problems have no stopping rule.
3. Solutions to wicked problems are not true-or-false but good-or-bad.
4. There is no immediate and no ultimate test of a solution to a wicked problem.
5. Every implemented solution to a wicked problem has consequences.
6. Wicked problems do not have a well-described set of potential solutions.
7. Every wicked problem is essentially unique.
8. Every wicked problem can be considered a symptom of another problem.
9. The causes of a wicked problem can be explained in numerous ways.
10. The planner (designer) has no right to be wrong.[3]

Think of a game mechanic and you can see how nicely it fits this description. I’ll give an example. We’re currently testing out different single-player mechanics in Chasing Aurora. One of the design challenges we’re facing is developing physics-based 2D flight for a bird-man. Since flight is your main means of traversing a level and the challenges are platformer-ish, the player has to have a lot of control over movement. On the other hand a lot of the challenges are built on wind-streams that affect your movement. We’re iterating the flight movement component again and again and again and again to strike the perfect balance between control and being at the mercy of the elements. Now let’s look at the above list. (1) The description of the problem is informal and incomplete. (2) We will not know it when we built the perfect control scheme just bounce against the fluffy invisible wall of diminishing returns because there is no absolutely (3) right solution to this problems. (4) There isn’t even a formal test we could apply to test if our solution is perfect. All we got is unreliably human game testers. (5) If we implement a different solution it affects the whole gameplay. (6) There is no point in describing all possible control schemes for character movement, we just need to make it (7) deep, feeling fresh and perfectly fitting to the game as a whole. (8) Reminder: The whole game can be regarded as a wicked problem. Point (9) is impossible to tackle without venturing into philosophy. I leave that as an exercise for the reader. And finally, (10) the game will simply not fulfill the player if we fail.[4]

The reasons why wicked problems are so prevalent in the game development process are many, but the most obvious are:

• Game development is bound by countless constraints: Genre, technology, player expectation and physiological limits, to name a few. Constraints call for creative solutions.
• Interactivity is at the core of games: Nearly every aspect of a game manifests as a dynamic system bound to user interaction. Interactive components always need to be tested with players.
• All systems and parts of systems are connected: Health and health packs, health packs and lifting strength, lifting strength and inventory display, inventory display and button mapping, button mapping and device drivers, device drivers and graphics cards, graphics cards and shader versions, shader versions and post-processing FX, post-processing FX and particle systems, particle systems and healing magic, healing magic and health. Solutions to one problem affect a host of other problems and their solutions.
• Innovation needs experimental setups: Every innovation is a risk. Despite the ongoing cloning and the prevalence of straight genre works, there’s a huge amount of innovation in the field.

The standard game design and development problem solving toolkit consists of tools to overcome wicked problems: Scrum, prototyping, MDA, game testing from pre-alpha/internal to beta, interaction sketching, even patching and the rampant board game obsession. Tackling wicked problems is key in game design. And we’re doing it every day.

We’ve Already Solved These Problems, Let’s Tell The Others

Game development never fell into the product-process symmetry trap in the first place. We’ve solved a lot of design problems in this industry that other similarly structured areas are still having problems with. And if you look at the current trend of gamification and how horribly designed most of the applications of gamification are, it is clear that the challenge is not only bringing game mechanics to other areas but revising company structures in other industries so that they are able to tackle problems as game design tasks. Hand over the keys instead of opening the doors. To truly gamify a service, processes in the company that run the service have to be adapted. New processes, tools and methods have to be introduced. Just adding a points-based rank system does not do the trick. While restructuring the company, the whole process of user interaction has to be restructured, too. I am no friend of gamification, but if you do it, you better do it whole-heartedly. If you add achievements to a web service, make them as supporting to your design goals as possible (after all, achievements play an important support role in modern gaming), as a prize for risking something, as a tool to foster changing the style of play, rewarding exploration and experimentation, as a means of comparing your progress to other player’s progress. Awarding points for arbitrary interaction is not gamification and reduces the whole concept to a marketing trend. Structuring interaction dynamics via game mechanics can make products better.

If gamification was about introducing game/design thinking to new areas, it would not feel so much like a marketing stunt. I firmly believe that a lot of products – and their design processes – could profit from the agile design methods we use in game development*. And a lot of interactivity can be rendered more satisfying when it is game-designed.

[1] Lawson, B. (1980): How Designers Think. Third and revised Edition, Architectural Press, Oxford, 1997.
[2] Gedenryd, H. (1998): How designers work. Ph.D. dissertation, Cognitive Studies Department, Lund University, Sweden.
[3] Rittel, H. & Webber, M. (1973): Dilemmas in a General Theory of Planning. Policy Sciences, Vol. 4, Elsevier Scientific Publishing Company, Amsterdam.

* If you look at the most successful recent product launches, like the iPhone, and think about how many iterations they went through before being released you can see design thinking in action. Also, I think what sets Apple apart from other companies mostly the fact that they do not release every iteration of a product to the market. It’s not like they make better hardware than Samsung. Samsung just releases crap mobiles additionally to their great and well thought-out products.

** … and it will not sell, and not have a decent metascore, either.

In our current game, Chasing Aurora, project we’ve prototyped different gameplay elements, game modes, ways of control your character, graphic styles, level designs, game rules, enemies and timing rules. We will soon also prototype different social interaction methods, asynchronous multiplayer, settings and more enemies. Both of these lists are far from complete. When setting up the design principles for the single player mode we isolated four layers of challenge that we are basing our game design upon:

• The story layer: Levels can be generated by thinking about the (background) story of the game.
• The metaphoric layer: The story conveys a meaning via metaphors. This is the meta-story.
• The skill layer: The player will learn how to play the game. His skill might be contested in order to help him develop the physical abilities it takes to complete the game.
• The setting layer: Our game plays in the Alps. The game world is always an interesting starting point for challenges.

Of course all of these layers are intertwined and connected and each level has to challenge the skill, progress the story, work in the setting, and have a metaphorically interesting proposition, even if it is a simple one. The settings and skill layers lend themselves the most to prototyping. You can model an challenging level in an hour and have it tested out by players. You can model a feature of the setting, e.g. waterfalls or rock slides, in a few hours. Developing a block of story is also fairly simple once the background story is in place. Yet testing it out proves to be a bit more complicated because parts of stories live from the associations and connections to the whole. The metaphoric level is even harder to test because it is closest to the player. Different cultural contexts might make a situation getting read completely different by the player. Ethics is not universal, and neither is body language.

Story, metaphor, skill and setting might form the starting points for our level design, yet the overall game design needs to incorporate even more layers. Every layer has his own depth and the ability to pull the player deeper into the game world. It is this depth – along all four axes – that makes the player continue playing. Succeeding to deliver on all of them makes a great game. I could drop hundreds of examples here, but Zelda might be the easiest to prove my point. Most dungeons in Zelda are modeled to teach you the use of a newly acquired ability that manifests as a new weapon or tool in most cases. There are different settings and how to beat one of them is a question of using the right tool in combination with the settings affordances. The story layer in Zelda is quite linear and yet another interpretation of the famous Hero’s Journey which is in itself packed with witty metaphors.

A slightly different view on these layers of depth is presented in Hunicke et al.’s seminal MDA Framework. The authors of the paper list eight kinds of aesthetics that create the player experience of a game:

1. Sensation: Game as sense-pleasure
2. Fantasy: Game as make-believe
3. Narrative: Game as drama
4. Challenge: Game as obstacle course
5. Fellowship: Game as social framework
6. Discovery: Game as uncharted territory
7. Expression: Game as self-discovery
8. Submission: Game as pastime

While prototyping can not be used to directly test for one of these, and neither they are suited as generators for good game design, a game designer might still be able to probe for a specific aesthetic by creating a prototype. Our game is strong at challenge and discovery. Most of our prototypes so far have focussed on the challenge aspect of the game because we did not have the assets to support discovery. The single player campaign will lean heavily towards exploration and thus we need to build prototypes focus on the narrow space of risk/reward systems in spatial movement. We need to build environments that feature spatial challenges and rewards. If you read discovery less literal, exploring the main character’s capabilities is an act of discovery and can be prototyped by focussing on skill-based prototypes.

I think Hunicke’s list needs an update. The paper even states that the list is incomplete. Limiting social elements of games to fellowship and challenge is complicated in the age of FarmVille and Demon’s Souls. At the same time, social factors are a strong reason for submitting to a game. Nowadays – or maybe it was always the case – compulsion is the most important kind of “fun” in games, and the one most talked about. At the same time, the demise of music games can be read as a games-as-expression bubble. If players want to express themselves they fire up Twitter or Facebook. Most games are ill-suited to help you discovering anything about yourself but some physical abilities. Shadow of the Colossus stands as the exception to this rule. Narrative as story (the game’s story) builds on make-believe. Narrative as experience (telling other players about your personal journey) is in the discovery/expression corner. Thus I propose a new list of layers of depth in game design:

1. Sensation: Game as sense-pleasure
2. Challenge: Game as test
3. Competition: Game as rivalry
4. Fellowship: Game as event of social connection and alignment to a cultural circle
5. Exploration: Game as uncharted territory
6. Drama: Game as make-believe and drama
7. History: Game as an experience worth telling stories about**
8. Compulsion: Game as force that pulls you in
9. Metaphor: Game as learning something about you and the world around you

Our own starting points for level design – story, metaphor, skill and setting – can be integrated into this broader set of aesthetics. Skill becomes challenge, story becomes drama, and the setting is what allows for exploration. Only metaphor stays as it is. Now it is up to us to effectively start implementing mechanics that foster dynamics that trigger aesthetics. And if we design for enough depth on all these axes, we will be able to pull off the game we set out to make. Do the same. Make a good game.

* The late Steve Jobs served this marvelous quote about his definition of design: “Design is the fundamental soul of a man-made creation that ends up expressing itself in successive outer layers of the product or service”

** I’m not happy with that choice of word

The service in Wii Tennis works like this: First, you waggle the Wii Remote to throw the ball into the air. Then you make a racket swing-like gesture with the remote in order to hit the ball. The higher up the ball, the mightier the service. When you strike the ball in the moment it reached the apex of its flight curve, you serve with maximal speed. Hit it perfect and you play a “power serve” that smashes the ball across the court leaving a trail of smoke. Countering a power serve requires perfect timing. After failing to perfect his abilities to reliably play the power serve Peter invented the so-called “Lulu-service”. It’s the on the opposite end of the coolness scale.

While the power serve is played by throwing the ball into the air and hitting it with the bat when it has reached its peak, the lulu-service needs the player to hit the ball moments before the Mii catches the ball again with his hand. Why is the service so important in Wii Tennis? Because the game has an intricately balanced risk-reward scheme. After training for months, we reached a point where our games were brutal hit-and-miss duels. Just like in real tennis, we played serve and volley, yet without much volleying. The thing with the power serve is that it is a high-risk operation. If you succeed, you most likely win the point, because returning it is so hard. Yet if you miss that small window of opportunity and fail, the opponent can strike back by returning a 100% uncatchable ball. It’s hard to play that return, but we were good enough, back then. The game punishes you severely for failing while rewarding you for taking the risk if you succeed. It would be a classic risk-reward scheme if there weren’t the lulu-service. Played that way, the ball barely makes it over the net. It touches ground right behind it, making the opponent’s Mii hurl himself across the field. Since the ball ends up so close to the net and has so little velocity, it bounces just a few inches. The opponent can not play and aggressive return from that angle. If he does so, the ball inevitably ends up in the net. He can either play a lob, handing over the initiative to you again, or try to play a similarly limp cross. It is a good service because in most cases it allows you to remain in the role of the attacker. Also, it is easier to play than the power serve. In the end, it is the second-best service in the game.

Nintendo’s genius can be seen in this intricately modeled risk-reward scheme. Above, you find a risk-reward curve of the service in Wii Tennis. You can see how it diverts from a conservative, linear, “more risk equals more reward” balance. Additionally to its merits as a means to win a game, the power serve also serves a second purpose: it rewards spectacular play. Gears of War’s active reload serves the same purpose and is similarly cleverly modeled. The player gets rewarded if he risks to actively reload his gun and gets punished if he fails. Participation is optional, as active reload just shortens – or prolongs, if you fail – the normal reload sequence. Active reload adds depth and playfulness to a dull and repetitive task. I’m sure similarly structured game mechanics can be found in a lot of games, though they rarely come with the attention to detail that Nintendo put into the simple act of thrashing a ball across the court. Nintendo served risk and reward deluxe.

We usually work in one or two week sprints. It has been seen that we’e been doing three week sprints, too, but those were rare. We use Basecamp for the detail-work, i.e. todo lists and discussions. We use Skype for immediate communication. The scrum is a tool for on-site face-to-face collaboration and that’s why we do it on paper. We scrum on Monday, Tuesday and Thursday. Our core period is from 11am to 3pm. You’re supposed to be on-site during that hours. If you can’t make it to the office, you must be available on Skype during that time. The scrum is shortly after 11am, usually around 11:30am, once everyone is in the office or online. We try to timebox it to 15 minutes, but sometimes we fail.

We have no roles in our scrum because otherwise half of the team would have a role which somehow contradicts agility. We know that this will change once we’re a larger team, but for our current situation, the most important factor is honesty. And if you’re playing the “Product Owner” when you’re in fact the engine programmer, your honesty is severely compromised right from the start. We don’t play games, we make them.

Our scrum board has the following layout. There’s the “Future” box on the left. Unassigned and miscellaneous future tasks can be put into that box all the time. They are to be considered in the next sprint. Then there are three bars titled “Todo”, “In Progress” and “Check”. On the right, there are two boxes, “Done” and “Backlog”. An item is introduced in the “Future” box. During the planning of the next sprint, the tasks’ post-its are moved from “Future” to “Todo”. Also, one ore more people are assigned to the task, one of them officially responsible for the completion. Those are written on the post-it, too. If a task loops over the whole scrum board several times we talk about why that happens and either drop it or reframe it so that it can be completed. During the scrum meeting, each team member picks the task he’s going to work on for the next one or two days and moves the post-it from “Todo” to “In Progress”. He also moves all accomplished tasks from “In Progress” to either “Done” or “Check”. Tasks that are to be checked should be tested by a different team member before they are considered “Done”. If the task could not be completed and gets postponed to the next sprint, the team member puts it in the “Backlog” box. Additionally, there are “Mail Pending” post-its that signify an external dependency. Sometimes you can’t proceed because you’re waiting for a phone-call or email. Other dependencies are modeled using different post-it colors for the tasks. Red means either that the task is very important or that a yellow task depends on its completion. Green is one hierarchy level lower than yellow.

We’re currently quite happy with our custom-tailored scrum (or is it even scrum-ban; I’d say so). But there have been times when things didn’t work so smooth. We had one person responsible for the scrum meeting for some time who was not interested in that particular position at all. He did the job but the scrum really started to show its strength as a productivity tool once we’ve made our whole development dependent on it instead of having one guy reminding us that it is time for the scrum. Put bluntly, it’s necessary that the scrum feels necessary for everybody. We’ve also experimented with estimating the hours we have to put into a task and writing them down on the post-its in order to get a better feeling on the amount of tasks we can put into a sprint. That worked but always felt awkward to me personally. Currently we’re not pursuing this route anymore. In my opinion it is much more valuable to have flexibility than predictability. In other words: Postponed tasks and tasks that explode into hour-eating martyrdoms are problematic cases. Keeping an eye out for those is really important. We might experiment with a more abstract system of estimating the workload of a task in the future.

This is how we scrum. As usual, we’ve broken a lot of rules. I’m not writing this because I want you to copy our methods. I’m fairly certain you can ruin a project by doing that. All I want to tell you is that it is a good thing to tailor your production methods to your own needs. How do you scrum?

Part 2: The New Game Studio

There has been a disturbing number of success stories in independent gaming in the last years. First there was 2D Boy with World of Goo, then Jonathan Blow’s Braid came along, then Rovio introduced the whole world to Angry Birds and at last, Mojang made Minecraft – or the other way around. What do all these success stories have in common? They all (except of Minecraft, where it’s a bit more complicated) had about the same budgets. Each of them uses a custom engine. All of these games came to many platforms, or are in the process of doing so, extending their shelve life infinitely as they hop from marketplace to marketplace. Plus there’s one more thing they have in common: The studios that made those games still own the IP’s of the games.

Be A Fighter

If you want to go down the Rovio route, there are a couple of things you can learn from them. One of the most important ones is: Make tons of games. They were in the business for 6 years when they released Angry Birds, having released more than 50 – mostly mobile – titles. They dared to launch their own IP when the time was right for new IP’s, i.e. when the App Store was still young. Also, they kept their IP and just sold the distribution rights for the first Angry Birds game to Chillingo. Rovio had their tool chain and in-house tech in place. Once they struck gold, they immediately started building a community around their game, creating a loyal customer base. They were quick in switching the product to a service – and a brand, drip-feeding their newly created community with fresh content and monetizing their brand by launching spin-offs and selling merchandise. They wisely used their money to bring Angry Birds to each and any platform that pops up, lest an impostor grabs a marketplace with a clone. I’m also quite sure that they were quick in setting up a legal department, but I don’t know that for sure.

In short, these are the lessons you can learn from Rovio, or 2D Boy, or Mojang, for that matter:
- Keep control over your IP*
- Build your own tech (based on open platforms)
- Create your own community
- Get agile & hop from platform to platform**
- Have a lawyer

Don’t take this list as a recipe for success, though. There’ve been tons of studios that ticked all the boxes and failed. It’s more a list that tells what most successful indie studios have in common.

Be A Publisher

Mojang is another interesting case. They built their fortune on something that started off as a clone but quickly got into its own and grew far beyond any inspiration. Mojang shares a lot of properties with Rovio. They own their IP, use their own tech, and are experts in creating a community. Mojang recently announced the first third-party game they’re going to publish, Cobalt, which is an interesting road to go down once you’ve outgrown the single-IP stage of a new company. Turning into a publisher might not be the right direction for every independent game producer out there, but if you’ve got the community, the marketing power, and the understanding of the production process for a game, you might as well publish other indies.

Build A World

What Mojang and Rovio have in common is that they have a deep understanding of what constitutes their brands. I’d love to see them as not regarding their brands as “brands” but as “worlds” they are building for their players. They know what constitutes the unique style of their game worlds, from the graphical language to the gameplay. And they quickly and convincingly translate that knowledge into new products, be they marketing give-aways or spin-offs. While Rovio walks the Disney road without too much controversy, Mojang has certainly built a strong studio identity. Mojang proves every day that growth does not mean that you’ve got to compromise your values. And that’s also part of the world they’re building.

In my next, and last, article of this short series on the future of game development, I’m going to look at the future game. See you in two weeks.

* Kellee Santiago of thatgamescompany keeps reminding me that it is not about who owns an IP, but about who has control over an IP.
** Or strike an excellent deal with a big platform holder and grow from there. Depends on your IP, your studio, and your connections.

Part 1: The future is already here

William Gibson famously said, “The future is already here — it’s just not very evenly distributed”. Looking at the spectacular successes of some new-born gaming giants should tell us where the future lies. Apple, Zynga, and Mojang are suited best for my case. Lets look at them one by one.

A New Breed Of Hardware And Software

Apple has released the iPhone in 2007 and is now the dominant force in mobile and portable gaming. The PSP and the Nintendo DS are still selling well, but they already feel the sting of the iPhone. Looking at the specs of the PlayStation Vita tells how closely Sony is paying attention*. As I see it, three factors contributed most to the huge success of iPhone gaming: The fast platform iterations, the low level of entry for developers and the great software. Reducing the life cycle of the platform from 4-6 years to 9 months made incremental hardware improvements possible. At the same time, it made hardware sales a viable business for the manufacturer, whereas the PS3 was sold below production costs at launch. Apple established a walled garden for iPhone development, but the wall is significantly lower than in console development. Sony tried to replicate the lower wall with the PlayStation Minis and Microsoft has XNA. While the diminished costs of entry meant that the iPhone marketplace is crowded and full of cheap knock-offs and shovelware, it also enabled a number of startups to print money. The garden’s wall was lowered even further with of two clever moves by Apple: Having no dedicated dev kits by making each device its own dev kit and releasing easy-to-use free SDK’s. If you compare XCode to Visual C++ it is not on par in most regards, but it is free and developing for the iPhone is (nearly) as straight-forward as developing for the host machine. ObjectiveC made the wall a bit higher, but most games for the iPhone are programmed in C/C++ anyway. Or at least their game logic is. At the same time, the iTunes store is so seamlessly integrated into the product usage that it feels almost natural to buy software, as opposed to pirating it. Combined with the low prices and the automatic upgrade system, a lot of would-be pirates don’t bother pirating software on the iPhone. Just like Steam turned pirates into loyal customers by adding additional value, lowering the prices, and offering more convenience than torrents, Apple offers a service that is more comfortable than the gray market, and nearly as cheap.

Social Is Not A Fad. It’s A Change Of Lifestyle

I know a lot of game designers look down at Zynga because their games are hardly revolutionary in terms of gameplay. With most game mechanics indistinguishable from grinding, Zynga’s games are prime examples of what Nick Yee from Stanford University describes in the following sentences: “The timing and layering of reward mechanisms in video games train players to derive pleasure from the work that is being done. Video games condition us to work harder, faster, and more efficiently” (Yee 2006, p. 70). According to Yee, this careful crafting of challenges and rewards can be traced back to behavioral conditioning (see Skinner 1938). The player pays for being turned into a worker, producing, buying and consuming immaterial goods. Yet Zynga’s games sell like hotcakes. And people love that kind of mechanics. Why is that so? I’m sure part of the reason is that FarmVille perfectly blends into our socially networked surroundings. From its monetization strategy to the marketing, it fits perfectly into the world of today. At the same time, the bite-sized playing sessions fit into contemporary working environments: FarmVille is the Twitter of games**.

The Minimal Viable Product

Mojang is the developer behind Minecraft. By the time of writing, the game has sold 2,999,785 units, making it the fastest and best selling indie game ever. When Minecraft was first released, it barely deserved to be called an alpha version. It had barely any gameplay but the most important hooks were already in place. Then the beta came along and everything fell into place. Mojang is the most successful proponent of the minimal viable product-approach in video game development. A number of factors contributed to this success. First, Minecraft is a great game. Its sandbox-style open world with physics and endlessly fulfilling grinding fits perfectly into today’s gaming landscape. And it has pixels the size of voxels. Minecraft takes no learning and is hardly twitch-skill based. Learning Minecraft is playing Minecraft. Playing Minecraft is learning Minecraft. Clay, sand, rock, wood, everything in Minecraft is an abstraction of the real world. The game is social to the bones. Youtube fan-videos and the outspokenness of Markus “Notch” Persson, its creator, are perfect marketing tools. The success of Minecraft was neither an accident, nor planned.

Minecraft is but the best example of recent games that launched as minimal viable products, hardly in shape for prime-time, and turned into successes later. Yet neither the production methods nor the studio structures of most game developers allow for this way of production. It takes a new approach to game design and development, which is natural to some younger and more agile studios. It requires versatile technology and business models. And there’s hardly any knowledge about how a structured design approach for a minimal viable product looks and how those games can stand out in the sea of shovelware within the low walls of the new gardens.

Looking Ahead

I will continue this series of articles next time, where I’ll write about the new game studio and what the changes to game development outlined here mean to us as game developers. I’m no expert in any of this, just making up a plan as I go along. So feel free to bash me and tell me I’m wrong. I appreciate any and all critique.

* Also, I am personally delighted that we’re going to have RISC instruction sets on all interesting platforms in the near future. By the way, Apple was the first company to put a RISC processor into a gaming machine (if you don’t count the Archimedes/BBC Master).

** An important implication of social networks is the redefinition of privacy. It was Google who realized that this is where Facebook is occasionally too ruthless. I’d bet that features a la Google+’s circles will become a familiar feature of many social platforms.

References

- Skinner, B. F. 1938, The behavior of organisms. Appleton-Century-Crofts, New York.
- Yee, N. 2006, “The Labor of Fun – How Video Games Blur the Boundaries of Work and Play”, Games and Culture, vol. 1, issue 1, pp. 68-71.

The Data To Tweak

Ginkgo is a component-based engine. Game objects, which we call nodes, have basic geometric data. But their functionality is located in their components. Components are classes that wrap one specific aspect of a game object. They are coded in C++ and we use a Python-based Preprocessor-like script to generate their data definitions, which also include default values for all properties. Properties are (soft-)typed “data fields” of components. Some properties can be set via writing a specific piece of data into a specific memory location, made slightly safer than it sounds by our Property class. Some properties require accessor functions to be called. Since we do not have an inheritance system, but an aggregation system, we needed a solution to replace the comfort of the former while maintaining the flexibility of the latter. Thus we implemented a template solution; Template as “pattern”, not as “STL”. A template defines a game object, a required set of components and the default values of all the data of these components. There can be game objects without templates, but we currently don’t support runtime generation of game objects without templates. Each game object can override its template’s properties. Thus we end up with the following hierarchy of initialization of all properties. Higher levels override lower levels in the hierarchy shown in this graphics:

Data Bindings

We use the above-mentioned properties to establish rtti-like access to game objects. Reading and writing properties is implemented via a delegation mechanism. Well, actually there are a couple of different ways to read/write data values to/from objects and only the most slow & uncomfortable one is based on delegates. Though you won’t notice that from the “user” side anyway. The same mechanism is used to implement editor access. Soft-typed access, as I’m used to call it, lends itself to data bindings for GUI’s. The functionality — apart from a number of convenience functions to allow for faster browsing of scene objects — is that there is a property tree that reflects a game object. The nodes of the tree are the game object hierarchy (game objects can be inside other game objects to group them) and the components. The properties are at the leaves of the tree. The Controller of the MVC structure I implemented manages the tree. The leaves got their own controllers that manage the binding between a property and the text field that allows editing it. The clue is that you set the runtime value as well as the definition value of the property. And you can edit a game objects’s template with a similar tree widget. As a level designer, you have full access to the value hierarchy. This is especially important in a live editor, where runtime evens might override the runtime data of a property. We use the per-class property definitions when creating the game object. When the engine is compiled for edit mode, the same definition is used to store the values that get written back into the property’s XML definition. These definitions are stored on save, together with the edited templates. Bear in mind that the original definitions are per class. We store an extra definition structure per instance for editing. Runtime values are not preserved, so as not to overwrite startup values. I.e. you want your objects to spawn in the right place, even if they moved during gameplay.

Extending the Library

At first, I thought Gwen is a well rounded library. While most nuts and bolts are in place, it still lacks some features I needed. Gwen comes with a property editor, but there are just text fields, number fields and a color picker that does not support alpha. All our data descriptions are string-based, so we’re currently using the text field for all the editing. Later, I will have to implement at least a pop up list, an alpha-supporting color picker, and a clamping-supporting number box. In order to make the editor more comfortable to use, I wanted the property fields to display the definition value when you mouse over them. Usually they show the current runtime value. And there were other little changes I had to make to the text field-based property editor fields, e.g. exiting them without entering the data by pressing escape, or rewire them so that they only fire change events when the user presses enter. Per default, the event is fired once the user presses any key.

Here’s how I’ve extended Gwen to suit my needs:
- I’ve added an Event::Caller called onEntered to the class Gwen::Controls::Property::Base. It is called when OnTextEntered() is called by the underlying text box. Since continuous update triggered some cases where the value was incorrect (and immediately set back to the last valid value) I had to add this event to the library itself.
- I’ve added an OnKeyEscape() function to the Gwen::Controls::TextBox class that blurs (de-focusses) the text box.
- My Property Field Controllers are hooked up to the Gwen::Controls::Property::Base subclasses via OnPropertyValueChanged. This event is fired by Gwen, if the user edits the property. It is responsible for writing the new value into the property data field as well as the property’s definition. If a template is edited, the same event writes into the template definition. Property definitions and template definitions are saved. No API changes necessary.
- The above-mentioned behavior of showing the default value on hover is added via the Gwen::Controls::Property::Base‘s onHover Event::Caller. No API changes necessary.
- I’m adding checkboxes to mark if a template default was overridden via the GUI by attaching them to the Gwen::Controls::Property::Base. Since scroll bars were overlapping with checkboxes I had to adapt the rendering a little bit. I also had to add rendering for different checkboxes. A simple subclass to the existing checkbox does the job nicely.

I know that there are as many ways to architect a game engine as there are stars in the sky. Ours might not be the most performant one, and neither is it the most comfortable to work with. But with Gwen, we’ve found a GUI library that allows for a cross-platform live-editor that does not explode our code base and is simple enough to be portable to future platforms. It’s not the solution to every GUI problem we’ll ever face, but it proved to be a versatile, easy to integrate, and well behaved library. Now, if I manage to get rid of all the dynamic_casts I could even use it in deployment builds.

P.S.: Sorry that I did not include source code. My code is so intertwined with the property system that I’d have to add the source of that, too, which would explode this post.
P.P.S.: We’re currently using good old XML as a data format. But its well encapsulated and we’re planning to enter the 21st century by totally going for JSON in the near future.
P.P.P.S.: This posting concludes my series about Gwen. I feel like I should write about a less technical topic next.

Finding Gwen

The Gwen project is currently hosted on Google Code. The main community forum seems to be on Facepunch where you can also meet Garry Newman (of Garry’s Mod fame), who wrote the library. On the Google Code site there’s a handy guide to hooking up your own renderer with Gwen. Out of the box, Gwen comes with OpenGL, DirectX9, GDI and SFML renderers. You can use those by instantiating the renderer and you should be fine. Gwen also includes input handlers for SDL, SFML and Windows. We’re using OpenGL and SFML for Ginkgo, so there was not too much work to do. Input handling worked out of the box. I just had to adapt the focus handling a little bit. See below for details. The rendering was also pretty much ready to use, but I wanted to hook up our own resource manager and font renderer rather than loading textures and fonts directly. For now, Gwen just renders in every frame after the game. Since we’re building a 2D engine, draw order equals depth and Gwen thus always stays on top of things.

Taming Gwen

In order to write a custom renderer for Gwen it is best to copy or inherit from one of the included renderers and just replace the functions that you need to. In my case, I had to provide the following functions:

virtual void Ginkgo::Begin()
virtual void Ginkgo::End()
virtual void LoadTexture( Gwen::Texture* pTexture ) = 0;
virtual void FreeTexture( Gwen::Texture* pTexture ) = 0;
virtual void LoadFont( Gwen::Font* pFont ) = 0;
virtual void FreeFont( Gwen::Font* pFont ) = 0;
virtual void RenderText( Gwen::Font* pFont, Gwen::Point pos, const Gwen::UnicodeString& text ) = 0;
virtual Gwen::Point MeasureText( Gwen::Font* pFont, const Gwen::UnicodeString& text ) = 0;

Begin is called before any rendering takes place. Set up your projection and model view matrices as well as a pixel-exact viewport in this function. You can pop everything back to normal in the corresponding End() function. Load texture should load a texture via your resource manager. Fill out the struct Gwen::Texture and return it. You can save a pointer to your engine’s texture class in the data field of Gwen::Texture. Here’s how I implemented it:

void Ginkgo::LoadTexture( Gwen::Texture* pTexture )
{
	GIN::Texture *tex = GIN::TextureManager::instance().get(GIN::FixedSymbolize(pTexture->name.Get().c_str()));
	pTexture->width = tex->width();
	pTexture->height = tex->height();
	pTexture->data = tex;
}

LoadFont does the same for fonts. RenderText and MeasureText both depend on your engine’s font rendering and should be implemented accordingly. We’re using a custom bitmap font renderer in Ginkgo, that can either write into pre-allocated interleaved arrays for per-vertex information and indices or return non-interleaved arrays for vertices, indices and texture coordinates. When I connect Gwen to our render manager (possibly the topic of one of my next posts) I’ll use the interleaved method. For now, I just have the font renderer allocate the data for me. Gwen is quite cleverly implemented. It caches rendering information and flushes the cache when it reaches a certain size and after it finished rendering. In order to properly fit your own rendering between Gwen’s cached vertex rendering you must Flush() before you render on your own.

One function that needs a little explanation is Translate(Gwen::Rect &rect), which is found all over the place in the renderers. Translate translates and scales the supplied rectangle and is the primary method for placing objects in Gwen. If you add your own rendering functions, be sure to Translate() all coordinates.

Make sure you load the default skin and at least one font before anything else. Set the appropriate values via SetDefaultFont and Init’s parameter of the skin. Here’s my setup function for the GwenManager. The texture “defaultSkin” and the font “editorFont” are both loaded in advanced.

GwenManager::init()
{
	_gRenderer = new Gwen::Renderer::Ginkgo();
 
	_gSkin = new Gwen::Skin::TexturedBase();
	_gSkin->SetRender( _gRenderer );
	_gSkin->Init(L"defaultSkin");
	_gSkin->SetDefaultFont(L"editorFont");
 
	V2f contextSize = RenderContext::instance().getDimensions();
 
	_gCanvas = new Gwen::Controls::Canvas( _gSkin );
	_gCanvas->SetSize( contextSize.x, contextSize.y );
	_gCanvas->SetDrawBackground( false );
 
	_gInput = new Gwen::Input::SFML();
	_gInput->Initialize( _gCanvas );
}

With this information, and the tutorial, you should be able to integrate Gwen into your engine. I don’t regret choosing this GUI so far. Attaching events is a bit awkward, but I’ll come to that next time.

We’ve integrated live-editing into Ginkgo some time ago by hooking up our component system and AntTweakBar. Now that the system has outgrown what AntTweakBar has on offer, I’ve started the epic quest of finding a suitable OpenGL-based GUI solution. Our requirements are straight-forward:

• Platform independence (i.e. Windows, OSX, possibly Linux and maybe even iOS)
• Unicode support
• Simple skinning
• Either scriptable or easy to abstract
• Copy&paste and Undo supported, or easy to add

I’ve spent the last two months on and off evaluating GUI libraries and toolkits in order to find the perfect one. Sadly, all of them have proven to have their downsides. Let me summarize what I’ve found out so far.

A failed experiment but you can see AntTweakBar in the top right corner.

What’s Out There

Of course I started my research by looking at projects that already have a working live editor and trying to find out what tools they’re using. Wolfire Games are fans of Awesomium, a custom version/wrapping of Apple’s WebKit (which started out as a branch of KHTML of KDE fame). There’s also an open source BSD-licensed equivalent to Awesomium called Berkelium that uses Google’s Chromium (itself a modified WebKit, as far as I can tell) instead. Both offer the benefit of being easy to skin and script since they are windowless browsers rendering HTML and executing JavaScript. On the downside, they are pretty big, adding 80MB of foreign code to your project. Since we’re eager to keep control over our source code and would love to maintain portability, even for the in-game editor, both of those sound like a less than perfect solution for us. Of course, one could substitute Chromium/WebKit with EA’s open sourced portable WebKit, but that looks like a major engineering task while all I wanted was a window with some sliders and buttons.

A somewhat similar solution two the above is libRocket, the poor man’s ScaleForm. It’s a freshly implemented wrapper for a subset of XML that approximates a subset of HTML. In other words: You can build your GUI in HTML and the library is less than 80MB large. Sadly, I found it unnecessarily difficult to get the library running and it is more suited for in-game GUIs than for procedurally generated editor panes.

On the other side of the spectrum lies Capcom Game Studio Vancouver’s tool chain for Dead Rising 2 which they explained in great detail over at Gamasutra. Incidentally their architecture greatly reminds me of Pure Data, the open source audio programming language / live instrument I used to work on years ago. You’ve got a server – the game, the audio engine, … – and a client GUI that connects to the server. All communication between the two goes over sockets. The upside of this approach is that you can live-edit your game even on a console, with the editor running on your workstation. The downside is that this approach is less suitable for in-game editing (where the editor lives in a window in your game context). Every coin has two sides.

Apart from these two there are numerous GUI libraries out there of varying quality and simplicity. CEGUI seems behind the curve nowadays, with “immediate mode” interfaces getting en vogue. Yet, IMGUI and its cousins are good for in-game displays but less suitable for level editors. Gwen and guichan are two packages of straight and simple C++ libraries I’ve recently had a look at.

A Quick Rundown Of What I’ve Found So Far

I’ve looked at a number of GUI libraries and attached a couple of them to our renderer – or at least configured their OpenGL rendering and hooked them up with our resource manager. Here’s a quick rundown of the pros and cons of those libraries:

• AntTweakBar: Perfectly suited for live-tweaking values. I’ve rarely seen source code as dense. Reminds me of Pearl more than of C++. Due to that it is very hard to extend and not suited for anything else but tweaking strongly hierarchically displayed data systems.
• Awesomium: A comfortable WebKit-based package for OSX and Windows. Closed source, unless you pay $$$. Can’t say how hard it would be to port it to Linux and/or consoles. 80MB large, which is hefty for a downloadable game. Easy to script the GUI in HTML5 and JavaScript. Simple skinning through CSS.
• Berkelium: Same as Awesomium plus Open Source. Linux support available, yet similarly unfathomably hard to port.
• libRocket: Does it’s own rendering but there’s not JavaScript support. I found it impossible to hook the system up with our resource system. But it sounds intriguing. Simple skinning with CSS. Lively community.
• Qt: Replaces your application framework like so many good tools out there. Visual designer available. Lively community. All bells and whistles, but we’ve built our game around the easily substitutable and portable SFML instead.
• Cocoa: OSX-only but, boy this library is good. Visual editor, beautiful and well working widgets, easy to integrate bindings. Object C-based and closed-source, so importable to other platforms.
• MFC: Insert random joke here.
• guichan: A small and portable GUI lib. Makes heavy use of exceptions but features quite good code quality. Widget set is rather small and there’s no copy&paste or undo management.
• Gwen: Like guichan, Gwen is a straight C++ GUI lib. It does support copy&paste and does not require exceptions. Very good code quality from what I can tell. Made by the guys who make Garry’s Mod.
• Tkinter: The standard python GUI. While the ugly standard flow layout might not be the perfect fit for everyone, scripting a GUI is the only viable replacement for a visual GUI editor.

Browsing my object hierarchy over telnet.

What I’m Doing Next

This week and the coming week I’ll implement a socket-based interface to our game engine. Then I’ll design a GUI that hooks up with that. What I’m planning is more of a browser than a full-fledged level editor. That way I hope to maintain the live-editing features of AntTweakBar but make everything far easier to access. I’ll keep you covered how that goes.

I’ve been writing path finding algorithms, balanced trees and motion blur shaders for the past 3 years and all I got was a lousy 76% (Anonymous game developer)

All of us have a different attitude towards game reviews. Reviews tend to be one-sided and unfair, sometimes even irresponsible. They treat your game like any other game, disregarding the fact that your own game is work of love and hard labour whereas the other games were just quickly mashed together in Unity. They don’t see the effort that went into the game, just the outcome. How unfair. Additionally, most of the time they culminate in a numerical score that does a lousy job in quantifying what you’ve been up to for the last 3 years. The world is different for AAA than for indie games (again!). Where there’s a dedicated marketing team for AAA games, most indie studios have to manage publicity themselves, meaning that reviews are even more personal. In this #AltDevBlogADay posting I’d like to comment on game criticism, as you cannot deny that it is one of the many forces that shape game design.

Side Quest: Personal Experience

I’ve been reading reviews of my own games for the past years and I was startled – even shocked – by some of them. The more abstract my games were, the more interesting the ideas reviewers had about how they work. In the beginning of my game development life I tried desperately to learn from reviews. Then I shot myself in the knee by issuing a sequel to a game that tried to repair everything that needed improvement according to reviewers and players. From that point on I decided that I won’t listen to complaints in reviews anymore. I tend to avoid them altogether, nowadays, except when I know the journalist.

Reviewers Are People, Too

One of the key facts that I’ve learned from Chillingo’s Chris Byatte (or was it Joe?) is that reviewers often secretly (and sometimes openly) want to make games themselves. They just ended up on the wrong end, somehow. Of course, it could be the other way around. Journalists told their audience what is wrong about a game for such a long time that they believe they know how to make a game without wrongs. Now, while there might be stories about game journalists that turn into successful game makers, what you should learn from this is that the journalist is not eager to imprint his ego on your game. Most journalists write from the assumed perspective of their audience. All journalists I’ve ever met were willing to contribute and constructively criticize my games when I communicated directly with them.

Flocking Behavior

Just like money breeds money, favorable reviews breed favorable reviews. A lot of games get carried away by a wave of rave reviews if their first review in an established magazine is overly positive. And it takes courage and strength to defend a game that got meager reviews from other sources or to bash a game that everyone pretends to love. Journalists fly in flocks, creating trajectories. I’m sure there’s a marketing term for this. Our last game’s metacritic score barely moved 3 points after the first 10% of reviews were received. In other words: Once your game is a ~83% game, it stays that way. There are hardly any games that really divide the professional reviewers. Many more of them divide the player masses.

The Good, The Bad, And The Ugly*

Coming to an end, I’d like to highlight some of the braver attempts at journalistic integrity and ingenuity and lament about some general faults. Have your read the recent Infinity Blade review by the notorious Kill Screen magazine? If not, do it now. The 100 word reviews the guys at No Added Sugar came up with are pretty hilarious, too. And of course, there are the standard bearers like e.g. EDGE magazine. When you look at the landscape of iPhone game reviews, it is striking how much amateurism there is. But the field is very young and it might simply take a few more years until professionalism settles in. Still, there are laudable efforts in this area, e.g. the O.A.T.S oath of ethical standards for reviewing presented above.

Reviews lost some importance with Twitter and Facebook and thus word of mouth getting the prime way of exchanging opinions about games. Those channels are not so much marketing tools as they are direct communication channels with your audience, the players. Nowadays, a high profile tweet about your game might shift more units than a rave review in an established print magazine. I welcome this new world of game criticism and I think that professional journalism is the perfect counterpart to rampant amateurism. Did I just end up with a critique on the state of the art of game journalism? That was unintended. Oh well, I’m off making a 91% game now.

* I swear I’ll stop using that headline.

Outages, Hacking, and Dependency

The hacking of Sony’s servers demonstrated what is the most media-effective trouble an online distributor can run into. Losing your client’s data is embarrassing and expensive. But that is just Sony’s part of the problem. For game developers with their games on PSN, the missing revenue for the time of the service’s outage, might yield lower numbers than Sony’s reported $170 Million. Nevertheless, the loss of a revenue stream is hard to compensate. Of course, other companies could become culprits of hackers the same way, Sony did. I expect other services to get hacked or DDoS-attacked in the near future. Imagine if Apple or Microsoft are hit. On the brights side, just like bank robbing does not bring down the banking system (and neither does Bernard Madoff), criminality has always flocked around money and rarely destroyed working ecosystems. The only thing you can do as a small games company is to diversify as much as possible. Establish as many revenue streams as you can, because if one of them dries up, you still got the others. Make yourself as independent as you can. Diversify! Sounds easier in theory than it is in practice.

The Player As Customer

I should rather title this paragraph “unidirectional communication”. I’ll start with a story: We’ve released And Yet It Moves for the Mac App Store when that opened. We had a Mac version of the game for a year, so it was pretty straight-forward to make it compliant with the terms of service. After a few submissions we were in the store and thanks to Apple’s gratuitous featuring and the quality of the game we quickly rose up in the charts, leading to a #2 spot in the charts on our best weekend. Then an unexpected dynamics started to kick in. We’ve learned that some older MacBooks and iMacs have trouble rendering the shaders in the game. Also, case-sensitive file systems introduced buggy behavior. We simply had not tested on enough different kinds of hardware. We fixed those bugs but some players were still having trouble getting the game to start. It just showed a black screen on startup. We released four patches so far, all of them addressing the same issues and introducing only very few new features. While we fixed the game for most players, sadly, there are still systems out there that seem to have the black screen problem. They are very few and none of the test systems we have access to still has the problem. We’ve done our best to fix the game for every user. And we’d love to work with those that still have trouble getting the game to run.

The core of the problem is: One of the users that is still suffering from this problem is “Like Clockwork”. And what that user does is that he posts a one-star review minutes after a new update hits. I suppose he will do so until the problem is fixed for his system. His most recent review is:

“there have been several updates to this program, all promising a fix of the “black screen” issue, yet every time i start the game, i get NOTHING but a plain black screen. i want my money back!” (Mac App Store)

Apple has a refunding policy, and it would be very easy for Like Clockwork to get his money back. We’ve got a support forum and we’d love to send Like Clockwork a test version of the next update before we publish it. We’d also love to hear what hardware he owns in order to test our game on that specific type of Mac. Sadly, the Mac App Store makes it far easier to trash a developer with a one-star review than to offer support. Our game runs on 99% of the machines out there. Bugs happen. The player is a great customer if the platform supports him. What we’re learning from this experience is that we will release our next game for the Mac with minimal hardware requirements. You have to design for the lowest denominator because one angry customer is enough to break your neck.

Tangible Ethereal Goods

I have a theory. If products turn from physical goods to ethereal, something has to compensate the lack of haptic sensation. In other words, back in the days when games were still physical goods – and I’m talking about those days when the additional content of the package was worth the money alone – you got something tangible and seemingly personal from the manufacturer of the game. With the introduction of standardized packaging and even more with digital downloads, this aspect of the physical good got lost. Still, the hardcore fans of any brand, those key leads you have to target first, if you’re marketing your games yourself, demand a personal experience. The AAA world introduced limited editions for this demographic. What we’re trying to do in the indie world is to establish a relationship with our customers. Via twitter, Facebook and all the other dreaded social networking systems. We can’t have a marketing person, department or company make that for us, because our core players want direct communication with developers and designers. The Humble Indie Bundle managed to leverage this aspect of digital games marketing very successfully. The most tangible thing we’re offering nowadays is ourselves, the developers. Of course you can also sell plush toys via Etsy instead.

I hope this post did not come out as a rant. I would not say that I believe that digital distribution is the future. I think it is inevitably coming our way. The reasons are manifold and most of them are not in the interest of the customer – e.g. having full control over content distribution, destroying the second-hand market, and diminishing piracy – but the security, comfort and possibilities it offers are by far exceeding the downsides for most people. For each poison, there’s a remedy, and for every woe of the download market, there is a strategy to work around it.

I’ve been working at a technical university for the last 5 years before I joined Broken Rules. I’ve also been part of the committee that shaped a new curriculum for a university of applied sciences some months ago and lectured at a number of universities. I’m still teaching game design and prototyping courses at the Vienna University of Technology. During the years at the university I’ve done my best to produce bright and open students. Students with a passion for computer science and new media. This article is written from the perspective of an indie developer that runs a flat company. Small companies have specific recruitment needs. While there are highly specialized startups that require employees with very specific capabilities, the majority of small independent games companies needs generalists. In my company, we’re all wearing exquisite collections of hats. Most of the local games companies are small to medium sized. The same holds true for web startups and content providers. That is a European tradition. Local universities should produce a workforce for local companies. Nowadays, our European economy builds on innovative small businesses – even if they get sucked up by large corporations. So why not focus education on their needs?

No More Programmers

Educating generalists means that we don’t teach programmers. Most of the brilliant programmers I’ve met are great despite their education, rather than because of it. They were not spoiled by mediocre programming courses they had to attend at uni. They were self-taught and quickly included the knowledge they acquired in the structured environment of the educational system into their rich private pool of knowledge. Yet they profited particularly from the few high level courses that a university offers. It is ironic that highly specific courses advance the generalists the most. Similarly, focussing on one computer language, no matter which, is wrong. Someone who receives a master degree from a university in a technical curriculum must have a thorough understanding of programming that goes past the ability to work in a specific language. If you show him a PHP script he should be able to edit it within seconds, even if he’s never seen PHP before. He should immediately recognize that Clojure is a LISP dialect. And he should be taught OOP with all its pitfalls and flaws. Even if he’s hired as a C++ programmer, I would expect him to write a Python script when it’s appropriate. As an indie we rarely hire pure programmers. Most of my team is made up of designer-engineers. We could invent a new word for us: Designeers. We need an education for designeers rather than one that isolates engineering from design.

A New Foundation

In my personal opinion, a solid footing in the history, theory and practice of information science is the best basis for developing deep interest in computer science. Whether it is the history of computer systems, mathematics, information theory, theoretical informatics, or the social implications of information systems, a strong background in the science part of “computer science” is crucial for becoming a generalist. In order to nourish the interest in all things digital, the social ties between students need to be strengthened. A lot of Scandinavian universities excel in this aspect. The german speaking countries with their German tradition of studying are less inclined in supporting the social side of learning. I could ramble on for hours about the architectural differences between the ITU in Copenhagen and the Vienna University of Technology. Suffice it to say; we could learn a lot from Finland and Denmark.

It’s The Money That Ruins Everything

During the last years, more and more of my students took on jobs during their studies. Nowadays, there are hardly any full-time master students anymore. While it is important to learn how to work and to apply your knowledge, I still think that it dilutes their studies. Maybe it was the transition from a single 5-year Master curriculum to the Bachelor/Master curriculum, which yielded half-educated half-prize programmers. Maybe the parents can not support their kids’ education anymore. Maybe the iPhone4 is a tad to expensive for a student but considered mandatory equipment nevertheless. All I know is that I’m sure students would benefit more from starting non-commercial pet-projects and fumbling around with strange OSs and languages than from making websites for an advertising agency.

I know I’ve formulated this posting in very general – and slightly whiny – terms. There are great students coming out of all universities I’ve mentioned. I just fear that the current direction education is taking, turning the self-determined and free student of the once-revolutionary universities into a schoolboy, is not leading in the right direction. You cannot optimize education indefinitely. Sooner or later it breaks.

PS: Now I don’t know what’s wrong with education in America, but it looks like it is as bugged as ours. Just differently so.

For a AAA-developer, even a budget of $140k would be a joke. Yet for an iPhone project, this is an immense pile of money. The average budget for iPhone software can be assumed as $35k. Even with a budget that low, you can not expect to generate enough revenue to recoup your investment. In fact, it is not a sane economic decision to invest $140k in a project for a platform where the average return is as low as on the iPhone. According to this analysis, the average sales of a number of surveyed games were 11,625 units, or 44 copies per day. However, 56% of the those games sold less than 10k units. What lessons can be learned from this state of affairs?

We’re working on a series of three games, in the moment. While I cannot talk about the content of those games yet, I would love to take this opportunity to talk about our budget. We’ve recently received public funding for this project. Remember, we’re based in Europe. In order to acquire that funds we had to submit a detailed project and budget plan for the duration of the project, which runs until early 2013 in our case. Each game has a budget of around $100k for the initial release and a further budget of around $75k for ports and sustained support. How did I end up with these numbers? I’ve had an enlightening conversation with Martin de Ronde from Vanguard Games (and formerly from Guerilla Games) and after that I knew what to do. Martin was kind enough to share his thoughts on development costs and his advice was: Either go for $100k or invest more than half a million. Since the latter was not an option for us, we decided to design the project so that it fits in the first category.

Our budget is spread between all kinds of development tasks, from coding and game design to marketing. Additionally, there are material costs for dev kits and there’s a traveling budget. The following pie chart shows the distribution between those tasks. The “Code” task is a bit misleading because it includes all programming as well as gameplay-scripting and other game design tasks like controls tuning. Also, 80% of the costs summed up as “Materials” are marketing costs. Still, our marketing costs are exceptionally low and our coding pretty dominant. If I had had this chart at hand when I planned the project I would have skewed the numbers a bit to give marketing a bigger role. Still, most of our marketing is community building, which is a) cheap and b) not in the project plan.

I would not advise to take this template and apply it to any project. The reason why the coding piece of the pie is so large is that we’re currently building our own tech, as you know.

Compared to other indie games that have published their development budgets, we are on the cheap side. Braid – a showcase in indie marketing as well as game design – cost $180k to develop. World of Goo, another indie darling, had a budget of $120k. Both are in the “forbidden zone” mentioned above, as is Angry Birds. We are aiming at three games of the size and scope of these examples and hope to achieve the same level of game design and polish.

In sum, I think it was a brilliant idea of Rovio to invest $140k on an iPhone game. There are only a handful of games of this scope on that platform and most of them were very successful (e.g. Rage, Infinity Blade, World of Goo). The tide of no-budget games drowns most low- to normal-budget outings. Rovio went with a publisher – Chillingo – and allocated the time and talent needed to bring the game into a shape that reduced the risk of investment significantly. In other words: investing $20k in a downloadable game is gambling. With a fitting budget and the right team, you can reduce your risk. I’m sure there’s a business term for this.

Take another grain of salt and apply it to my personal advice, which is:

• It looks like $100k to $140k is a suitable budget for a downloadable indie game.
• It is wise to acquire additional money for sustained support and porting, although you might only need it if you strike gold, anyway.
• There are more articles about sales numbers than about development budgets online.
• Of course, the most important thing is that your budget fits to your game.

PS: This blog was initially published at #AltDevBlogADay.

Brooksoid asked:

I’d love more details on what’s going on in your macros, as information on Terrence’s COMPONENT macro is non-existent.

Actually the only macro that I mentioned in the article but did not properly explain is GIN_IMPLEMENT_COMPONENT. This macro expands to the following code:

#define GIN_IMPLEMENT_COMPONENT(className, stages) \
GIN_IMPLEMENT_DERIVED_COMPONENT(className, stages, );

#define GIN_IMPLEMENT_DERIVED_COMPONENT(className, stages, baseName) \
ComponentPool* className::_pool; \
ComponentInfo className::_info = { ComponentManager::unregisteredType, #className, ComponentManager::unregisteredType, #baseName, SymbolArray(0) }; \
GIN_IMPLEMENT_COMPONENT_HELPERS(className) \
GIN_IMPLEMENT_INITIALIZE(className) \
void className::preMain() { \
	_pool = new ComponentPool; \
	ComponentManager::instance().registerType(&_info, 		\
							static_cast(_pool), 	\
							stages); 			\
	staticInitialise(); \
}

As you can see, the macro mostly adds static functions to the component class. The preMain function is actually a misnomer. It is called before the engine enters the runloop, but in main(). Still, preMain allocates a static component pool for the class and registers the class type. The info structure used for registration is similarly static. At last, it calls the staticInitialise (which is obviously British) function that registers all properties (functors) of the class. Maybe I should write about our property system at some point. For now, I’ll just say: The property system registers component variables for XML import and export, the in-game editor and (soon) scripting.

GIN_IMPLEMENT_INITIALIZE hooks up the preMain function following Gregory’s Game Engine Architecture:

#define GIN_IMPLEMENT_INITIALIZE(classname)	\
bool classname::preMainRegistered = false;	\
bool classname::registerPreMain()			\
{ \
	if ( !preMainRegistered )				\
	{ \
		Initializer::AddInitializer(classname::preMain); \
		preMainRegistered = true; \
	} \
	return preMainRegistered; \
} \
static bool classname##RegisteredInitialize = classname::registerPreMain();

The class Initializer is a singleton that calls all registered initialize functions before our engine enters the runloop.

coolbeenz asked:

I would also be interested to hear if and how you support a GetComponent( ComponentType ) on an object instance.

We have several getComponent() functions in the Game Object. Bear in mind that the components are stored in contiguous arrays in the ComponentPools. The Game Object just stores a linked list of its components in what we call a component chain. This list can be queried for a specific component type. The Game Object also offers handy functions to access other object’s components, but those are rarely used. Each component can have a name that might also be used for retrieving it. The most commonly used method for getting a specific component is a template function that expands to getComponentThatImplements(T::type()), where type() is the static type stored in the _info structure and registered by the GIN_IMPLEMENT_COMPONENT macro above. getComponentThatImplements first tries to return a component of the correct class. If it fails, it returns a component of a derived class.

Brooksoid asked:

I figured (naively?!) that the vtable indirection would be absorbed by the d-cache once you’ve updated the first component of a type, and all the repeated calls (for the rest of the components in the pool) wouldn’t really cost…

This is the result of a battle design by compromise between Peter, our main C++ coder, and me, our main C coder. I wanted a virtual-function-free component system closer to the Entity System architecture proposed by Adam Martin. Peter wanted to stick to the OO features that C++ offers. In the end, we settled for a compromise that is neither optimal, nor satisfying for anyone. Maybe it’s time to refactor that bit. We’ll profile that part when we’re on the brink of moving into production with our current game.

My next post will be about component communication. We’ve implemented more than enough methods of cross-component interaction and I’d like to publicly discuss those. I’d appreciate feedback, so please keep it coming!

There aren’t many rules we’re following, hence the name of the company. But we’ve developed three key techniques for game design that I’d like to share. They work for us, so they might as well work for other comparable teams. I’m not so sure about larger teams and companies and neither about more traditional projects. We’re independent because that allows us to make those games that a traditional publisher hardly funds. Also, we’ve only released three games so far (not counting my 3 iPhone games) and only one of those is of a decent scale and ambition. But we’re currently working on our next big title. We’re in the second pre-production phase of this project. We’ve finished a playable core gameplay prototype, playtested it and made a vertical slice. At the moment we’re testing out other gameplay elements and working to get the engine on speed. The rules we’ve followed so far, and that have proven to unleash a lot of productivity and creativity are:

• Brain Day
• Constraints are King
• The Single Invention Rule
• Kill Your Darlings

Let’s visit them one by one.

Brain Day

This one is simple. During the early stage of development everyone involved in the creative process of conceiving the game is allowed – even encouraged – to have a Brain Day once a week. On Brain Day you’re not supposed to show up at the office. You might go shopping or enjoy a walk. Or just stay in bed all day. You might Skype with the team but you’re not expected to check your emails. Just do whatever is necessary to get into a creative mindset and let the thoughts flow. If you turn up with a gameplay idea, a setting, or a sketch on the next day that’s excellent. If not, there’s another Brain Day in the next week.

Constraints are King

This one has a backing in academic design theory and has been iterated more than enough by a lot of clever people. We’re making 2D games because with our team of five we could simply not make a full-fledged 3D game. We’ve settled for a game world before we’ve developed most of the gameplay, because once you know what world your game is playing in you can just look at it and pick those elements of that world that you currently need for your game. We’ve tried to make gameplay fun when it was played with the accelerometer alone, before we introduced buttons. We’re working with prototypes with wireframe graphics to focus on the gameplay alone. Some constraints we’re experiencing are external – budget, time, platform technology, and team size are examples for those – and we have to work within those limits. Other constraints are internal and we set them up explicitly in order to fuel our creativity.

The Single Invention Rule

This is maybe something indie-specific. Since we’ve got no publisher backing and are completely free in our game design decisions, we’ve come up with one specific constraint that’s central to our design philosophy. The Single Invention Rule is actually based on a talk by Kellee Santiago (from thatgamecompany) that I can’t find right now. Our interpretation goes like this: There should be no more and no less than one gameplay, one technological and one conceptual innovation per title. With our upcoming games we’re trying exactly that. We’ve got revolutionary gameplay, but only in one aspect. Some of the tech we’re working on is to be considered innovative for our standards. And the concept of the games we’re working on is innovative, too. I can’t go into detail because the game’s not announced yet. The idea of this rule is that it’s far too easy for an independent game developer to invent something completely new. Yet players want games that are approachable. And they want to understand what’s going on when they see a screenshot. The single invention rule keeps us from letting our creativity run loose.

Kill Your Darlings

Richard Fine wrote about this the other day: Don’t get too attached to anything. Be prepared to throw away key parts of your game if it is necessary. Every time we run into a dead end – and we’re running into dead ends a lot during the initial design of our games – we’ve found our way out by throwing something away. It might be a key game mechanic or the graphical style. Sometimes it’s the target platform or the control method. Just because you sunk a lot of time, effort and money into it does not mean that it was a good decision in the first place. The challenge is to isolate the piece to get rid of. A Brain Day helps to get some distance between you and the project. Or a pair of fresh eyes.

These four rules are cornerstones of our design process. They’ve helped us open up the design space. Currently, we’d need some new rules that help us to narrow the design space again. But I’m sure we’ll come up with those once we really need them. And I’ll keep you posted.

The textbook approach to game loops is to model them as simple loops that first process the input, update all game objects and then render all objects:

while (!quit)
{
	ReadJoypad();
	UpdateScene();
	DrawScene();
	FlipBuffers();
}

In an OOP system, the update function is usually found in the game object. After each object drew itself – or was drawn – the graphics buffer is switched. In a more sophisticated engine this buffer switching might be synced to the vertical refresh of the graphics card.

Jason Gregory of Naughty Dog described the pitfalls of this design in his excellent talk at Game Forum Germany 2011:

“It’s also terribly inefficient
- potential for duplicated computations
- possible reallocation of resources
- poor data and instruction cache coherence
- not conducive to parallel computation”

In Ginkgo, every component registers for n update pools. N is usually 1, sometimes 0 and might be >1 in the future. The pools are triggered consecutively. Thus, we can order components, aspects of the same object. There are no game objects, but each assembled component group that forms a runtime game object receives several update calls as each component might be updated with a different pool. Rendering is done by one of the game object’s component among many. All rendering components are currently executed in the same update stage at the end of the loop, though this is not strictly necessary in the long run. Naughty Dog’s engine uses a dynamic bucket-based approach, which is something we might consider in the future, e.g. as soon as our number of update stages goes over a certain threshold.

In order to address the above issues we took the following actions:
- Less duplicated computations by building pools of similar objects and manager objects where it’s appropriate (e.g. the particle system, physics engine, etc.).
- We forbid reallocation during update. Let’s see how that ends ;-)
- We increased cache coherence by putting our components into pools and updating them pool-wise.
- We have not thought about parallel computation yet, but we have a very clear image where sync points will/might be.

But there’s an additional issue with game loops. There are a number of algorithms out there that profit significantly from predictable timing. The Runge-Kutta methods – which are widely used in physics calculations – are an example. Now you can’t change anything about the timing of the screen refresh. But in Ginkgo, the render timing is based on the vertical sync of the graphics card whereas the physics engine we’re using, Box2D, uses integration methods that demand fixed timesteps. Gladly, Glenn Fiedler wrote an excellent article describing how to merge these two time sources into a single game loop, “Fix your timestep!“.

Why not dive straight into the subject matter at hand and look at our game loop:

void Ginkgo::update()
{
	f32 timeScale = _paused ? 0.0f : _timeScale;

	f64 newTime = System::getTime();
	f64 dt = newTime - _systemTime;
	_systemTime = newTime;
	_deltaTime = (f32)dt;

	// For timescaling we need to consider 2 values:
	// 1) _deltaTime: We stretch the time that passed since the last frame with _timeScale
	_deltaTime *= timeScale;

	// 2) _currentTime:  We need to fake this value for all the components and systems that use currentTime() to update their state (TaskManager etc.) in order to reflect that time passes slower/faster than usual.
	// We can do this by moving the _startTime value backward/forward corresponding to the offset of the real vs. the scaled time per frame.
	// Thus currentTime advances slower/faster according to timeScale. This is the most problematic point, as numerical errors will add up here.
	f64 timeOffset = dt * (1.0 - (f64)timeScale);
	_startTime += timeOffset;

	// currenttime is the time since start
	_currentTime = (f32)(_systemTime - _startTime);
	
	// deltatime is the time since the last loop
	_accumulator += _deltaTime;

	u32 numTicks = (u32)glm::floor(_accumulator / TICK_DURATION);

	_accumulator -= numTicks * TICK_DURATION;
	numTicks = glm::min(numTicks, MAX_TICKS);

	for (u32 i = 0; i < numTicks; ++i)
	{
		// We use a fixed-step update function and accumulate between frames
		++_tickCount;
		tickStages();
	}

	// Rest of the accumulator, in percent of dt
	_interpolationFactor = _accumulator / TICK_DURATION;

	updateStages();
}

This game loop first determines a timeScale for this loop. If the game is pause, the timeScale is set to 0.0. The current time is requested from the class “System” that provides a uniform interface to platform-specific functions. “dt” – delta time – stores the seconds since the last iteration. It is scaled by the time scale. A time scale of 2 thus means that the system behaves as if double the time has passed sine the last iteration, doubling the game speed. In order to correctly scale the execution of e.g. scheduled tasks that demand absolute time, the start time of the engine needs to be adapted. The engine thus behaves as if time would always have been that slow or fast.

In order to maintain a constant tick rate, an accumulator is used. This variable gets the last time slice added. Then the number of ticks in the accumulator is calculated. The update() function of all pools registered for ticks is called via tickStages(). This function first updates all PreTick components, then Tick and at last PostTick. These are the three update stages in the tick section. Glenn Fiedler describes the accumulator as follows: “Any remainder in the accumulator is effectively a measure of just how much more time is required before another whole physics step can be taken. For example, a remainder of dt/2 means that we are currently halfway between the current physics step and the next. A remainder of dt*0.1 means that the update is 1/10th of the way between the current and the next state” [1]. This remainder has to be used for interpolating the actual position of e.g. a sprite when the frame needs to be drawn as the drawing occurs between ticks. It is stored in _interpolationFactor. At last, updateStages() is called. This function updates the pools that registered for the PreDraw, Draw and PostDraw update stages as well as all singletons that need frame-wise updates, e.g. the external sound engine.

While our approach to the game loop is not as elegant as Naughty Dog’s, it still solves a number of issues more naive approaches to game loops have. And it integrates nicely with the physics engine. The usual disclaimer: Ginkgo is a work in progress, and every line of code might change in the future. Also, I’m happy for all feedback!

I think I’ll take a leave from Ginkgo for a while and make my next posting about something entirely unrelated. Let’s see how that works out.

Here’s the thing to remember: We’re a team of just two coders working on this engine. Also, bear in mind that we’re currently at a very early stage. Everything can still be changed – which is the main reason why I’m writing publicly about the engine in the first place. Keep the feedback coming, tell me all I’m doing wrong!

The Component System

The core of the Ginkgo engine is a Component System. Instead of using a fat Game Object class and inheriting other game objects, we assemble Components to aggregate a game object. The main point of a Component System is to replace (especially multiple) inheritance with aggregation. Components are allocated independently of the actual game objects and assembled according to requirements. Components are vertical slices of game objects. Each one encapsulates specific functions and a specific set of data. They are updated (their update() function is invoked) in consecutive order. Our system assembles the game object aggregates from templates defined in XML. Our components are stored in contiguous pools. One component pool is updated at one update stage. Updating a component pool means that all components are updated. Thus, a game object is updated several times during one main loop iteration – part for part, component for component.

Let’s look at a typical component. The player Game Object currently consists of 9 components. PlayerController collects and manages a number of other components. PlayerStateMachine is a state machine for the player. It is used to trigger different states (e.g. flying, falling, crashed, …) and thus different player character behavior. PlayerInput is a component that translates the input of the player to specific properties. These are interpreted by the PlayerMovement component. The Box2dBody component wraps a physical body that is actually part of the physics subsystem. The Spatial2d component stores a location and orientation in space. It is written by the Box2dBody and read by the RenderManager. The SpriteRenderer sends rendering information to the RenderManager in every frame. The TickInterpolator component interpolates the draw position and orientation in order to sync the tick-based physics to the frame-based rendering.

Additionally, this player has a particle system attached that consist of two components, the system itself and a particle renderer component. The particles are stored in a different tight contiguous pool. More about that in a later post.

The Components

All components are derived from the base Component class. It stores administrative data and receives a number of events. Components are declared and defined using a number of macros. The most important one is GIN_DECLARE_COMPONENT, which declares ObjectPool and ComponentPool as friends, adds a declaration of an update() function that is not virtual but thus still present in all components. The GIN_DECLARE_COMPONENT_HELPERS are mostly comprised of shortcuts to static management information and typed allocation and free functions.

#define GIN_DECLARE_COMPONENT(className)
GIN_DECLARE_COMPONENT_FRIENDS
private:
GIN_DECLARE_COMPONENT_DECONSTRUCTORS(className)
GIN_DECLARE_COMPONENT_MEMBERS(className)
void update(UpdateStage::Enum stage);
public:
GIN_DECLARE_COMPONENT_HELPERS(className)
GIN_DECLARE_INITIALIZE

Each component has a class, a name and an internal type. By supplying the class name to the macro, we circumvent error prone RTTI methods and can still query each component for its class and type.

There are three important callbacks in each component:
- update(UpdateStage::Enum stage) gets called with a specific update stage. In this function the main runtime work of the component is done. See the runtime section below for further information on the different update stages. Update is called once per frame/tick, so making it non-virtual is crucial.
- onOwnerModified(bool added, ComponentType type, Component* component) is a callback that gets triggered once the owner (usually a game object) is modified, i.e. a component is added or removed.
- loadConfiguration(TiXmlElement* element) is a callback that is issued by the level loader. We use tinyXML for loading component configurations. We’ve initially planned to allow different initialization data, but there was no reason to implement that yet.

Component Pools

Components are stored in component pools. Each pool stores exactly one type (class) of components. It has a capacity that is specified at level load time. The full capacity is allocated once and all components are pre-initialized at that point by calling each component’s init() function.

Component classes set up their pools in static initialization methods pre-main. The pool is first allocated and then registered in the ComponentManager. The ComponentManager class is the main entry point for all component operations, allocating, initializing, updating and terminating components. It manages all pools. Once the pool is valid, the staticInitialise() function of the component class is called. This function initializes e.g. exported component properties for the GUI and component loading. The two-stage init is just necessary because the preMain() call is wrapped in a macro that always makes sure the pool is created:

GIN_IMPLEMENT_INITIALIZE(className)
void className::preMain() {
_pool = new ComponentPool;
ComponentManager::instance().registerType(&_info, static_cast(_pool), stages);
staticInitialise();
}

As you can see in the registerType() function above, the pool is created with a template of the component class. Every concrete pool object is a subclass of the abstract IComponentPool interface:

class IComponentPool
{
public:
virtual ~IComponentPool() { }

virtual Component* allocateBase(void *prius, GameObject *owner) = 0;
virtual Component* getComponentBase(ComponentHandle handle) = 0;
virtual void freeComponentBase(ComponentHandle handle) = 0;

virtual void recreate(ComponentHandle newSize) = 0;
virtual void updateComponents(UpdateStage::Enum stage) = 0;
virtual Component** getActiveComponents(u32& numActiveComponents) = 0;
virtual ComponentArray getActiveComponents() = 0;
virtual void pauseComponents (bool paused) = 0;
};

Let’s go through these functions one by one. recreate() deletes all Components in the pool (physically) and creates #newSize new ones. It is to be used at level or scene changes. updateComponents calls the non-virtual update function of all components, whose state is set to INITIALISED. All components start in state DEAD. getActiveComponents() returns a temporary array of Component* or a vector of Component* containing only initialized components. We have implemented a component-level pause function that can be called via pauseComponents().

The allocateBase() function allocates a component and returns it with the actual type it has. It calls pool->allocate() and simply casts the component before returning it. The allocate function of the pool first retrieves a new component handle. Then it sets the state of the new component to INITIALISED, sets the game object that called the allocate function as the owner of the component and calls the component’s init.

The ComponentManager

Usually you do not interact with component pools directly. Instead, ComponentManager acts as a one-stop shop for all accesses to component pools. This singleton class also manages the actual pools. The functionality of the ComponentManager is split into two areas: Its internal functions for managing the pools, its external functions for querying the pool for specific components.

The manager maintains an array of actual pools. It also stores all necessary runtime information for the pools and has preprocessed lookup functions for retrieving the internal type and the name of a component class. Most lookup functions are based on each component pool’s ComponentInfo struct. The ComponentInfo is stored as a static struct for each component class:

struct ComponentInfo
{
ComponentType type;
FixedSymbol name;
ComponentType baseType;
FixedSymbol baseName;
FixedSymbolArray requiredComponentsAtStartup;
};

The system can look up type information and name of the component class and the same for the base class of the component. It also stores a list of required components describing all dependencies of this component, should there be any. We have implemented a fail-early approach for dependencies. The other option would have been to use a visitor pattern. In that case, a component would always act as if its dependency is sufficed and broadcast messages in the hope that the required component picks it up. In our solution, the required component needs to be present once the whole list of components for the game object is assembled. Otherwise the system exits with an error.

The component manager has the ability to call all component update functions per pool. Since the data of the components is stored in consecutive order, iterating over them and invoking their respective update functions should be very cache-friendly. The update stage for each component class is set at the definition of the class via the macro GIN_IMPLEMENT_COMPONENT(className, stages). We currently support one update stage per pool but a limited number of stages in total.

Next up: The Game Loop

In the next post about the Ginkgo engine I’ll write about the runloop and how (and when) the different subsystems and component pools are updated.

It’s great to have your own tech but it also means that you have to make a lot of decisions. I know we’re building something quite experimental – and a lot of things could go wrong. I’d highly welcome feedback!

We‘re a small independent game developer. Three of us have studied computer science (actually two are still in their master studies), one is a studied game designer and one a graphic artist. That’s our small but skilled team. The company is owned by ourselves and we’re working on our own IP’s from design, production and QA to marketing and support. We’re not only financially independent but strive for establishing our own independent infrastructure. That comes at a price – our wages are far below industry average – but every value we grow is a value of our own company. The largest project in a long list of actions furthering our independence is our in-house engine. The engine is written by just two guys, Peter, the main engine architect and CTO and me, the pragmatic coder that knows all the finishing moves. We’re very different, yet we had to agree on a lot of issues before starting the project. In this blog post I’m going to describe our starting points for developing the engine. There was a recent blog post on our studio blog that detailed why we started to write our own tech in the first place.

Setting Our Limits

The first thing we had to agree on was a number of very strict limitations for the engine. We can’t produce a state of the art 3D engine with our limited budget and manpower. We formulated general requirements and decided on limitations of the engine. The main goal for the engine is to provide us with a tech that we can easily port to any platform out there. Our business model highly depends on agility and the ability to cheaply bring our games to emerging new platforms like e.g. the Mac App Store or the iPhone. So the number one requirement for our engine is portability. We’re making 2D games. While our rendering architecture would be suited for 3D content as well (more about that later) we’ve decided to focus on 2D for now. The main reason for that decision is that it is near impossible for such a small studio to provide the amount of content a 3D game needs. In other words: We’d rather deliver a highly polished 2D game than the crude and simplistic 3D game we could deliver with our limited resources. Other things that were off the list right from the start are e.g. networked multiplayer and streaming content.

The cornerstones for Ginkgo that we agreed upon are:

• An easily extensible 2D engine
• XML as the main data format
• Optimized for physics-based games
• Component-based design
• The only STL classes we’d use would be vector and string (and some maps, but we might replace those later)
• No networked multiplayer/replication

The engine would have a slightly different architecture if the main design would have been mine and not Peter’s. I’m a C programmer and I’ve mainly developed highly specialized software for art installations (e.g. talking boots and music-playing pinball machines), realtime audio and similarly one-sided areas of application. I’ve singlehandedly coded a number of iPhone games, but none of them were technically very sophisticated. I’ve had my days in the Open Source development, too. Peter is a C++ programmer, on the other hand. Where I’m using a void pointer he’s reinterpret_casting. While I think OOP is only perfectly suited for a small number of tasks (UI’s come to mind), he thinks it is the basis of good design. We’re constantly fighting over these issues and I think that’s important for our engine architecture and our design process. Compromises often lead to mediocre results, but talking things out is a very important thing.

A Component-based Core

What we easily agreed on is the component-based nature of our engine. We’ve prototyped in the component-based Pushbutton Engine (Flash) and Unity before and we knew it would help us keep the increasing number of classes with overlapping functionality that usually get written during a game project. Also, Peter had stumbled across Terence Cohen’s GDC 2010 presentation “A Dynamic Component Architecture for High Performance Gameplay”. At the same the DoD movement – and especially Noel Llopis’ take on it – was at the centre of my attention. I see the C programmer’s mindset at work and I’m pleased. Insomniac’s architecture was the blueprint for our core engine architecture.

Here are some additional coding rules we agreed on early:

• Templates instead of instancing, where it’s possible
• Never call a virtual function in a component’s update
• As little inheritance as possible

… And What We’ve Built On Top Of It

Most low-level features we implemented are based on publications by established game engineers. I’ll go through them one by one.

• Our initialization and termination methods are lifted from Jason Gregory’s excellent book “Game Engine Architecture”
• Our main game loop is designed as suggested in Glenn Fiedler’s “Fix Your Timestep!”. The paper describes a fixed timestep game loop ideally suited for integrating physics independent of frame time. It is ideally suited for libraries that request a constant tick rate, like physics libraries. We’re using Box2D for our physics part.
• Many subsystems of the engine depend on iterating over contiguous arrays of components or structs as outlined in Tony Albrecht’s “Pitfalls of Object-Oriented Programming”. Our components feature an update function. But they contain the minimally necessary data to perform their functionality and are iterated over by component pool. Our component pool architecture will be featured in a future post.
• We did not implement Marcin Chady’s messaging architecture though nowadays I think we should’ve gone for it. Instead, we access components directly if a call is time-critical or via delegates if we want a leaker link between them. Component-to-component communication will be a different post.
• Our rendering subsystem is following the guidelines outlined in Christer Ericson’s “Order Your Drawcalls”. We have buckets of arrays of faces that are sorted according to a render mask. More about that in a later post.
• Our particle system was designed according to Lutz Latta’s “Building a Million Particle System” slides from GDC 2004. I don’t know if I should write too much about our particle system. Maybe once it’s fully integrated into the engine. Currently, the main downside is that every game object can only have one single particle effect attached because the emitters are components just like the any other blob of data.

The Future Is Bright And Full Of Pragmatism

Now that you know where we started I can describe how we kicked off the project in the next post. I would also like to think aloud if the development of your own tech is even viable for a micro-studio like ours and how we manage to focus on games and develop our own tech at the same time with only one team consisting of five people. We’ve had our first user test with a prototype of our next game last friday, and it was awesome to see our engine (and the game) in action for the first time I will write about our upcoming game in the future, too, but it’s currently top secret.

If you have any questions or want me to focus on specific engine features, just tell me and I’ll gladly write about it.