The Birth of a New Game Studio,
Part One: Humble Beginnings

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