Plan for Scott Shumaker
by Scott Shumaker · 05/04/2001 (9:59 pm) · 1 comments
First off, thanks to all who responded to my last plan. I'm really beginning to dig the GarageGames community, and hope to be more active in the future.
This plan probably won't be as exciting as my last one, I'm afraid. It's mainly personal updates, with a small rant on the bottom.
Before I began work on Hunted, I spent half a day going through my old codebase and fixing bugs and design issues that confronted me during Smash TV 3D and even Project Venus. I've actually been developing a carefully layered architecture since Venus, although there wasn't really much to speak of until I began development on Smash TV 3D, just some nice assertion macros, compiler pragmas, and type traits.
Last semester I actually had begun work on a turn-based strategy game with a friend. Developing fun turn-based games is HARD. We went through nearly a dozen major revisions and were still tweaking the game when the semester ended. After the design settled down a bit, we wrote a client / server app that let multiple clients connect and play a generic version of the game (no rule verification, just the abilities to place and move the appropriate types of pieces), simulate the 'card-drawing' process, and send text messages.
This helped with playtesting enormously; we could play games at our respective homes, and we didn't need to use pistachio shells, index cards, and a whiteboard to play the game. :) Unfortunately, my friend is taking a job in D.C., and I'm loathe to continue without his presence - playtesting takes at least two people, the more the better. So I'm putting it on the shelf for now.
Fortunately, I was able to further develop my framework during the client / server app development (which included a network library and server), and brush up on my networking knowledge.
As for yesterday, it felt good to get a lot of the old crud out of the system, and take care of things that had been bothering me for a while. I wrote a stripped down 'hello world app', which is a simple MFC-based app that includes the graphics system, font system, renderer, etc and which I can use as a base to write test applications. It's very useful to have apps such as these to test out new components that depend on having 3d rendering and all your framework in place, since you don't have to spend time making a shell project every time.
I spent the rest of the day learning about splines, which are going to be an important component of my path system.
Splines are cool, at least partially because they let you easily and efficiently represent a path in space. They are better than the alternatives for several reasons:
1) Since they are parametrized by t rather than x,y, or z, you can easily have splines that form loops or do other things you can't do with polynomials.
2) Most splines are designed to afford you local control over a portion of the curve by moving control points - as opposed to other representations where changing a point changes the entire curve
3) They are pretty efficient, since you only need to evaluate a few control points for a given segment of curve
Yesterday I wrote code for cardinal and b-splines and an application (using the hello world app as a template) to interactively place and move control points, view the resulting curve, and to observe an object moving at a uniform rate along the curve. It turns out that moving at a constant rate along a curve isn't a trivial task. You have to use a numerical approximation, because you need to reparametrize by arc length and can't easily get the inverse of the mapping function.
Cardinal splines are a generalization of Catmull-Rom splines, but with a tension parameter. They can be useful because the resulting curve passes through your control points, but they're not as pretty-looking as B-Splines. Both are almost identical in implementation - the only differences are in a few functions to compute positions and derivatives. I only bothered to write a rational, uniform b-spline implementation. This is not quite the same spline used in NURBS 3d modeling - although that form offers you more control over the way the curve looks, it is more expensive to evaluate and complex to code. Since my paths at this point are mainly for movement, I really don't need anything that sophisticated.
Today I added a class of 'curve' which is basically just connected line segments, and then integrated them all into the path library. The path library allows you to connect various types of curves, assign spring-based acceleration and decceleration, and set waypoints. I've been pretty busy with other things today, but hopefully I'll be able to get the new camera system done as well.
The main purpose of the path library is for scripted sequences and especially camera control. The control scheme I'm going to be using for Hunted basically necessitates some kind of curved path for camera movement.
There is certainly a lot of spline code on the internet, but I really wanted to learn how they work myself, which is something that you usually don't get when working with an existing library. This is not always the best solution when working under tight time constraints, but my main goal for Hunted is to have fun, and learn a lot doing so.
-----------------------
In general, I like to develop new code on subjects I'm interested in. You're probably not going to outperform dedicated libraries or approach them in robustness, but it's good experience. Obviously it's not something you should necessarily do when under a deadline, but even if you eventually change over to a external library, you'll find the work you did independently gives you a much better grasp of what's going on. Like it or not, any library more complex than an image loader is not the simple black box the designers would like it to be. You have to have a firm understanding of the underlying mechanisms to extract the most performance and to use the library in an effective manner.
This is especially true for complex game engines like the V12 engine. Even the level designers for 3d games need to be aware of the relative cost of various features. Perhaps particle systems are extremely expensive to render; maybe rotating brushes halve the framerate. While a lot of these idiosyncrasies can be learned as you go along, it certainly helps to have technical understanding to fill in the details. It might not be obvious to an even intermediate quake level designer that making the hallways that connect rooms go around corners rather than go straight gives a large boost in framerate. But if you have a deeper understanding of the way Quake's PVS works, you could figure this out.
It's probably not the level designer's job to understand how a PVS works in technical detail. They just need the necessary information to make levels that run fast on the target machine. So the responsibility falls to the programmer(s) to learn the ins and outs of the systems they're working with. If they are lucky enough to have access to the source, they can fix any outstanding problems directly in the code. If not, they may be able to work around the issues, and at the very least they'll be aware that they exist.
Don't be a passive consumer of technology. Just because the guys who wrote the V12 engine are smart as heck and have a lot of industry experience doesn't mean that they don't make mistakes. They certainly didn't have infinite time to develop it either. You may be able to make dramatically improvements in many areas, especially if your game isn't a team-based multiplayer fps. :)
Learn about the underlying algorithms. Make empirical measurements through timing routines and profiling. Above all, make sure that the technology does what you want it to do. The V12 engine may be world-class, but it won't do you much good if you're writing a text-based adventure game.
Of course, you shouldn't go too far in the opposite direction either. Almost everything you will want to do has been done before, and there probably have been papers published about it to boot. You shouldn't ignore the contributions of others unless you really enjoy rediscovering things entirely for yourself, and while admirable, that attitude does not get games shipped. For example, I used Computer Graphics: Principles and Practice as an introductory spline reference, and looked at David Eberly's Magic Software code to see how he went about computing integrals for spline arclength.
In the end, it's all about drawing upon the works of others to assist your own innovations. As Isaac Newton said, "If I have seen further than others, it is because I have stood on the shoulders of giants." So go out there, borrow what you can, redesign when you must, but don't ever lose sight of your actual goal: to make games.
This plan probably won't be as exciting as my last one, I'm afraid. It's mainly personal updates, with a small rant on the bottom.
Before I began work on Hunted, I spent half a day going through my old codebase and fixing bugs and design issues that confronted me during Smash TV 3D and even Project Venus. I've actually been developing a carefully layered architecture since Venus, although there wasn't really much to speak of until I began development on Smash TV 3D, just some nice assertion macros, compiler pragmas, and type traits.
Last semester I actually had begun work on a turn-based strategy game with a friend. Developing fun turn-based games is HARD. We went through nearly a dozen major revisions and were still tweaking the game when the semester ended. After the design settled down a bit, we wrote a client / server app that let multiple clients connect and play a generic version of the game (no rule verification, just the abilities to place and move the appropriate types of pieces), simulate the 'card-drawing' process, and send text messages.
This helped with playtesting enormously; we could play games at our respective homes, and we didn't need to use pistachio shells, index cards, and a whiteboard to play the game. :) Unfortunately, my friend is taking a job in D.C., and I'm loathe to continue without his presence - playtesting takes at least two people, the more the better. So I'm putting it on the shelf for now.
Fortunately, I was able to further develop my framework during the client / server app development (which included a network library and server), and brush up on my networking knowledge.
As for yesterday, it felt good to get a lot of the old crud out of the system, and take care of things that had been bothering me for a while. I wrote a stripped down 'hello world app', which is a simple MFC-based app that includes the graphics system, font system, renderer, etc and which I can use as a base to write test applications. It's very useful to have apps such as these to test out new components that depend on having 3d rendering and all your framework in place, since you don't have to spend time making a shell project every time.
I spent the rest of the day learning about splines, which are going to be an important component of my path system.
Splines are cool, at least partially because they let you easily and efficiently represent a path in space. They are better than the alternatives for several reasons:
1) Since they are parametrized by t rather than x,y, or z, you can easily have splines that form loops or do other things you can't do with polynomials.
2) Most splines are designed to afford you local control over a portion of the curve by moving control points - as opposed to other representations where changing a point changes the entire curve
3) They are pretty efficient, since you only need to evaluate a few control points for a given segment of curve
Yesterday I wrote code for cardinal and b-splines and an application (using the hello world app as a template) to interactively place and move control points, view the resulting curve, and to observe an object moving at a uniform rate along the curve. It turns out that moving at a constant rate along a curve isn't a trivial task. You have to use a numerical approximation, because you need to reparametrize by arc length and can't easily get the inverse of the mapping function.
Cardinal splines are a generalization of Catmull-Rom splines, but with a tension parameter. They can be useful because the resulting curve passes through your control points, but they're not as pretty-looking as B-Splines. Both are almost identical in implementation - the only differences are in a few functions to compute positions and derivatives. I only bothered to write a rational, uniform b-spline implementation. This is not quite the same spline used in NURBS 3d modeling - although that form offers you more control over the way the curve looks, it is more expensive to evaluate and complex to code. Since my paths at this point are mainly for movement, I really don't need anything that sophisticated.
Today I added a class of 'curve' which is basically just connected line segments, and then integrated them all into the path library. The path library allows you to connect various types of curves, assign spring-based acceleration and decceleration, and set waypoints. I've been pretty busy with other things today, but hopefully I'll be able to get the new camera system done as well.
The main purpose of the path library is for scripted sequences and especially camera control. The control scheme I'm going to be using for Hunted basically necessitates some kind of curved path for camera movement.
There is certainly a lot of spline code on the internet, but I really wanted to learn how they work myself, which is something that you usually don't get when working with an existing library. This is not always the best solution when working under tight time constraints, but my main goal for Hunted is to have fun, and learn a lot doing so.
-----------------------
In general, I like to develop new code on subjects I'm interested in. You're probably not going to outperform dedicated libraries or approach them in robustness, but it's good experience. Obviously it's not something you should necessarily do when under a deadline, but even if you eventually change over to a external library, you'll find the work you did independently gives you a much better grasp of what's going on. Like it or not, any library more complex than an image loader is not the simple black box the designers would like it to be. You have to have a firm understanding of the underlying mechanisms to extract the most performance and to use the library in an effective manner.
This is especially true for complex game engines like the V12 engine. Even the level designers for 3d games need to be aware of the relative cost of various features. Perhaps particle systems are extremely expensive to render; maybe rotating brushes halve the framerate. While a lot of these idiosyncrasies can be learned as you go along, it certainly helps to have technical understanding to fill in the details. It might not be obvious to an even intermediate quake level designer that making the hallways that connect rooms go around corners rather than go straight gives a large boost in framerate. But if you have a deeper understanding of the way Quake's PVS works, you could figure this out.
It's probably not the level designer's job to understand how a PVS works in technical detail. They just need the necessary information to make levels that run fast on the target machine. So the responsibility falls to the programmer(s) to learn the ins and outs of the systems they're working with. If they are lucky enough to have access to the source, they can fix any outstanding problems directly in the code. If not, they may be able to work around the issues, and at the very least they'll be aware that they exist.
Don't be a passive consumer of technology. Just because the guys who wrote the V12 engine are smart as heck and have a lot of industry experience doesn't mean that they don't make mistakes. They certainly didn't have infinite time to develop it either. You may be able to make dramatically improvements in many areas, especially if your game isn't a team-based multiplayer fps. :)
Learn about the underlying algorithms. Make empirical measurements through timing routines and profiling. Above all, make sure that the technology does what you want it to do. The V12 engine may be world-class, but it won't do you much good if you're writing a text-based adventure game.
Of course, you shouldn't go too far in the opposite direction either. Almost everything you will want to do has been done before, and there probably have been papers published about it to boot. You shouldn't ignore the contributions of others unless you really enjoy rediscovering things entirely for yourself, and while admirable, that attitude does not get games shipped. For example, I used Computer Graphics: Principles and Practice as an introductory spline reference, and looked at David Eberly's Magic Software code to see how he went about computing integrals for spline arclength.
In the end, it's all about drawing upon the works of others to assist your own innovations. As Isaac Newton said, "If I have seen further than others, it is because I have stood on the shoulders of giants." So go out there, borrow what you can, redesign when you must, but don't ever lose sight of your actual goal: to make games.
About the author
Jonathan Whitehead