Auriea Harvey & Michaël Samyn 8 PROTOTYPE ALPHA 1 PRESENTATION OF 9 OCTOBER 2002 Jan Van Eyck Academy, Maastricht, Netherlands A little history of the game demo design project so far...

Entropy8, Zuper! & Entropy8Zuper!
From 1995 to the present, Auriea and Michaël have been making interactive websites with a focus on trying to create a feeling of "being in" an environment. In a sense, we were trying to fake what can be done for real with real time 3D software. The main reason why we did not make the step earlier was that there was no software available that we could learn how to use and there was no budget (and probably no talent) for learning C++. Other reasons were that we felt very comfortable on the world wide web, which at that time still held a lot of promise of undiscovered potential. A concept that has been largely ruined by the commercialisation of the internet.

Pornography
In 1997, Michaël wrote a threaded narrative scenario for a pornographic CD Rom, figuring he could make a quick buck after having seen Virtual Valerie 2.
He then spent a whole year on trying to model and animate a human character with an application called Hash Animation Master. These models -Johny and Mathilda, two of four neo-porn evangelists- were only used in the "Zuper! 7 Interface", launched in July 1998.

Al-Jahiz
In December 2000, we conceived Al-Jahiz, a 13-part narrative episodic comissioned by Lifetime TV. The project was cancelled but we learned a lot from it. It was a large scale project that was in essence a game based on a narrative. The interface was a similated computer desktop of an auction company terminal with an email client, a browser and a webcam of an employee available to the user for inspection.
We learned that we were not very good at coming up with stories and that a well written story was essential for this type of environment. We also learned that we enjoyed dropping narrative elements in the environment and letting the user figure out the connections between them.
This was one of the first projects in which we explicitly expressed our love of Persian culture.

Eden.Garden 1.0 is released
Comissioned by the San Francisco Museum of Modern Art, this is the first interactive 3D piece we made. It acquainted us with the concepts of 3D game design, motion capturing and 3D Studio Max.
Eden.Garden is an alternative web browser. It goes to a web page, parses the code and represents it in a virtual Garden of Eden. Some code elements show up as trees, others as animals, etcetera. The motions of Adam and Eve are triggered by the letters of the text on the page, each letter corresponding to a motion. These motionsets were copied from Quake 3 and include motions for fighting, running, jumping and dying.
The technology used for this project was Pulse 3D, a powerful engine with a lousy editor and a silly licensing system.

First ideas about making a game
A document from that time clearly outlines some of the elements that are still high priorities in our current design: no violence, a smart camera, the idea of a relationship with the main character that is more complex, the idea of making a series of small games rather than one big one, no photographic realism, the realisation that the game happens in the head of the player (we just give the player elements to fantasize about).
At that time, the games that we thought most about as influences were Tekken 3 and Tomb Raider. Tekken because it gave us characters about whom we fantasized stories (like playing with a doll house) and Tomb Raider as a game which stressed exploration of the virtual world rather than the more literal games of sports and violence.

One of the ideas we dropped was building a system that would allow the world to develop spontaneously according to certain rules. We later decided not to do this because we realised that there were a lot of more fundamental concepts of real time 3D that we still needed to research and make decisions about.
At that time we had not decided whether our game would be in 3D at all. From our experiences with Eden.Garden, we had learned that 3D was incredibly complicated and we were afraid that we would lose focus. Ultimately we decided against 2D because we thought that it might be a dead end street (something we had felt when launching Numbers) and because 3D felt more intuitive for us, it felt like really making something rather than simulating it.

At that time we were still thinking of our game as a console game. We loved our Playstation and found it's gamepad interface very agreeable. Also, a console game is played in the sofa in a living room. Not at a desk in an office. We knew that it was near to impossible for independant designers to get their hands on the necessary development tools, let alone that we would have the know-how to use them. But we figured we could make the demo on a PC and the final production for a console. Later we realised that the interfaces for both were too different. The PC usually only has a mouse and keyboard and the PC user tends to sit much closer to a screen which usually has a much higher resolution. Also, the PC player plays alone, not together with the other people in the living room. Since we only had access to PC-based development software, we decided that we should optimize the game for PC use. This has had serious implications, especially in terms of navigation. We had to find a PC-alternative for the comfort that the gamepad with it's dual analog joysticks offered.

First ideas about making "8": Sleeping Beauty, the little girl, the situation
Aware of our talent of interpretation of existing stories rather than the invention of new ones, we decided on fairy tales as a never ending source of good story lines. This may have been partly motivitated by our desire at the time to make a game that would be accessible to both children and grown ups in which the difference between the two would be a difference of reading: the adults would read the symbols differently than the children and only to them, the story would reveal its implicit sexuality, violence and horror.
Another reason for using a well known fairy tale was that it provided an immediate "hook" for the player. When a Western person sees a palace full of sleeping people that is surrounded by a forest of thorns, it is very likely that he or she recognizes it and immediately calls to mind parts of the story related to that scene. That recognition will pull him or her into the world instantly and as soon as he or she is there, we can start playing with those ideas.
In the same meeting we drafted the first concept of a little girl entering the palace of Sleeping Beauty halfway through the spell: with all other game characters asleep. The idea then would be that the girl would discover "the truth behind the fairy tale". We did not realise at that time, how many versions of this fairy tale there were and how different they were from one another.
Since we wanted to experiment with the ambiguity of the relationship between the player and the main character in a game, we invented a character that would be both cute and eerie: a deaf mute girl in a pretty white dress (whose looks are based on an old photograph of Auriea). At that time, also, we decided that the player should be able to change the environment somehow as we thought that the ability to be creative in a game would keep the player interested.

The game world's map at that time was to consist of a series of concentric circles in the middle of which would be Sleeping Beauty, surrounded by her Palace, a mote perhaps, the magical forest, a large flax field, a river and mountains. One of the ideas was to have the field be an internet based meeting place for players.
We had decided to make a demo of this 3D game with Shockwave 3D either by learning the skills required or by hiring people to work for us.

Blender
We discovered Blender as a perfect tool for us to make our demo:

1. It was an all in one package.
   One and the same program would allow us to model, texture and animate our assets and program the game logic.
   
2. It was very cheap and did not have an arcane licensing system (read: it was not American...)
   
3. It worked or would work on Windows, Macintosh and Linux, both offline and on the web.
   
4. It's interface was very well designed which made the program easy to use.
   
5. It was extensible through the use of a non-proprietary scripting language called Python
   All these features would enable us to make a complete demo of our game ourselves. The only price to pay would be performance: Blender's real time rendering engine was not very good. It could only render so many polygons per frame. Polygons are the triangles out of which all elements in a real time 3D world are made. The early Lara Craft model in the first Tomb Raider games, e.g., consisted of about 500 polygons, while the models used in current games often exceed 4000 polygons. But we decided that there was a lot of research to be done that did not require high-resolution models.

Design of palace starts
mixture of Palladio, modern villa, Morrocan city & Asian Pagoda

The story of Sleeping Beauty is most often set in a medieval castle. We did not want to do that mainly because medieval castles are such a cliche in games. Every game that does not play on a far away planet seems to take place in a gothic castle. Furthermore we had discovered that the roots of the fairy tale might very well be even older than the middle ages. And more importantly we came to understand that it is in the nature of fairy tales and their oral history that they change and mutuate over time. In that sense the bastard version that Walt Disney based on the already handicapped versions of the brothers Grimm and Tchaikovsky is a perfectly acceptable continuation of the age old oral tradition.
First of all, we decided that it doesn't make sense for a story like Sleeping Beauty to take place in a cold castle. With the lifestyles demonstrated in the fairy tale, it would make much more sense to put it in a luxurious palace. This immediately made us look towards the renaissance rather than the gothic era for examples of architecture that we could use. Palladio turned out to become very influential, not in the least because he had written books in which he explained in great detail how to build those beautiful luxurious villas and palaces. Not being architects ourselves, learning simple things like the measurements of stairs or the slope angles of roofs, was extremely important.
We did not, however, want our game to be set in a historically accurate world. Especially since the concept of time itself is played with in the 100-year spell that takes place in the story. We wanted to create an environment that could not immediately be dated on sight. And we did not want our game to be set in Western Europe either, but rather also in a non-specific geographic location. So we started looking into Asian and African architecture styles and through Islam architecture, we discovered a great solution in orientalist painting. The scenes displayed in orientalist paintings were almost perfect for our game. They took place in rich environments in which most people were either sleeping or resting. They also demonstrated a more or less timeless atmosphere: the architecture had its roots in ancient times while the style and subject matter betrayed much more recent Western concerns. The light in the paintings was also something that we could see as a great inspiration for a 3D world. Furthermore, one of the versions of the Sleeping Beauty tale, can be found in "1001 Nights" and may have very old Eastern roots.

But more than the style of orientalist paintings, the concept of cross-geographic and cross-chronological ecclecticism was the perfect solution for our timeless, placeless world. So much that we even decided to play with it by having the 8 princes that break into the palace come from different times, each of them bringing their own customs and technology to the game world.

Proposals VIZO prototype sponsoring & Rockefeller Fellowship grant
Auriea was nominated for a Rockefeller Fellowship of $35000 and we decided the submit the game as her proposal. VIZO in Belgium was also offering prototype funding mainly aimed at furniture designers. We requested funding for the prototype of our game.
It was at this point that the two phase plan came into being. We were going to seek non-commercial funding for the first phase of the project which would consist of the design of the complete game and the production of a game demo. With those two things in hand, we would then try to find commercial funding for the production of the actual game. The reason why we wanted the first phase to be non-commercial is that we considered it to be a research project. We did not want our research to be hampered by commercial considerations and we wanted to reserve the freedom to fail, which is an essential aspect of all research.
Despite of the fact that the Rockefeller jury did not award the proposal, simply writing it along the guidelines offered by the Foundation, has been a great help in defining what we want to make and how we want to make it. As of then, we have regularly taken the time to write down things about the project. This has always proven to be a great time saver because it allows one to evaluate and draw conclusions much quicker than during creation.
Even when programming, simply writing out what you want to achieve, is very beneficial. It allows you to spot and correct logical errors and streamline your system before any code was written, thus saving enormous amounts of time spent on debugging.
The same goes for creating assets like characters and models. Rather than willy-nilly producing models that may be of use here it there, it is much better to write out how a scene will look and what elements need to be produced for that. It is also much easier to estimate the time frame required to produce these assets with a descriptive text in hand. And since modeling is a process with which one could easily fill many lifetimes, scheduling is crucial.

The Kiss, Incorporator is launched
Comissioned by the Korea Web Art Festival, this was a web based real time 3D environment in which the user could fly a camera through a pulsating 3D scan of our bodies kissing. It was made in Blender in less than a week.

Guernica is launched
Guernica is a web based internet data client. It analyses and parses data coming from an internet source en represents it as 3D objects in a realtime virtual space. This space consists of a globe upon which running tires, pumping oil rigs, screaming women, business men in suits, Dollar bill cubes and airplanes appear in a film noire like grey scale palette. There were two clients made: one for Alex Galloways' Carnivore server and one that analyzes the CNN homepage. The world was created with Blender and the online data connection with Flash.

Paradash is made
This project was comissioned by D-a-s-h but was rejected due to problems with usability. It was from this issue that we learned the importance of early user testing. We had developed an interface system that was very efficient and easy to use for us -who had been working on it continuouosly- but it turned out to be completely arcane for our client. Also, this project was done in a rush (one very intense week) and it taught us that that is not a good idea: time is require to let things sink down and to reconsider them.
Paradash is a game in which the player steers a little Kingfisher Bird through an icy world consisting of four small islands. On these islands, strange tree-like structures grow, a different one on each. These trees drop seeds that the Kingfisher can pick up and bring to another island. Dropping them there causes cross-fertilisation and makes the tree look more diverse.
This application was made with Blender.

Numbers is launched
Part four of our series of websites with interpretations/appropriations of the books of the Bible. Despite of the fact that we had trouble to achieve the right tone and put together the right content for this piece, designwise it provided little challenge. We were very comfortable with the format already established by the previous three books and knew exactly how to do certain things. This combined with the frustration with the performance of Flash, the technology that we used, stimulated us more in our desire to try something different.

Jobs: Mosex corp site

Attempting to write a scenario

Interview at Jan van Eyck (13 Feb)
We went to Maastricht to present our project to Koen Brams, Jouke Kleerebezem and Filiep Tacq. That same day we received an email message saying that our project had been accepted. At that point we knew that this was really going to happen.

Blender development ceased
When making Guernica and Paradash, we discovered many things that our game demo design required and that were not available or buggy in Blender. But most of those features were high on the priority list of the developers, so we had good hopes that they would be included in the program by the time we were going to need them.
What we had not counted on was those developers going bankrupt...
Suddenly we were confronted with the disadvantages of political correctness. Blender was a cheap application, partially free, developed for the love of it for multiple platforms and devoid of all the nasty commercial attachments that come with many other programs. Ingrateful as the market is, the result of these high ethics was bankruptcy.
There were voices at the time that said that Blender development was going to continue and by now it looks like that is actually going to happen in an open source format. But at that time we couldn't wait. We needed to find an alternative quickly.
We were already completely hooked on doing this in full 3D so there was no going back on that idea. We had experimented with Macromedia's Shockwave 3D before and decided that we didn't like it. Mainly because it was a subset of a larger application, Director, and not dedicated to realtime 3D. Pulse 3D, the technology we had used for Eden.Garden, was a big no-no because of the complexity of the design process and it's licensing scheme. Axel came very close to Blender in the sense that it was also multi-platform and included modeling tools. But we decided against it because it was too simplistic for our needs. Virtools looked interesting until we heard its price.
After that, we were left with two contenders: German 3D Game Studio and Dutch Quest3D. Both applications were only available for the Windows platform. This was problematic for us but we decided to go with it because our project was about research of a concept, not about making it accessible to as many people as possible. The advantages of 3D Game Studio were that it came with some modeling tools and that it's scripting language was simple and efficient. Also, it was one of the few realtime 3D appliactions that was dedicated to making games. The others always wanted to be more versatile and generic. The sad part about that in Game Studio was that it was dedicated to making first person shooters, which was exactly what we did not want to do. We were very impressed with Quest3D's rendering performance: it made a quick connection to the 3D hardware of the PC through Direct3D. This is where Quest3D felt very creepy to us: they were making an application based on not just one, but two Microsoft products: Windows and DirectX. This was a tough one for us to swallow. But we were seduced by the performance of the engine and the elegance of the design of the editor. Quest3D comes with a flowchart based programming environment. This means that the programmer is not required to type much at all. The whole application is "written" by making connections between boxes on screen. It took a while to grasp this concept as we were more comfortable with scripting, but once we did we were hooked. The big disadvantage of Quest3D for us, however, was that it did not come with modeling tools. Then again the ones included with GameStudio were not very good either, and it's map editor was based on the outdated Quake model. So we were going to have to use extra software in either case, software that would provide for sharing data with the real time engine. Once we realised that Quest3D had many more features than Game Studio, the decision was easily made. We were a little anxious because, just like the makers of Blender, Act-3D was a small and young company (and they were Dutch as well! ;) ). But their product was much more solid and focussed than Blender and, above all, it was finished: it offered all the features required to make our demo right now. So even if they were to go bust, the software would still be useable, at least for a while.
But since Quest did not come with any modeling tools and very little character animation and texture mapping tools, we needed to choose one more application to take care of that aspect of the production. Blender was excluded because it had difficulty sharing its data with other applications and was ultimately found to be too primitive. We had had some experience with 3D Studio Max but using it required also using Character Studio and Deep Paint. It felt like trying to tame three dinosaurs simultaneously. Also 3D Studio Max is not an easy program to use. After some research we decided in favour of Maya. It's built-in modeling and texturing tools were much more intuitive to us and it had the added benifit of have a Mac OSX version in the works.

Table made: 8 talents, 8 spells, 8 princes (not final)
We had not decided on a name for the game yet, but we had decided that there were going to be 8 talents in our game. In the different versions of the fairy tale, the princess receives numbers of gifts or talents varying from 3 to 12. We felt free to take our pick and 8 turned out to be our lucky number. Each talent that the princess had received, corresponds with an object that is taken by one of the 8 princes. When the little girl return this object to Sleeping Beauty, she receives one of eight magic spells. These spells allow her to restore the palace: there is a spell to clean floors, one to fix walls, one for pruning plants, etcetera. To signify that the girl has acquired a certain spell, her appearance will change. A diadem will apear on her head when she receives the telepathy spell, patterns on her dress for the fire spell, etcetera.

Research project starts officially in Jan Van Eyck Academy in Maastricht
While the support from the Jan Van Eyck Academy covered less than half of the required budget, we were eager to go ahead and start the project officially. The schedule was expanded by three months to make up for the time that our physical presence in the Academy would cost. Because of this, the budget had to be increased. Lucky for us, VIZO decided to co-sponsor. This brought us well over half of the required budget.
The extra time reserved for commuting between Maastricht and Gent turned out to become less used than planned for because the Academy failed to acquire the equipment necessary for us to perform the tasks in situ. But we were happy to use the added time when we had to make up for the loss of Blender by learning new software.
And we needed extra time as well to make up for the lack of budget: we were going to have to take on commercial assignments to make ends meet.

Three new applications: Quest3D, Maya and StorySpace
By that time NaN, the makers of Blender, had officially declared bankruptcy and we needed lots of time to get to grips with the new software we had chosen. Quest3D had a steep learning curve but after a difficult first month, things went much smoother. The one thing that never ceased to hold back progress was 3D math: the most advanced mathematics that Michaël had ever used was trigonometry but the matrix math required for translation and rotation of objects in 3D was on a much higher level. The Quest3D interface made it a lot easier to work with things that we did not fully understand, however.
Maya, on the other hand, was a lot more complex and difficult to master. It is only now, after six months of intense work, that we feel confident enough to say that we can actually make something with that application. After we'd lost hours of work more than once due to bugs in the program. And we know that we have only scratched the surface of all it's features. After deciphering its cryptic texturing paradigm and figuring out what all the buttons do, one comes to the conclusion that it feels like a rather complex set of lego bricks held together by sticky tape and that this is part of its charm. At this point we feel there is no going back. And there is also nothing to go back to. All big 3D applications suffer from the same problem.

While learning these new skills, we were also developing the actual content of the game: writing out all the stories and harvesting narrative elements from all the versions of the fairy tale that we could lay our hands on. We figured that there was no point in trying to design a demo if we did not know what that demo would be a demo of. We quickly ran into a new problem. As our game world was going to be extremely non-linear, we had a hard time simply figuring out how to write the scenario. We started looking for tools that would help us with the task and ended up choosing an old application for developing and reading hypertext documents.
In the early nineties, hypertext was all the rage. The concept of hypertext was to make texts that do not require linear reading but instead consisted of small chunks of the text connected to each other through hyperlinks. The user would navigate from one chunk to the next by clicking a link. It was a dream-come-true for any deconstrivist postmodernist. This concept had been completely swept away by the success of the world wide web which popularized the notion of hypertext while at the same time destroying the very idea of using the concept of hypertext for literature. Yet, the most important tool for making hypertext documents is still around. It is called StorySpace and it turned out to be very suitable to our needs.
What started as a scenario for a game, has turned into a massive database, containing all of the information that we have concerning the game's stories but also it's design, technology, interface concepts, etcetera.

VIZO Design confirms funding
In April we also received confirmation that VIZO Design was going to fund part of the project. Together with the scholarship from the Flemish Government that brought us to 60% of the required budget. If we didn't find more funding, we were going to have to take on commercial assignments simply in order to survive. This would cut into our time seriously. If the commercial assignments were going to take too much time, the project schedule would have to be adapted. This would mean that the budget would become even higher. Etcetera.

Pergolesi on Klara
The baroque mass of "Stabat Mater" by Pergolesi was played on Belgian classical radio station Klara this month. To us, it sounded like a mother crying out for her little girl...

Experimenting with Maya and Quest3D
took about two months. In that time we also wrote the whole game scenario and started setting up the game loop structure.

The game loop
Everything that one sees on a computer is the result of mathematical calculations. Since the amount of calculations a computer can perform simultaneously is limited, they need to be queued and calculated one after the other, preferably very quickly so they appear to happen all at once. For a 3D environment like a game, this whole queue needs to be calculated once for every frame. For the human eye to perceive a series of still images as a moving image, approximately 25 frames per second are required. So these calculations need to occur 25 times per second. In a game, this queue of calculations is called the game loop, because it is a program that is executed over and over again, 25 times per second.
Quest3D represents this game loop as a flow chart: everything within this flowchart happens 25 times per second and in the order specified by the structure of the flowchart tree: left to right, top to bottom. This order is extremely important. To make the character walk, for instance, the player would press the keyboard's up arrow. After moving the character however, we need to check wether there is a wall in front of the character or not. So we would put collision detection with walls after moving the character in the flowchart tree. Then after that, we need to define how the character should respond to this collision, etcetera. It's a very linear system that is repeated over and over again.

3D space is empty
The annoying thing of a realtime 3D environment like a game world, is that everything needs to be made. In 2D animation you can fake a lot of effects and in video you just point your camera at something and it's in the picture. 3D, however, starts as an empty space. All nature, architecture, objects and characters need to put in that space on the right location. This usually means that all these things need to be made. Making these things in 3D is not as simple as taking a photograph or making a drawing. There is no suggesting in 3D. Everything needs to exist. Even if you don't see it. A 3D model is basically a collections of points in space. These points are then connected by lines and the triangles made by these lines are then filled with colours. All these points need to be created by the person making the model.
And as if that wasn't enough, all these points, lines and triangles need to be moved around when we want the characters to move. This moving around is hardly a random process either. We have to deliberately put a character in a certain location. Since this character is only a collection of points in space with less intelligence than a prehistoric bacteria, you have to tell it how to do each and every little thing. Simple things like where the floor is and that it should try to not fall through it or what to do when the player presses a certain button. And more complicated things that we humans might take for granted like going from one place to another without walking through the obstacles in your way or remembering to keep casting a shadow and take it with you when you move. Not to mention interacting with other point clouds in space and differenciating between a wall and a water pipe, the first being a obstacle that would block your passage, the second a thing that would be pushed aside when you run into it. Etcetera.

Work done in May:
Path finding, shadow casting, interacting with objects
Structuring the game loop
Concept of real locations (objects "floating in space")
Putting scenario in Story Space document

Tale-of-tales.com registered, name of game given: "8"
"Tale of Tales" is the translation of the title of a book in which one of the earlier versions of the story of Sleeping Beauty appears. We though it would be an appropriate name for the framework surrounding our game production.
The game itself, however, was not going to be called "Sleeping Beauty". Mostly because fairy tales have the bad name of being trivial children's entertainment. The number 8 kept reappearing in the stories we were inventing as well as in the architecture and ornamentation (mostly Arab and Persian) that we were inspired by. At that time, also, the "prequel" to Star Wars came out and we though it would be funny to mock the idea of starting with "Episode 4". We were going to call this game "8" and the next one "144", etcetera. These numbers could also become a huge source of inspiration for the game's design.
But the most decisive factor in choosing "8" as a name was that it exists in many languages. Since our game would not contain any language and we thought it would be impossible or at least extremely pedantic to not give our game a name, we decided on a name that was not connected to any one language. And as a bonus, since the origin of our number symbols is Arab, it also points out the -often forgotten- significance of Arab culture in the world, a culture that, by that time, was under heavy attack from the West as a result of the US response to the September 11 events.

Private: Auriea in hospital

Tale of Tales website launched
In June we decided we didn't have enough work ;) so we started working on a website. The idea was to present the game to future players, including future investors, to provide behind-the-scenes information to sponsors and other interested parties and to open a public forum where the design of computer games could be discussed among developers and players.
We wanted the work on the website to be an integral part of the development of the game. In order not to waste time and energy, we wanted the website to be a testbed for atmoshpere, visual effects and stories. But it soon became much more than intended because we couldn't help ourselves trying to make a good website. Which does not necessarily mean that the game production is served by it at all. In any case, the development of the web site took much more time than it should have. But it did force us to think about and write out some of the stories connected to some of the characters in the game. These stories were invaluable when designing the look of characters.

Sketches the characters
Finding a method to design the characters in the game proved to be a project in and of itself. It was difficult to find a method of sketching that would actually be helpful when producing the 3D models. And we tended to drift off in attempts to make beautiful drawings that were of no use whatsoever to the game production. Or so it seemed.
Went into the character design highly skeptical of "concept art" and seeking some way to make sketches both 2d and 3d that would actually be useful though not necessarily pretty. It is much easier to copy what one sees than to invent or subvert reality. Drawing seems so disconnected from building. Drawing did help quite a bit when story writing i.e.-> a character is so tall and wears this kind of clothing and has this sort of history. However storyboarding and sketches for communication with others outside the project are something we will have to revisit.

3D Map practically finished
In June 2003, the 3D map of the palace was practically finished. We call this model a 3D map because it is only intended as a reference document. We do not intend to use the actual model in the game but we will build the required walls and floors, etcetera, based on this model. In the game, the complete palace will never been seen at any one time. this would require too much memory and would degrade performance. The player will encounter the palace only room by room. This 3D map will garantee the consistency of the world. It will make sure that a door that is visible in one room, will appear on the right location in the adjacent room, et-cetera.
We quickly switched to 3D for designing the architecture because there was only so much we could imagine and account for based on 2D plans.

Other work done: Mouse force navigation ("push mode"), obstacle avoidance

Jobs: Lifetime Quiz, Tale of Tales website

Creation of a "game" folder on the file server
In this folder, a structure of files and subfolders is developed that will allow the game engine to access the many different assets required in the game. There is a folder for 3D objects like characters and rooms but also folders for machinima movies and programming functions. All files in these folders are in the Quest3D format.

More work:Pushing things, stay in room, switching camera's, 3D cursor

Jobs: NYCSEX ad campaign

Motion captures of Martha at Motek, Amsterdam
In order to make the animations of the main character in the game look more interesting, we spent a day in a dark studio in Amsterdam to capture the motions of a 5 year old child. These captures will later be applied to the girl character in 8.

Attended: Game Developers Conference in London, UK

More work: Whole gameloop redone & restuctured: seperation between thinking and doing

Jobs: NYCSEX kiosks

Making an alpha prototype
The difference between alpha and beta testing is that in the alpha phase, the general concept of the application is tested while in the beta phase, the application itself is tested for errors. Alpha testing takes place early in the project while beta testing happens right before the final release. There is a contradiction in this in the sense that in order to test the concept of an application in the alpha phase, a working application needs to be made. This application needs to be as error-free as possible in order not to skew the test results. It was an immense job to iron out all the little bugs to make the prototype usuable. It is very likely that due to all this bug fixing, the application has become unstable and will need to be rewritten entirely.

Jobs: BAM Next Wave

What went wrong?
1. Blender died and we did not reschedule the project
We underestimated the time and effort it would take to learn new software, especially Maya, and the time it takes to find solutions for converting between file formats to get data from one application into another.
2. The Prototype does not contain finished rooms
This is partly caused by the above but also a conscious decision. We felt that there were many things that we wanted feedback on before we continued and finished the game's look and feel.
3. Time
Time goes too fast. We are halfway through the project and we only have two rooms. Despite the fact that this was what we had scheduled, it seems quite a daunting task to make an actual game demo in another 6 months. Then again, looking back, only one fourth of the previous six months was spent on actually making the game. The other fourths being designing the game, learning the software and working on other jobs. With the scenario done, the software learned and no more other jobs to do, we should have four times the amount of time for the rest of the demo! Right?

What went right?
1. We have a working prototype
The small scale of the prototype does a bad job at representing what is behind and underneath it: a complete game scenario and a working and expandable game engine. Still it is an invaluable tool for testing many aspects of our design and we are happy to have it this early in the project. After this, things should go much more smoothly.
2. We know what we want and we know how to make it
3. The project is (hopefully) fully funded
It is not official yet, but there is a good chance that the Flemish Ministry of Culture will sponsor the remaining part of the budget. This will allow us to prevent wasting valuable time on doing jobs for money in order to survive.

Conclusion
Evaluation of alpha test results & implementation of changes during complete recoding of the engine.
Investigation of 3D aesthetics: 3D texturing is similar to 2D collage: learn lessons from this in order to make the world look more like a whole.
We have to make concrete decisions about which part of the game we are going to make for the demo and decide whether it is a good idea to try and fit that in the current budget and schedule. There is still a lot of very fundamental work to be done and we are far from mastering the software we are working with. It is a very high priority for us that the demo look very polished, that it look as good as the finished game will. Not just for convincing investors but also for ourselves: seeing a finished version is the only way for us to decide whether we are happy with the result and what should be changed if not.