Q: I have to admit that your demo looks pretty impressive; is this your first title?

A: Thanks for compliments; we had to consider our goals first. Our project was heavily focused to an educational goal: “It doesn’t have to be good looking because we don’t publish games. It has to be similar to a driving school lesson.” But who likes to go to school? It was clear for us that a driving simulation has to be good looking. It was also clear that the city layout and the physics simulation for our cars have to be as realistic as possible to beat our (possible) competitors by miles. And we had to consider the “fun factor”. We realized that due to some experiences we’ve made during game development some years before. All our team members were experienced A3 developers and game designers. In 1995 we have started to publish an A3 ego shooter and we have continued with several smaller 3D applications based on A3.
 

Q: How many men are in your team and how long did it take you to finish he game?

A: We had 3 guys in our core-team: one programmer and two graphic artists. All 3 men have created levels with WED. The creation of graphics and textures have also been done by these 3 persons and another graphic artist. One of our men has created the houses and the street textures; the other two men did the rest of the graphics work: one of them made the help dialog graphics and the start screen and the last one (the WDL-developer) the street signs and the GUI. The graphic artist has delivered the basis for the cockpit model and the traffic light models. The basis for the car models are bought from geometricks and the pedestrian is from the free models project. Sounds are derived from a professional sound studio. One guy of the core team did all the WDL- and DLL-programming. He also animated and refined the models to be suitable for A5 and created all traffic sign models. Yes - and a girl friend of us delivered the story board - which cars and pedestrians will move at which event in which direction. What driving-skills shall be trained in which way; how will be the entity-paths and so on. She also did system testing. For testing we have also hired a professional testing lab in Scotland.
 

Q: How many portals has a medium sized level?

A: One of our lessons learned: you can handle an A5 level be having a maximum 4500 portals. It takes some experience to create a big level with only a few portals and it is also tricky to arrange these portals in such a way that the “camera-scan” always hits a low / medium amount of portals at the same time (the absolute amount of portals is only important to get the level rendered by “wmp2wmb” in a short time). Our first level had over 8000 portals and a poor frame rate; it was possible to build the WMB in preview mode. At the middle of the project it was necessary to split our level into different smaller levels which will be loaded at runtime. Our biggest level (big means a lot of building and crossings) has 3500 portals and a rendering time of 45 minutes on a 500 MHz PIII. In WED, block positioning was done with a lot of care for that level. Our smallest level has 2800 portals but it took 10 hours to render; because it is a small level the camera will always hit a lot of portals, so the frame rate is poor. The big level is much more faster (and has more models too). Our last level (we didn’t had enough time to optimize it) has 5150 portals and it took 190 hours to get rendered (using the same PC as the big level). You can imagine that the portal placement is important to consider. In summary we created 5 distinct levels with a medium count of 3500 portals.
 

Q: How did you attach the lights (for breaks, etc) to the car models?

A: This was a problem; the models are made of two distinct entities - one for the chassis and one for the wheels. Our original plan was to create a third model with attached lights and different skins. So you will have a lot of work on each car to place the light model exactly to the chassis position and angles. This would be the best solution because we would waste only a small amount of texture memory for different light-skins. The idea was also to attach flare sprites to the break lights to get a better visibility. We didn't have enough time to realize this idea, so the traffic lights are painted on different chassis skins directly. This costs a lot of texture memory which we had to spare at the block textures instead, but it works fine.
 

Q: I think that you are using predefined paths for the other cars but how did you manage to synchronize the movement (one car waits for the other to pass and so on)?

A: This is also a little bit extravagant. We had to move a lot of cars in parallel and we had to meet the requirement of getting a fast frame rate. Typically one level has to move 60 cars (that means 120 entities) and pedestrians in parallel. That means that these entities are not allowed to use the A5 collision detection because we want them to move fast. Another necessity was to program cars to drive on several lanes according to our story board. Additionally, cars will be triggered by other cars or the player and the car ways and states have to be restored upon user’s request. To increase performance, cars will be hidden depending on the localization of the camera and restored back if the camera turns.

One of the solutions was to assign only one path to each lane. Cars drive from waypoint to waypoint and are able to change between different ways. I programmed that “driving plan” using some of the 8 skills being available at WED’s entity-dialog, so the story board designer has got a WED-toolkit to realize her ideas. Each car only knows its nearest car on his own way and calculates distance to that car each tick. With that information and according to traffic rules, gas and steering wheel are calculated. A car model is controlled the same way the player controls his own car using the keyboard; everything behaves in the same way and uses the same mathematical rules so it would be easy to implement a multiplayer driving-simulation in future. A car has to monitor its “nearest” car only (and the player) at each tick; I had to establish only a mechanism to calculate the nearest car on certain circumstances. The decision when to brake and when to accelerate is implemented using an automaton. This automaton also considers up to 20 physical parameters to simulate a realistic driving experience of different car types (car length, wheel distance, mass, several different springs gears, power etc.). I also implemented a bike driving rule but we couldn’t afford a bike model at last…
 

Q: Do you plan to release an English version of your simulator in the near future?

A: There will be localizations for other countries in the near future. First of all we will implement European localizations. The English version will be difficult. I think that an US-version would have to have also typical American levels. American cities are quite different to the European cities. Furthermore we have to improve the highway simulation and so on. For an UK version the level has to be mirrored because our UK friends drive on the left (wrong ;-) side. If the new WED will get that mirror-feature we will move forward to realize the UK version too.
 

Q: If you would start creating 3D-Fahrschule again, what would you change in it?

A: I would take a stronger emphasis upon the city layout. We only use a small part of the implemented functionality because our crossings are not very complex.
And I won’t start such a project by having such a small budget we had (and small means really small). Professional graphics work is very expensive.
 

Q: Do you think that A5 was the "perfect" tool for this game? Have you missed an important engine feature?

A: This question isn't easy to answer: yes and no. The main points which speak against an usage of A5 (but this is only my personal experience):
- The lack of creating complex data structures and entity arrays.
- There is only a poor pointer arithmetic (but it gets better and better) and you are very restricted if you want implement using an object-oriented approach. I’m used to program in Java - so you can imagine my situation ;-)
- Combining moving models is not easy and sometimes not easy to comprehend.
- Scanning is only done by cones and triggering done by spheres.
- You have only global fields (how to implement a recursive function?) and global functions.
- Using fonts is not state of the art.
- Saving is not differentiated enough.
- The (old) WED is *§$@!# !

But there are also good points for which I would choose the A5 for the next 3D project too:
- The support is quite excellent. This is the major fact!
- If I won’t get a bug fixed or a very special question answered, the best tool would be useless. And the Conitec-support was very good (special thanks to JCL).
- It is easy to get a lot of good results with a little effort. You get much for little money.
- The API is very comprehensive and easy to understand.
- You can do a lot of things if you understand A5’s particular nature (if not you will always stay at a beginner’s level).
 

Q: What are (in your opinion) the key "selling" points for 3DF? Why would I want to buy it?

A: I drive the car for almost 20 years. During the test phase I drove through the levels over and over. As an effect I recognized the I turned my head more often in reality. Though the game concept worked indeed!
Additionally there are situations which can not be trained with a real car. You can do forbidden things and you can repeat scenes. You save a lot of money because you won’t have to pay a driving instructor.
Additionally this is - as far as I know - the first car game (sorry - simulation) in which you can drive in every direction and not only along a predefined path (this feature is restricted in the demo version - sorry folks)
 

Q: What's coming next? You get rich with this title and stop making games?

A: We won’t earn a lot of money with that product if you consider the amount of work we put in it (working 18 hours a day). But it was fun to make that project and it is also fun to read recessions and test reports. Actually we are test-winner in some magazines - so we can say it was worth the effort. Except some localization stuff off 3DF there are no concrete plans for new projects - sniff…
 

Thank you very much, Harro.