See what's going on with flipcode!


Future Experience
Question submitted by (04 December 2000)

Return to The Archives
  I'm a 17 year old high school student, and I'm interested in 3D engine design. I've writtten several "toy" engines (just rotating meshes or so) to test out triangle fillers and object loaders. My question is: what do I do now?

Should I implement a 3D Studio MAX 3 (ASE is nice) loader and some arcane visibility algos? I only have 1 year to go before I've finished my Matric, and I'd like to have something to show some game companies.

  What I get from your question, Thomas, is that you have played with the core graphics stuff and now feel that it's time to apply what you've learned to something useful; something with some substance. At the same time, you don't know which direction to take your project. This is not something I can answer for you, but I might be able to give you a few tools so that you can determine this for yourself.

The trick is in knowing what you want. Makes sense, sure, but is it that simple?

I often think that philosophical discussions are as important (if not more important) than practical discussions. Philosophical discussions can provide tools for a more broad use of knowledge, while practical discussions are typically very specific. I think that this is one of those situations where a philosophical discussion is best suited.

In my typical style of type-a-lot-to-say-a-little, I'm going to digress while staying on topic. Besides, this column isn't free; your payment for asking the question is to put up with my digressions. And since you don't know where I live, you can't stop me. ;)

A few months ago, I was approaching different potentials for investment capital. I hadn't been on the phone for very long before somebody finally asked me to simply send an email outlining exactly what we wanted. What do I want? No sweat! I wanted to start a company and needed X dollars of capital in order to do so. I'm not completely ignorant, I also knew that I needed to retain the rights to the technology, and I knew all the specifics about the company and the capital, but something was still missing. To be perfectly honest, after typing up the email, I looked it over and it didn't look anything like what I would expect such an email to look like. It just looked bare, lacking a lot of content. All of the sudden, knowing what I wanted wasn't so simple, because I was stepping into an area where I had no expertise: business.

The biggest problem was that the question itself was incomplete. Since you can't answer an incomplete question, I extended it to: "what do I want from this business arrangement?" Now I know what's missing from my email.

I called up my business consultant and began a three-day affair with the telephone. Let me tell you, not a lot of savvy business folk are willing to spend three days on the phone teaching a biz-lamer (like me) the ropes. Fortunately for me, this person is one of those rare, extraordinary people. During those three days, he didn't simply tell me what to say or do in certain situations; rather he helped me understand the way a business-minded individual would think. Teach them how to grow the corn, as they say.

Between the two of us (well, 10 pounds of him and one pound of me), we crafted up a proposal. As I expected, the portion of the proposal that covered the capital investment needs was only about 10% of the entire proposal. In the end, I found out that I wanted a lot of other things that I just wasn't aware of. The rest of the proposal covered such topics as the term of the arrangement, how much of the capital gains from the technology we needed (and how much we were willing to share), equity options, technology usage rights, exit strategy, and a lot more. I also wanted the proposal to be fair.

The extended question allowed me to see more clearly what my near-term goal was. My goal was not just startup capital for the company, but a business arrangement. I've always been very clear about what I've wanted from life and from my career, with very clear goals. Somehow, this one slipped past me because I let my lack of knowledge confuse the issue. Knowledge is only a rest stop on the way to your goals.

Have I been obscure enough? Let me be more direct.

Given a map with two points (point A labeled "You are here" and point B labeled "Your goal") find the path from A to B. In order to navigate the map successfully, you need to know both points very well. You need to know exactly where you stand now (what you're capable of, etc.) and you also need to have a clear idea of your goal (this usually means a spec for your engine or your demo.)

Listen up! This is important: it often helps to work backwards from B to A.

Next, simply ask yourself what does point B have that point A does not? This is sometimes as simple as looking at your spec and realizing what has yet to be implemented. But don't forget about the intangibles, like how everything will fit together in the engine. Do your best to try to cover all the bases.

At this point, the idea should start to become clear. Along the path from A to B (or B to A, whichever the case may be), there are obstacles. In this case, an obstacle might be curved surfaces, or character animation.

Each obstacle will have a set of dependencies (which, in turn, may have dependencies of their own.) For example, the curved surface obstacle might have the following dependencies: (1) learning how they work, (2) implementation, (3) integration with the environment, (4) how to illuminate/texture them and (5) where to get the data.

Here comes the cool part. When you originally spec your goal, it usually consists of a simple list of features that describes what the engine can do, and how it will look. Most of this stuff you already know, but it's good to have it on paper for reference. As you fill in the path with obstacles and their dependencies, you are producing the contents of a design document.

A design document doesn't have to be a formal document. The purpose of a design document is to map a path from A to B. If you decide to actually draw the path from A to B with all obstacles and dependencies using a magic marker on the nearest wall or if you decide to build it with string, soda cans and duct tape, it doesn't matter.

Response provided by Paul Nettle

This article was originally an entry in flipCode's Ask Midnight, a Question and Answer column with Paul Nettle that's no longer active.


Copyright 1999-2008 (C) FLIPCODE.COM and/or the original content author(s). All rights reserved.
Please read our Terms, Conditions, and Privacy information.