Q: Have you worked with other engines before meeting Conitec's Acknex?
A: Approximately ten years ago there was a program called "3D Construction Kit" by British software company Superscape which got me really interested in working with a script-based 3D game engine. I have also tried out Genesis3D/Jet3D for a few months before joining Conitec. Aside from that I was mostly working with low-level graphics APIs such as IrisGL/OpenGL, DirectX.

Q: I know that you joined Conitec only a few years ago; how did you learn C-script?
A: By reading the printed manual that comes with the Sybex Extra Edition. Reading it once left a number of questions unanswered, so I can sympathize with some of the requests we have had in the "Blame the Manual" forum section. However, after reading it a second time and creating a few sample programs it all made perfect sense. For programming newcomers I especially recommend going through the 7-day workshop and then start playing around with the code to see what effects this causes.

Q: There are a lot of users who want to learn how to play with the sdk. What books would you recommend?
A: The SDK itself is just an interface to GameStudio's internal data structures and C-Script functions. I don't think you can create a blank SDK project and then see what you can do with it- it works the other way round: you have the idea of some intriguing graphics effect, or advanced scripting functionality and then turn to the SDK to implement it. One thing I am looking into right now is how to use GameStudio as a visualization for Windows Media Player 9- that would be a perfect candidate for playing around with the SDK and seeing if it can serve as an interface between these two applications. Another project which I had to abandon due to time constraints is a chess game which uses GameStudio for input / output and connects to an OpenSource chess engine for the calculations.

Book recommendations, unfortunately I don't have any recommendations for good introductory C books :
- Stroustrup- "The C++ Programming Language" (for people who know C but want to move up one level to C++),
- Woo/Neider/Davis/Shreiner- "OpenGL Programming Guide (Red Book)"  (general introduction into 3D graphics)
- Moeller/Haines - "Real-Time Rendering" (advanced computer graphics, special effects programming, high-end rendering)
- Lengyel - "Mathematics for 3D Game Programming & Computer Graphics" (can't avoid math if you want to have pretty pictures)
- Microsoft - "Visual C++ online help system"

Q: What ide / programming language (msvcpp, delphi, etc) is the best to use with the sdk? Why?
A: MS Visual Studio C++ 6.0. The Conitec development team uses Visual Studio 6.0/ 7.0, so that's the platform we do most testing with, and if questions occur in the SDK section of the forum we can provide more reliable answers for these products. Visual Studio 7.0 is a little cluttered and it takes more effort to create efficient code, but either one of those works fine with the SDK.

Q: How should we design our levels in order to keep the frame rate as big as possible?
A: GameStudio offers lots of features for specific tasks- however if you limit yourself to only some of them this can have a strong impact on your overall performance. The map compiler which turns your WED level into a more efficient format for GameStudio assumes that you are creating maze like indoor levels. If instead you use it to create large outdoor levels your fps will drop (instead: use WED to create a rough sketch of the level and fill the details with terrains). Frequently use L or U-shaped corridors between rooms- usually the map compiler will take this as a hint to treat the rooms separately. If you have a straight hallway connecting two rooms, chances are they will be treated as a single large room, which reduces the framerate. Concerning details- do not create door handles, screws, ladders, etc. as part of your main level file as this can
have an impact on the rendering speed of nearby rooms (not to mention possible compile errors). Instead create details as separate map entities or MDLs- if you rely on accurate shadows then at least turn on the Detail flag of those small blocks. One very important recommendation: use Level-of-Detail whenever possible. If the player is flying in an airplane over a forest there is no need to use 500-poly trees. On the other hand, once the player lands and walks up to the tree (in order to catch the evil squirrel) you should use a 2000-poly model for that specific tree or users will complaing about the graphics quality. Despite AGP ports, a major bottleneck with graphics cards still is the transfer of textures from mainboard RAM into graphics card RAM. To minimize the impact of these transfers, refrain from using too many textures/lightmaps. Reuse textures whenever possible, make sure that your textures are square and powers of two in width/height. If there are multiple styles in your level keep them separated, e.g. in your alien infested space station there might be textures of metallic surfaces, as well as organic-looking structures. If you have a hallway alternating metallic with some organic textures both need to be present in the graphics card RAM at the same time. With low texture memory alternating between these two texture sets can slow things down. Instead limit yourself to a hallway with metal textures, then a U-shaped tunnel and then your organic part of the level. There might be a performance drop in the U part, but less RAM will be used in the other two halfs.

Q: Is it worth buying a dual cpu pc to build the levels?
A: For small development teams it is not worth buying a multiprocessor system. There are 4 steps that occur in level compiling: geometry creation, portal creation, visibility calculation, lighting. Currently only visibility
calculation makes use of multiple processors, but for most levels this is the slowest step and can take days to finish on slow machines. However, this step can be skipped: GameStudio runs fine without visibility information (it just renders the whole level like WED does). This will usually give you a big performance hit- but if you only want to check your recent lighting changes it does not matter. To avoid visibility calculations select "Testmap" instead of "Levelmap" in the Build dialog. Then as your project nears completion, build it with "Levelmap" to check for consistently high framerates at all locations in your world (or redesign the map if there are drops at certain rooms). With this being said, if you work on a high profile title and want to make sure that you get excellent performance across the range of available PCs, then these framerate tests can occur frequently- even at early design stages (where it's easier to modify level design). In this case it makes sense to get a multiprocessor system. One customer timed the following calculations for the same map:
Single processor: 6 hours, Dual processor: 4.2 hours, Quad processor: 2.1 hours.

Q: What features do you plan to add to the wmp2wmb compiler in the near future?
A: One of the major changes we are looking forward to is replacing the BSP (Binary Space Partition) tree and maybe removing the portal information. Currently the map compiler makes sure that only polygons of the current room the player is in are rendered. This is nice for PCs which render slowly, but with faster graphics cards it makes sense to, say, draw the neighboring rooms as well, as long as this frees up the CPU for more useful things such as AI or sound. As a bonus this means vastly reducing compile time, better shadow maps, and maybe even adding geometry during gameplay.

Q: Can you give us a few tips for beginners?
A: Start small. If you aim to make your first game similar to, but better than Grand Theft Auto 3 you are bound to become disappointed. Use templates. AUM and the tutorials provide game templates- it takes only
little imagination to turn those into full fledged, entertaining titles. Group up. In the good old days, a single person could create programming and artwork for a first class title, today teams of 20 or more people work
fulltime on the products we see on shelves. If people compliment you on your level design, but you find C-Script frightening- consider teaming up with a C-Script wizard, and a musical genius, to make a well-rounded team. Take one step at a time. If you do a first person shooter, a racing car game and an RPG title at the same time, chances are none of them will be finished. Set milestones to make sure you and your teammates are still on track- too many teams break up because there is no clear immediate goal for each team member. Stay informed. Read the user forum. Read AUM. If you can afford it, get a subscription to Game Developers Magazine (if not- go to www.gamasutra.com and read the articles online). In the past few years Charles River Media has emerged as the publishing company with the most game-related books of high quality.

Q: Please give us an example on how the new physics engine will add value to our projects.
A: Immersiveness: from everyday experience we have certain expectations towards "reality". E.g. if I bump into my office desk it's very likely that the table will move a bit. Yet all in-game offices I have seen so far featured desks that were apparently bolted to the floor. Thus the lack of physics betrays all the advancements that computer graphics have made in the past few years.

Non-linear, non-predicatble game play: one often heard critic about current FPS games is, that they are too linear. Basically the player walks along a pre-set path, does pre-determined things and then wins. Why not add some MacGyverisms to the game instead? Here are some examples: I know that a guard behind the closed door will soon start patrolling the corridors. Luckily I noticed a chair in a nearby room, so I grab the chair and put it under the door handle, preventing the guard from leaving the room. Then, using the time gained, I stack all barrels I can find in the level onto a heap- carefully balanced on a small wooden board- the unsuspecting guard comes running out the door, bumps into my trigger, causing the barrels to tip over which then roll over him. Some game designers will disagree with this idea of non-predictable gameplay because it introduces huge loopholes, requires extensive testing,  and is more prone to errors. However, I think predictable action should be left for blockbuster movies and kept away from computer games.

Shorter development times: if you have ever tried writing C-Script for a simple ball rolling realistically on the floor and colliding with objects, then you know that this can be a challenge. When several objects are supposed to interact with each other it gets exponentially more complicated and time-consuming. Compare this to adding these features to your project using the physics engine- it only takes a few lines and everything else is handled by GameStudio. Here's the relevant physics code for the bowling ball from the demo video:

action InitBall {
   phent_SetType(my, PH_RIGID, PH_SPHERE); // make it a physics object- sphere shaped
   phent_SetMass(my, 5, PH_SPHERE); // weighs 5 kg
   phent_SetFriction(my, 70); // rolling friction 70%
   phent_SetElasticity(my, 50, 10); // 50% bounciness when moving faster than 10 quants/sec
   phent_SetDamping(my, 20, 20 ); // 20% damping
}

function InitPhysics {
 temp.x=0; temp.y=0; temp.z=-380; // corresponds to earth gravity factor 9.81
 ph_SetGravity(temp);
}

Thank you a lot, Marco.