In the old days, crafting computer games involved a few thousand dollars, and one or two guys writing tight code in some dark, tiny room. Today games have become extremely sophisticated pieces of software crafted by large teams with multi-million dollar budgets. Game companies have left the tiny, dark rooms worldwide and some of them have entered the stock market.

Exactly one year ago, after our first visit to the Game Developer's Conference, we decided to take the big leap, and founded a new game studio in Barcelona, Spain. We had been interested in the industry for years, and GDC 2000 was the spark that helped us make the move. As you can imagine, we are not EA or id Software... at least, not yet. We really began moving in early September, and just recently we have reached a stable status. Still, the last year has been a crash course on teamwork, finances and project management. We have faced problems that the big players wouldn't even notice, but which are certainly familiar to other newborn studios. Now, we are coming back to GDC 2001 with some working code, some nicely done art, and great expectations.

Before we attend GDC for the second time, we think it might be a good idea to tell how our development studio was born, and the problems we found along the way. By telling our story firsthand, we can become an example to others. If it all works out, and our titles hit the shelves sometime soon, the series of articles we are starting today will become a useful reference to industry newcomers. If it all goes wrong, the value of these articles will be even higher, as an example of what can go wrong.

The first entry in the series will provide some background information: market research, teamwork and product design and architecture. Future articles will focus on industry events, technology, art, and more. The road ahead is long and winding -- let's get started.

Background research

Creating any kind of company is always a complex adventure, and some advance planning required. Does your idea really make sense from a business standpoint? Will you eventually make a living out of this? Many companies start just out of pure enthusiasm, quite logically in a creative industry dominated by young professionals. Still, we think it is a good idea to dedicate some time to write down the formulas that drive the business, and get a broad feeling of what we are really doing. Later on, this base research can be helpful when the time comes to make important decisions.

In our case, our first discovery was that games work more or less like books (I was lucky to know the book business from some past project). There are two parties: the writer and the distributor. Writers work on a royalty basis, getting more money as sales increase. The big difference between books and games comes from the fact that games take several people (and maybe more time) to create. The average game can take no less than 25 people working 18 to 24 months. So, paying these big teams until the royalties arrive seems a big issue. Luckily, we saw that advance payments can be negotiated with the publisher, to make sure everyone is OK until the game ships.

The business model for a retail game can be grossly expressed in the following terms: leaving taxes aside, the distribution channel (Electronics Boutique, Media Play, etc.) gets about 50 percent of the total price. The other half is divided between the developer and the distributor. The statistics here may vary, but the developers seems to get between 10-25 percent of the total depending on the risk and appeal of the title. These numbers are usually decided depending upon the developer's track record (less royalty for new companies, logically) and projected sales. So, getting a good deal is more or less like getting a loan from a bank: the more reliable you are, the better the conditions.

While researching this we also discovered that a successful title sells about 350,000 copies, and only a few games go beyond one million units. Top-of-the-line games such as Final Fantasy for consoles or Myst for PCs go way beyond that, selling in excess of 6 million units each. Sales seem to depend on how good the game really is, and can also be deeply influenced by the marketing used to attract the audience. Choosing a good publisher is a must: if you do some pretty basic math between costs and sales (and considering the percentage the developer gets) you will discover that the break-even point can be between 100,000 and 250,000 copies sold.

As we are based in the sunny Barcelona, Spain, we also did some research on our own country's potential. We learnt that Spain has a market penetration of PCs of about 20 percent (versus 50 percent in the United States). Although this is quite disappointing, the main problem in Spain is software piracy which, depending on the source you listen to, ranges from 50 to 70 percent. In any case, this is definitely not good news for any new game studio wanting to make a living. Finally, we found out the very important fact that a AAA game sells about 100,000 copies in Spain. Thus, creating a studio only for the internal market does not seem to be a wise move: under optimal circumstances you will barely reach the break-even point, and never pass beyond that. All this analysis led us to decide to give the company a global focus, and declare that exporting is definitely the way to go for us.

One might ask why we start a company in such a hostile environment. Spain does not seem to be a good place to sell many games. Well, strictly, that is true. On the other hand, maybe it can be a very good place to create them: production in Spain can be significantly cheaper (about one third less) than in higher-cost countries such as the United States, while return on investment will be the same. In other words, salaries and fixed costs are lower here, and theoretically, the game will generate the same return as if it was done in one of the more expensive countries. That's the same reason why some big-budget Hollywood movies are filmed outside the United States.

Also, Spain has a long history as a videogame producer. In the early 80's many companies emerged, and made Spain one of Europe's main game producers. Now, the tradition lives on with companies such as Pyro Studios (Commandos: Behind Enemy Lines) and Rebel Act (Blade of Darkness), both selling quite well worldwide. The main problem for the Spanish industry has traditionally been a lack of investors willing to take the risks involved with such projects.

So, our research results show that we need to sell between 100,000 and 250,000 units to become profitable, and that the exact number depends on the negotiations with the publisher. As the break-even point cannot be reached by sales in Spain alone, the company has to start from the very beginning with an international focus, trying to reach a worldwide audience. This simple formulation has helped us a lot to focus our vision.

Product design

The vision I'm referring is, obviously, the game. Much has been written on specific techniques and algorithms: we can tell the difference from a BSP and a DSP, and we know all about threads. Still, good articles on creating successful games are hard to spot. An exception to this is the excellent Designer's Notebook series by Ernest Adams here on Gamasutra, but most gaming web sites concentrate on the technology, and forget that it's the gameplay which really sells games. Assuming that a game is basically a form of entertainment, technology has to be seen only as a medium (and maybe a good way to generate some good'ol marketing hype).

So, we set out to design our game. As we are in a really early state, I'll not give any specific details here (I would infringe my own NDA… rather bizarre). For now, I will focus on the method we followed to put our ideas into practice, and get a first design draft ready. To do so, we used our own homegrown technique of dividing the problem into choosing a theme and choosing a treatment.

Theme

There is much more to selecting a good theme than choosing a cool setting. For some reason, there are themes which seem to be inherently more attractive to game developers than others. Ancient civilizations, space stuff, secret agents, or anything that has to do with paranormal activity seem inspire more games. On the other hand, games about everyday people (with emphasis in lawyers) do not seem to move the gamer community.

The reason for this is that a large part of the gamer community has, at least in part, a shared cultural background. Most of them are between 16 and 35 years, and the references absorbed from movies, books and other media are somehow similar from one gamer to the other, and this reflects in the preferred game settings. Asking for the top-10 movies in this group of people will definitely show some nice patterns. A deeper study of this topic recurrence can be found in Ernest Adams' article on Dogma 2001.

Still, choosing a theme involves more than giving the average gamer what they are expecting. The gamer community is anything but homogeneous, and by choosing your subject you can be expanding or limiting your audience. We will see later on that choosing a treatment can be more limiting that choosing a theme, but still themes are what you see when looking at a game box in CompUSA.

Our decision here was to follow our instinct, and choose something that sounded exciting but not many games had been written about. We wanted to avoid "me too" ideas, like building another RTS, FPS, or anything like that. Breaking new ground might seem risky, but entering a theme area with lots of competition and successful franchises doesn't look much safer.

Treatment

What will really determine the success of your game is the treatment; the way in which the theme is applied in a certain gameplay style. As an example, take a look at Independence War, by Particle Systems and any Wing Commander-style game. Both are space war games, both are mission-based, both are seen from the cockpit. Still, the way both games play is extremely different. Iwar was a great simulator, with all the realism a hardcore sci-fi fan expects to get. Wing Commander, on the other hand, is basically a proposal about fast & furious gameplay and action. Sharing very similar themes, both games had a radically different treatment. Clearly, the treatment you decide will determine the appeal of your game to certain audiences.

Treatment basically comes in two flavors: interface and interaction design. When designing the interface, you can go the hard way and craft a game that comes with a 600-page manual and requires 70 keys to operate, or try to approach the classical console simplicity and stick to 4 cursors, 2 additional keys and almost no manual at all. While the first type might be appealing to many people (flight-sim fans being an obvious group here), it's on simple, intuitive interfaces where the larger part of the audience likes to stay. People playing games prefer to learn the game than to spend hours studying its interface. Taking a look at the sales figures will show you that this fact can be considered as quite well-proven.

Still, there is more to treatment than the interface. The way you lay out your levels or game world will also influence the way people play. For example, in a game such as Diablo you cannot walk more than ten yards without encountering some grueling monster. Baldur's Gate, while sharing a similar screen layout and interface, features many empty areas to wander around. Clearly, you can design your game so that the rhythm is higher or lower, or varies from zone to zone. An excellent example here are Quake II and Half-Life. Both games share the same graphics engine, viewpoint, and interface. Still, one would think that Quake is faster-paced that Half-Life, in which the backstory is more important.

Interaction treatment is not as easy to get right as the interface treatment, largely because there is no written formula. Still, our decision was to try to blend the action and rhythm of a console game with some quieter areas found in classic adventures. The method we use to explain this is what we call the Disneyland Metaphor, and would really deserve an article on its own. If you consider it, amusement parks are structured in a series of "rides", or active areas, and "scenarios" or passive areas. In the rides, you experience fast action, sometimes actively (for example in a shooting gallery) or passively (in a rollercoaster). Then, as you get tired, there is no need to rest in a boring place: you can go to a scenario, where you can see shows and live acts and relax while keeping the fun factor quite high.

If you think about it, only some of the rides found in an amusement park are challenging. Riding a rollercoaster is definitely fun, but you are not demonstrating any skills (apart from courage). The same way, we believe that not all the gameplay in a computer game has to be about the player passing a hard test (beating a certain enemy or whatever). In our opinion, the continuous challenges proposed by many computer games should be blended by other forms of action which are fun, but really do not require you to master a certain skill. This fixation with competing and winning is quite specific to computer games, and probably goes way back to the arcade days when people paid per-game and putting players under pressure was required for the company to make money. Still, if you look at entertainment in a broader sense (toys, sports, etc.) you will see that competitive entertainment is only a tiny part of the cake. Kids playing with LEGO bricks or action figures cannot be said to be competing. Still, they are having a blast.

Thus, our treatment is to combine active and passive areas so that all of them are fun, but only some of them are competitive. While this might seem unattractive to some hard-core gamers out there, we believe that maybe getting ideas from places such as Disneyland or action figures, both being huge businesses, might be a good twist to approach a wider, more casual audience.

With our theme and treatment all set, we got a working plan on what we were really going to do. We started coding in October, so we had about five months until GDC, and lots of ideas. Still, we soon discovered that talking about "what" to do is easy. Problems usually appear when you try to decide "who" will do that.

Teamwork

I've spent most of my professional career in the online/portal business. My last position was a portal comprised of about 5,000 web pages and 25,000 files, with business in six countries. The portal ran on 15 servers, and involved no less than 20 technicians. Still, managing such a project involved little more than assigning tasks to people, much like issuing orders to a small army: programmers worked in parallel, and little or no interaction happened between them. The same applied to graphics designers, and the only collision points between the two teams would be agreeing in which files were to be put in which server and folder. Game development has proven to be more difficult, as the interactions between people are richer and more complex. The different team members have to work together, and dependencies between their respective work often appear. To make things worse, our team has not worked in a single location, but remotely and coordinating through the Internet with tools like ICQ and shared virtual hard drives. Although very interesting as an experience, this has only added additional headaches to the expected ones.

A good example of this complexity is the flow of work (and data) required to build art into our engine. In our system, art is integrated into the engine as soon as the 3D mesh is built. This way we can do performance tests, and also get the physical scale of the objects right (this last item is much easier said than done, really!). Thus, artists need the engine code to be available and working properly. Moreover, some format or mechanism to feed the art into the engine code has to be agreed upon: how will models, textures, and maps be exposed to the engine?.

Once all this is planned, art is crafted: first as concept drawings which are individually discussed and agreed upon, and then beautifully 3D-modeled. The resulting data has to be somehow integrated with the engine with the mechanisms designed beforehand. As you have seen, many tasks are sequential and dependent upon each other. In fact, this chain of commands is not perfect and will break sometimes, as bugs in the data formats, engine or art are discovered. To make things worse, similar problems appear inside the coding team. Clearly, some strategy was required to work things out.

Getting a team

Assembling a good team is probably the hardest (and more important issue) you'll be facing when creating a game studio: finding a capable and motivated group of people who share a common vision is, to say the least, hard. For us, the process went better than I expected, and we were able to complete a team consisting of four full time developers in record time. The roles assigned within the team were: one person acting both as game designer and programmer, a technology programmer, a concept artist and a 3D modeller and texture artist. That's not much compared with the typical 25 person team, but we were still able to create something quite nice and good looking.

The team was assembled around the designer (yes, that's me), who knew some of the other team members beforehand, and had to look for the others. Being a teacher in a multimedia school, getting a good programmer was not really much of a problem. Besides, technical schools in Barcelona and all over Spain are quite good, and talent is available. Art, on the other hand, was really difficult. Arts schools in Spain are quite biased towards traditional art forms (painting, sculpting, etc.) and there is an evident lack of digital artists with the skills required to get the job done. After lots of sweating, we were able to find a very talented concept artist, coming from the cartoon industry. He had no game development experience, so his ideas were fresh new and clean. Seen in perspective, this was a great decision, as we can raise the bar and really go far out in terms of graphical quality. Finally (and too late in our schedule), we found a 3D modeler with skills in low-poly modeling, which was our primary interest. We had contacts with many modelers, but the vertex control required by our project was really high, so we had a really hard time until we found the right person. Then, it was time to decide who did what: time to create workflows.

Design workflow

For this first process, we did some research on how design was being done in other companies, and came with our own philosophy based on the paradigm of enriching the vision. Under this model, one (or more) people are in charge of the initial creative energy, which is then freely enriched by the rest of the team. The person doing the initial design must keep it short and simple: in our case, this design was basically choosing a setting for the game, and sketching the gameplay and graphics line. From this moment, creative control is shared with everyone, with the initial designer acting only as an "idea collector" and moderator. In our project, much of the technology and art has been directly designed by the programmers and artists.

We chose this method because, while controlling the process from a central design team, it exploits all the benefits of working as a group doing mindstorm sessions. Having an established vision helps to focus the team's talent, and their contribution then is really significant. We were lucky enough to find an initial vision that excited everyone in the team, so the core game pleased everyone. Then, adding elements on top of that was just a matter of letting the teams' talent run free.

As a proof of this method in action, I'll give an example. Early on, when we began working, we decided to do a technology demo showcasing our ideas. The demo was to contain (among other items) a palace, visible both from the outside and from the inside. Below you can see three images that clearly illustrate the "enrich the vision" process: the designer's view in the left, the working concept in the middle, and the beautifully modeled artwork to the right. As you can see, my role as designer was only to sketch out the shapes. I only detailed those parts that would affect the gameplay later on: number of stories, size, global style. Going beyond that would have been a mistake, as I would invaded the creativity field of the concept artist. As can be seen, the final version preserves all the structural elements, while going way beyond in terms of visual quality and appeal.

Three images that clearly illustrate the "enrich the vision" process.

Data workflow

All games (except for rare exceptions like Tetris) involve huge amounts of data. In fact, the relationship between code and data in terms of size can be as extreme as 5% to 95%. In our example demo, the executable file is about 500 Kb in size (we do not use any resources embedded into the EXE file), and the total data is about 60 Mb. Thus, the data production-and-integration pipeline must be clearly laid out, to avoid redundant work.

Basically, by planning the data workflow a company defines the relationship between the technology and art teams, which boils down to deciding who will take care of what. It can be a good idea to analyze the abilities and weaknesses of your specific team to help you make these decisions. In our case, for example, we were all capable of using mainstream 3D and 2D art tools. Still, only the truly technical members of the team were programmers. It made more sense for the technology people to enter the art arena than the other way around. For this and other reasons, we decided that, upon designing the game engine, the technology team would define the internal art formats to be used. As both programmers were art-sensitive, the decisions taken made sense to the art team.

Similarly, it was decided that art would be inserted into the demo by the technology people. The reason for this is rather complex. Like many teams, we started coding the main engine and underestimated the time required to then build the art into it. Later on we had our art team working in a perpetual crunch-mode, while the engine code was basically stable. Thus, the technology people had to get some work done on the art front to ensure all the work was ready on time. In our case, we were lucky to be able to solve this issue because both teams know modeling. Still, this is a lesson to all teams out there: crafting art is a slow process. Plan ahead or prepare for disaster.

The last decision to make was the graphic look of the game. You can see a clear example of the evolution in the art below, which depicts how a riverboat concept evolved, from a first cartoonish version to the final, dense and overwrought drawing. Some companies use concept art only as a medium for modelers to get the idea of what to model. Others consider them as a legitimate art form, and use them also as promotional game tools. We clearly are part of the latter, as we think that good concepts can not only showcase the art quality, but also the mood and feel of the game. Moreover, good concepts can be used to help focus the vision of the team: having them running around the office will help not only modelers, but also programmers and designers to immerse themselves in the game world early in the development process, and thus create a superior product.

A riverboat concept evolved from a first cartoonish version to the final, dense and overwrought drawing.

 

Lastly, we decided to follow the typical KISS (Keep It Simple,Stupid) principal: we stuck to popular, off-the-shelf applications, and used common data formats. Making games is complex enough, there is no need to make things worse using arcane tools. The only exception to this rule was our texture file format. Our engine relies heavily on multipass rendering techniques via OpenGL, and many times ended up doing weird things to the texture's alpha channel. Thus, we decided to encode textures in a proprietary format. This involved creating a small command-line tool to create the files. Other than that, we stuck to mainstream tools widely available. We plan to expand our tool library to include a full-blown editor to create levels from the artist's perspective, but obviously this is a task way beyond the throughput of a two man programming team.

Code workflow

The final and most complex workflow was the one taking place in the core engine. Our technology today consists of about 200 C++ files, totaling well over 50,000 lines of code. It was written, from scratch, in five months by two people working remotely, so keeping in sync was a major issue. Frequently, one of the programmers would work on some new feature, which would have unknown side-effects on the other's work. Two strategies were established in order to fight this.

First, we followed a hard-core object oriented approach. In our whole code base, only one file was not a class or object, and that one was the file containing the main program routine. Apart from that one, all functionality was encapsulated into classes and, when required, higher-abstraction design patterns. This required the development team to spend some extra time discussing interfaces and methods. Still, the benefit was clear, as once the interfaces were stable, changes could be made to the innards of some subsystem and the overall impact would be reduced.

The second decision was an architecture based in micro-kernels and external subsystems. The idea of micro-kernels comes from Operating System design, and consists of having a lightweight piece of code acting as a kernel dealing only with base engine functionality (window management, events, and base types), and to implement all remaining functionality as external subsystems. These subsystems can be added, deleted or modified with little or no problem. In our engine, the core package would include vertex, color, camera & texture handling, and the rest would be implemented in more or less autonomous packages. A good example of this is our character animation module. This module is quite big, consisting of about ten classes with deep semanthics built into them. Our system is designed to animate seamless skinned skeletal models with props. Still, we can activate or deactivate it easily. In fact, we can separate that part of code from the rest of the program, and thus treat it almost like an independent entity. Similar results could easily be achieved by using a CVS-kind of system. Still, in our first months we did not have such a tool available, so some discipline was required from both coders to achieve the same result. As our coding team expands, the urge for a CVS such as Visual SourceSafe will increase, as more programmers also mean a higher possibility of a major disaster in the code.

Epilogue

After much discussion, coffee and sleepless nights, we finished our first demo or, at least, we have something we can show and talk about. This week, we will go to San Jose, California, to take part in our first Game Developer's Conference as a company. We won't really be showing much, as we are still in our infancy and everything is quite primitive and in an unpolished state. Showing unfinished work is a good way of causing a bad impression, so we are going to play it safe. Still, we know that these events provide a concentration of ideas and people that makes them the right place to make contacts, publicize your work, and learn new techniques. I have attended four Siggraphs, one GDC and countless e-commerce trade shows and have always returned with fresh, new ideas.

In this first article, we have seen how a little planning and serious teamwork can produce results, even with a sub-minimum team and infrastructure. In the next issue of this series (significantly titled "Goin' Places") we will be covering our stay at GDC 2001, the conferences, people and expo. We will try to show how game events like this can help a newborn developer. We hope to have some new experiences to share, and lessons learnt along the way. See you then.