Interviews

Meet Doug Poston! I know that you have met him at the forum but this interview will give all of us some precious info about the future of the Acknex engine.

Q: I hear that you have worked as a game developer before joining Conitec’s team; please give us a few details.
A: My previous job before coming to work for Conitec was a programmer for Nintendo Software Technology Corporation (NST) which is Nintendo’s "in house" development team. NST is very secretive when it comes to what they do, and I was given clear instructions not to mention any of the projects that I worked on while at the company, but my name appears on the credits for RidgeRacer64 ( http://www.nintendo.com/games/gamepage/description.jsp?gameId=222#about ) so you can draw your own conclusions. ;)

Before Nintendo I studied "Real-Time Interactive Simulation" at DigiPen ( www.digipen.edu ) and did various small game projects for the Windows and Macintosh platforms.

Q: You just got back from the Game Developer Conference – do you have some news that might interest the Acknex community?
A: A couple of 3DGameStudio users at the conference noticed me come out of the XBox developer lecture, but I’m under NDA so there is nothing I can talk about right now. ;) I still stand by the claims I made earlier; 3DGameStudio could be ported to the XBox platform but we need the support of a licensed XBox developer.

The new video card hardware being released by ATI and nVidia is nothing short of amazing. Microsoft is working on some new technologies for DirectX that, when combined with current and future video cards, will make your games have a "cinematic feel" to them. Many groups are advancing the art and science of AI as well, so the future is both "smart" and "good looking."

Q: Where and how did you learn c – script (aka wdl)?
A: I learned C-Script (which was called WDL at the time) from the documentation (WDL Manual). Because I had experience with the programming languages that C-Script is based on (C, C++, and Java), I was able to learn the basics very quickly.

Having experience with other languages helps, but the best way to learn C-Script is to use it. Start with the basics (workshops and tutorials) and then do your own experiments. Not sure how an instruction works? Write a small test project and find out. Wonder if you can reproduce a cool effect you saw in another game or movie? Give it a try.

As much as we try to keep things simple, C-Script is a programming language and chances are you won’t learn it overnight. Keep working with it. Use the manual to look up commands. Search the user forum to see how other people have solved things. For every problem you solve you will become that much better at programming.

Q: Are you going to rewrite the templates? What do you plan to add to them in the future?
A: I’m rewriting the templates right now. We plan to add what our users have asked for. First Person Shooter code will be there, but racing games, RPGs, space sims, and other genres will be added as well. The idea is to design the templates to be more "modular" so we can add new elements and let the user "mix-and-match" different elements to get the results they want.

While the main goal is to make it so new users can select the elements they want, tweak a few values, and publish a game without touching the code, the templates are being designed so experienced programmers can use elements they like and rewrite new scripts that will plug directly into the existing code.

Q: Are you going to improve the AI, too? What can we expect from the new evil actors?
A: New and improved AI is definitely a part of the new template scripts. In the past the AI was extremely basic because it is difficult to program "smart AI" that works in all situations. The result: "dumb" AI that works in most situations.

The modular nature of the new template scripts will make it easier to add a wide variety of AIs. Users can then "pick-and-choose" the AIs that work best for them. Need a bipedal AI that guards an object? One that patrols an area looking for the player? One that can drive a car? Just select the AIs you need and place them in your level.

Q: Let’s talk a little about the new game creation system that uses customizable scripts. How will it work and what game templates will it include?
A: The customizable scripts are part of the "non-programming game creation" system we are forecasting ( http://www.conitec.net/forecast.txt ). It is based on the new modular template system, which allow the user to add and remove scripts depending on what type of game they are creating. Users can then adjust values and select resources that are used by those scripts allowing them to fully customize their games without touching a single line of code.

This is hard to explain, so let's do an example. Let’s say you want to design a game that has an outdoor level with an animated sky. Inside WED you would select "Add Script" and select one of the sky scripts that fits your needs. Each script comes with default values, but you can change most of them by selecting "customize". If you choose to customize the sky script you can select the day and night skies, horizons, and the cloud map images. You can also adjust the animation and scale of each element in the sky. Press save and run your level. It is that easy.

Q: How should we write our code in order to get the maximum speed out of it? Are there any functions, features, etc that should be avoided or used carefully?
A: The new documentation lists the "speed" of the instructions. Obviously you will want to avoid slow instructions when you can, but it would be a mistake to concentrate too much on the individual speed of instructions and ignore the overall design of your project.

- Don’t perform actions that the player cannot see. If you have 100 entities in the level, but the player only sees 3 of them, the other 97 shouldn’t be consuming much of your CPU. Setting up ‘triggers’ in your level to activate entities or even using a slow instruction like "trace" to see if the player can even see an entity can really help speed up your game.
- Just because it "works" doesn’t mean it is right. In one of my projects I had an effect that emitted 50 particles. It looked good so I went on my way. Later I discovered that out of those 50 particles only 10 of them had unique locations, the other 40 were being drawn on top of these 10! I reduced the number of particles from 50 to 10 and everything looked the same but it ran 5 times faster.
- Don’t be afraid to start over. Chances are the first solution you come up with to solve a problem is not the most optimal. Don’t become attached to your code; if you find a better solution, use it.
- Don’t spend too much time optimizing your solution until you are sure that you need to do so. Use the "debug panel" to see how much time is being spent by your code and compare it to the time being spent rendering the level. Most of the time it is the graphics, not the code, which need to be optimized (see Marco’s interview last month for ideas on how to speed up your level design).

Q: You have to give us a few tips for beginners!
A: Here are three basic tips that most beginners (and several "advanced") users tend to get stuck on:

- Start small. Too many users try to program their "dream game" right away. This is a great way to become frustrated. If you are new to programming and you have a great idea, write that idea down and think of something simpler to design.
- Spend some time on design. Taking an idea directly from your head and trying to code it into the computer is more difficult then you might think. Grab some paper or a word processor and write your ideas down. Even with a simple project you will probably have to redesign things several times before they work right; it is easier to redesign on paper then it is in 3DGameStudio. If you can’t fit your design on a couple of sheets of paper then maybe you should re-read tip #1. ;)
- Finish it! This is perhaps the hardest thing to do. A lot of games get 60%, 70%, or 80% done, but that last 20% is what makes the game. You can learn a lot from a half-finished project but the joy and experienced gained from a finished game can not be measured.

I can come up with dozens of other tips (make backups *before* you make a major change, use breakpoints and panels to help debug your code, etc.) but beginners should concentrate on these three.

Thank you a lot, Doug.