Arx Fatalis was Arkane Studios' first game, the team members had all worked together in the past, and this time we decided to create our own company to work on something very ambitious and risky but also a very exciting longtime dream for all of us: a 1st person RPG !
Not only would this represent a huge effort in term of game design and assets management, we also decided we'd make our own engine and tools, which can be a good thing, but can also be a bad thing. The project started in October 1999 with a team of 4 people doing the pre-production and a demo. 1 year later, the production started in full when we found a publisher. It took almost 2 years for an in-house team of 10 people, and an external team of 20 people to ship Arx Fatalis.

Things that went right:

A clear vision of the goals: We precisely knew what game we wanted to achieve and what elements we wanted to show. The game designers worked perfectly together. We had a long pre-production phase, we met together a lot and we had much time to think. Thanks to this, we could work in-depth on the puzzles, atmosphere and game mechanics. The game design document was well made and it provided a good development bible for the rest of the team.

An amazingly efficient team that knew how to work well together:
The in-house team was kept as small as possible, basically, the idea was to keep the creative input amongst a very small amount of people. This would accelerate decisions, reduce ego and management issues. It revealed to be a very good way to keep costs low. Obviously, this system wasn't perfect (during crunch time for example), but overall we found out that it's a really good and efficient way to manage a project. Our contractors were really great, we worked with responsible people who (almost) always delivered assets in time and quality. Then, there was a significant time that needed to be taken into consideration for integration of the externalized work (which we've underestimated a bit sometimes).
To be fair, I would say we should have hired a few more people in-house. The fear of running over the budget stopped us from hiring, but looking back at things, we would have been more efficient by hiring a few more people when the project started to run under pressure. Something I'll remember for the next game.
Anyway, where this system managed to shine was in its overall efficiency and reactivity. Here is an example: "The frame rate is poor ?… Well then, let's add some portals !" It was a bit too late when we realized that the code optimizations were not as magic as we would have hoped compare to the expected performances. So, the Lead programmer decided to implement a portal clipping technology after we had gone Beta already and as we were a few months away from Master… Believe it or not: we did it! We "portalized" the entire game using hand edited portals in only 15 days ! That's what I call reactivity in a project.
Another example: We had to rewrite the story half way down the development. The main story was written since the very beginning, but we found out in the middle of the production that there was not enough surprises and twists, so we broke it all, and tried to rebuild the most interesting plot as possible: What turned out to be hard was to keep the elements that were set in stone by the work we had already done such as puzzles, characters, level designs, etc... That was quite a nightmare and a very interesting exercise at the same time, as we had the feeling of working in a reverse way. But as strange as it might sound, it also allowed us to end up with an interesting complex story that we could probably have never written if we had done it the 'right' way.

Game Scripting, AI: One of the things that revealed to be good when making our own engine is the fact that we could adapt the production tools and game functions according to what the game designers really needed (beware, this can be dangerous for the schedules!). One of the Lead Programmer's good ideas was to provide us with an event based script language that was used by the game designers to script anything that was in relation with behaviors of Objects, from a simple mug, to a goblin chasing a mouse, or item combinations. All in all, bugs aside, it has proven to be a great method because the game was made by the designers who always tried to fit a new fun idea, not by the programmers who haven't read the game design documents. Also, this method is extremely flexible and great for fast game tuning, I really recommend it to anyone, the only downside is that it requires Game designers who are 'technical' enough to be able to script events and behaviors.

Real-time Cinematics and dialogs: This is something that could have turned into a disaster, but for some reason it went quite well: We totally underestimated the difficulty of the task, we had absolutely no knowledge in the film industry, we didn't do any Storyboard for our cinematics. We did many things using our intuition: camera placement, zooms, close up, etc… and it ended up working quite well, though more knowledge of basic rules would have helped. I guess we've been lucky ! Next time we'll hire some storyboard artists for sure :

Things that went wrong:

A big waste of time with the text writings: On the Script writing side, I think we did something quite uncommon that wasted a lot of our time: Though we are a French developer, we decided that the primary language for the game would be English, mainly because the big part of consumers speak English, and also because we thought it would be better when showing the game to publishers. So, we started writing our internal docs in English. Well… in something that looks like English written by French people. Later on, once we had all the dialogs and the texts written, we contracted a French writer who's job was to translate our strings, and most of all: adding some style to our dialogs and books. Once the job was done, we were a bit disappointed with the style that was too 'written' and not 'talked' enough, so we spent some time modifying some strings that we didn't like. Then, we sent them to translation into real English (there are many companies who are specialized into game translation). Once the English texts game back to us, we started to waste some time correcting all basic mistakes made by the fact that the translators didn't know all aspects and elements of the game (standard issue). Then, when we sent the scripts to the recording studio in the US for speech recording. The guy sent me a mail saying that many strings were really 'naive' and bland in the writing for this type of dark serious game. So, we contracted an American to give a bit of 'punch' to our texts and dialogs. The texts came back to us and we were happy with them. But then we had to re-affect all the changes on the French strings that were already written ! And only then, our nightmare did come to an end: Texts were finalized and ready for German and Italian translation. Next time, we'll get a native English to write our texts from scratch.

We probably didn't choose the most adapted tools for Level Design: The initial technical goals that were defined between programming and game design were not ambitious enough in some areas: For example, the jump and crouch features were not in the plan, as they seemed useless when we started the game design. Later on, we decided that we couldn't afford not to jump and crouch in a 1st person game, so we had to change many areas to include these elements (somehow we failed to integrate them as well as I would have liked). Also, we initially agreed that the game world would be based on elevations (no room above another), so the level design was very 2D like, everything was designed from above, like for a pen and paper RPG. Later on, when we blocked out the first 3D versions of the maps, we had a feeling that everything was flat: We definitely couldn't ship a game only based on elevations, and not in 'real 3D'. So we started redesigning areas, and modify the meshes with the 3D modeler. The problem is that usual 3D modeling tools are not very good for game designers compared to known 1st person shooter dedicated CGS (constructive solid Geometry) tools such as WorldCraft, Unrealed, etc… Most game designers don't want to think in terms of Polygons and textures, they prefer the intuitive volume editors provided by classic first person games… and they are right !! This is also the time when we realized that we were lacking experience in 3D world designing…
Most 1st person games use CSG editors, and that's not an accident. It is definitely the most adapted tools for game designers to conceive worlds in true 3D. The drawback is that maps appear usually a bit blocky and 'geometric', but the solution might be to use the CSG method only to block out maps, then export the mesh to Maya or Max so that real graphic artists can work on it.
Anyway, once we finally managed to rework the basic meshes to reach a level of 3D that was good enough, we handed them to the Graphic department who's task was to change our horrible blocky maps into something immersive and pretty.

We had only 1 programmer for 1 year doing it all: That's wrong ! probably because of the lack of budget, we chose to stay with one programmer who would start from scratch, just with the compiler and DX7 !!
One guy alone had to work on the tools, the engine, the pre-production, together with making a cool tech demo to seduce publishers…
Well, he did it ! we had a tech demo which was pretty advanced and convincing… But then everything should have been scrapped and redone in a clean way if we had done things right.
Instead, we inherited a rushed engine that was used for the prototype. As a result, the entire production was built upon a dangerously heavy base that didn't always feature the right decisions, and new programmers found it difficult to plug their code in. Most additions would cause bugs and crashes and would require some heavy debugging time. Probably all this was due to the fear of being late. Anyway, at the end we managed to obtain a code that was stable, but at the cost of loooong extra hours and stress.

Underestimation of the Play Testing task: We assumed that the testing made by the publisher would be enough… Unfortunately, we've discovered that remote testing and debugging doesn't work very well. The tests made by the publisher are good for language testing, quality insurance and hardware compatibility, but the rest needs to be tested in-house. This is not something we had included in our initial budget, but we hired 5 testers in-house for about 4 months in order to accelerate the testing procedure. Still we didn't find all the bugs (the game being so big), and it took a few patches to remove them all.

Raphael Colantonio
CEO / Lead Game Designer