Game Deployment Woes (Just Make It Flash!)

In one of my previous posts I released a Pong clone game that, albeit not polished, was a fully working game and I was quite proud of it. Of course, as sometimes happens with the deployment of Windows-based games, I was dismayed when I learned nobody who actually took an interest (thanks to you faithful few!) was able to run the game :(

That's when the fun began. I asked one friend to make sure he had the DirectX runtime installed and even to reinstall it - no luck. I then learned the C++ runtime was required and had the same friend perform that install - no luck. I tried two different machines with the same installations - no luck. Finally I learned it was not just requirements on the target systems; it turns out I had included a debug version of a DirectX library in my project, which allowed the program to be created and executed, just not in a way that it would work!

You see, as a developer, I have all of the tools required to run any program I create. But other machines don't necessarily have these tools/environments. So I think I'll use the following plan for deploying my next game.

1. Create a game, coding and testing in DEBUG mode
2. Change the project from DEBUG to RELEASE mode
3. Replace DEBUG libraries with RELEASE libraries
4. Build the project in RELEASE mode
5. Create an installer project to install the game, the C++ runtime, and the DirectX runtime

1. Create a Flash game that can be played from a web page in any browser!

Now all I need to do is learn to program a game in Flash...

Triangle IGDA Chapter Meeting

Just a quick update, I'm excited to attend my first IGDA chapter meeting and extend a big thank you to my buddy Wes for making me aware of it! Event details can be found here and I've posted the basics below.

Date:  December 3rd, 2009
Time:  7-9pm
Place: Buckhead Saloon
       411 W. Morgan Street
       Raleigh, NC 27603

More info can be found on the Triangle IGDA chapter page, which dubs this event a "holiday mixer" and encourages attendees to bring non-perishable food items to support the Food Bank of Central & Eastern North Carolina.

Hope to meet you there!

Pong Postmortem: Completing a Game in 24 Hours!

For the uninitiated (or techno-illiterate), a "postmortem" is a wrap-up discussion summarizing the good, bad, and ugly of a project following its development. What follows is a summary of the creation of my first completed game, a clone of the Atari classic Pong.

My Pong clone was created in 24 hours, though not in the type of all-nighter hack-a-thon you might expect or even a typical three work days. I have a full-time day job, so development is typically done late evenings, but fortunately I kept track of the amount of time spent on specific components. Note that I started with a working Direct3D application from Luna's book Introduction to 3D Game Programming with DirectX 9.0c: A Shader Approach. Here is the hours-to-effort breakdown:

• 10 Hours - I dedicated the first 10 hours to rendering the basics of the game: the board, two paddles, and the ball. This included creation of graphical "placeholders"; I'm not an artist but I realized I could come back and make the art fancy after everything worked. Getting the ball in motion and then allowing it to bounce off the walls and paddles (Collision Detection) was the second major focus. Finally, the simple mechanic of allowing the player to move a paddle up/down brought the game into a playable state.
  
  
• 4 Hours - The primary effort of the next stretch was to implement a basic computer opponent (Artificial Intelligence), and I started with a perfect opponent whose vertical position matched the ball's position at every moment. When adding different game modes, this perfect opponent became part of the game's Practice Mode. I added the ball's motion blur effect just to improve aesthetics and moved hard-coded values to an include file for easier maintenance and testing.
  
  
• 4 Hours - In this phase I worked on creating a computer opponent that moved more realistically but was also fallible; a perfect opponent gets boring to play against! I added different difficulty levels (easy/medium/hard), which works by choosing a random "reaction time delay" between when the player hits the ball and the computer opponent is allowed to hit the ball. Obviously, as difficulty increases, the computer's reaction time improves to make it a more formidable opponent.
  
  
• 4 Hours - At this point the game was playable with differing levels of difficulty but no clear way of selecting game settings. I created the menu system and added scoring to determine the winner.
  
  
• 2 Hours - The last step before I considered the game completed was to work on the art, which could clearly still use some work! :)

Final Thoughts:
I knew this project would be relatively simple because there are only four game objects to keep track of: two paddles, one ball, and one board. However, due to its simple nature, I was inclined to hack it together quickly and did not follow strict OOP (object-oriented programming) principles. The majority of the game code is in a single monolithic file. I also resorted to reusing an existing class designed to output simple statistics to display text-based menus. But worse, the same class used to show all menus and text became my game state manager since I needed to know which menus had been processed. I then extended it to display current score values and to show which player had won the game. Although I could have put a lot of time into doing it the right way, the purpose of this effort was to get something done. In future endeavors I plan to follow better OOP design.

The best part of this project is that I actually completed a working game! I am proud of the subtle but effective motion blur effect. The game doesn't have all the bells and whistles (seriously, no sounds or music yet) but it is playable, implements Collision Detection and Artificial Intelligence, and has a clearly defined winner at the end. Some may even consider it fun :)

PONG Clone Completed!!!

It is with great pleasure that I announce I have finally completed a game of my own! There are some obvious improvements that could be made (adding sound, better art, etc.) but it is a fully working game with Artificial Intelligence (AI) for the computer opponent, basic menus, scoring, and clear winning conditions. I'm particularly proud of the ball's motion blur, a subtle effect that makes the game look more polished.

The left paddle is controlled with the W (up) and S (down) keys. Likewise, the right paddle is controlled with the O and L keys.

Download the Game Now!

I would be very appreciative of any feedback; just leave me a comment here on the blog to let me know what you think. I will provide a breakdown of the effort spent on this simple game (done in 24 hours!) in an upcoming post.

Finishing a Game: Pong Update

As I've stated in some older posts, I've been planning to work on a Pong clone for some time now. I was digging through a new book and learning the internals of Direct3D lighting, texturing, blending, meshes, etc. And I've learned a LOT (especially about vertex and pixel shaders) since those older blog posts, but one problem with the book I'm using is that it teaches small bits without building a game project. Even with all of my learning I still had not created a whole game, and I do know that in order to have a decent game career portfolio I will need to have at least one completed game (though probably two or more) to even be considered.

So I took a step back from all the fun advanced 3D stuff for a bit and am proud to say I'm making progress (translation: nearly completed) on my Pong clone. I will post the game itself and implementation details soon!

In other news, my wife and I finally purchased a Nintendo Wii since the retail price came down to $200. Wii Sports and Boom Blox are pretty cool. And just a quick news update in case you missed it- the Unity game engine is now available as a free download (was supposedly $199). Check it out and let's create some awesome games!

Sine Language Lesson, Part 2

In Part 1 of this post I discussed some useful applications of the sine function without really delving into the details of how it works. Specifically, we focused on the equation y = sin(x). Here is a more useful variation of the sine function as demonstrated in the Ocean Waves demo:

y = A * sin(K*distance - F*time + S)

• A = amplitude
• K = angular frequency
• F = time frequency
• S = shift

Amplitude represents the height of the wave; it typically ranges from -1 to 1 but can be set to an arbitrary value (e.g. set A = 25 for the wave to range from -25 to 25). The angular frequency represents how quickly the wave travels vertically. The time frequency represents how quickly the wave travels horizontally; note that F*time can be omitted from the sine function to view a static snapshot of the wave at a point in time but is included in the Ocean Waves demo to provide the effect of a wave in motion. Finally, the shift parameter allows us to move the wave by a horizontal offset so it starts from a new position (e.g. setting S = -π/2 would map it to the cosine function).

The Point Light demo from Part 1 sets the light source position's Z-coordinate using a simple sine function and then calculates the X- and Y-coordinates as sine functions using the computed Z value as the distance parameter. The Ocean Waves demo combines multiple sine waves to achieve the illusion of irregularity (not all waves in the ocean are the same height and hit shore at the same regular time interval). For example, to apply the effects of y = sin(x) and y = 12 * sin(3x), we can simply write y = sin(x) + (12 * sin(3x)). Observe that the two functions are added together. Watch the web preview of Combining Sine Waves to see the concept in motion.

I hope this post encourages you to investigate some potential uses of sine/cosine functions, as well as return to Part 1 if you missed the demo programs. It seems some things we learned in high school actually did turn out to be useful!

Staying Motivated

I can't believe I started this blog more than six months ago. I remember thinking initially, after seeing many game development blogs trail off after just a couple months, that I would surely put out at least five posts every week. Ha! Let's just say I may have been a little ambitious. It's easy to push forward full steam when something is new, but the question of true dedication comes when the going isn't so easy.

I've seen forum posts regarding burnout on the game development dream and even noticed one of the blogs I followed (and had linked here) seems to have disappeared. So... how do you stay motivated when your enthusiasm wanes? I think part of it is remembering what you enjoyed about it (whether it is game development or another hobby) in the first place, and looking forward to what you will be able to do with practice. In my case I'm reading through a very dry, technical graphics book right now and sometimes it is flat-out boring; but I know that by reading it and working through the examples I will in time be a better game developer.

Quite honestly, I think everyone loses their enthusiasm at times. If you stay away from an activity too long it can be hard (though not impossible) to get back into it, and if you play with something too long it can start to feel like work. But the best approach is to just stick with it. Don't give up!

Check out Brenda Brathwaite's blog post for more inspirational thoughts on staying motivated. I'm proud to say that even though I'm not posting as frequently, I am still learning new graphics tricks (today was Direct3D meshes) and will not be disappearing any time soon!

Sine Language Lesson, Part 1

I've had this idea ruminating in my mind for some time now. Math is a big part of graphics development and I'm certainly no expert, but I wanted to show off some cool things that can be done with sine waves. This part introduces the concept and shows some fun demo programs you can play with; part two will delve into the inner workings of the demos, which have been adapted from Frank Luna's Introduction to 3D Game Programming with DirectX 9.0c: A Shader Approach.

You may remember from your high school Trigonometry class (don't worry if not, it was a long time ago for me too!) those two periodic functions, sine (pronounced "sign") and cosine ("co-sign"). They're essentially the same function and you could map one to the other with a slight shift. Cosine has some unique applications of its own, such as determining light intensity based on viewing angle, but the demos below will focus primarily on sine waves.

Credit: Wikimedia Commons

Notice a few interesting properties from the graph above. One is that a sine wave repeats itself every 2π (π ≈ 3.14159) or 360 degrees along the X-axis. Another is that it oscillates between the Y values -1 and 1. We write the function y = sin(x) to indicate the Y value as a function of X; see from the graph above that Y = 0 when X is any multiple of π and Y is either 1 or -1 (the peaks and valleys) when X is an odd multiple of π/2.

Point Light Demo - Download Program!

This demo shows how sine waves can be used to animate a light source. Use the specified keys to combine waves, creating a variety of unique horizontal and vertical motion paths.

Before learning this elegant method, my approach to animating an object that sways back and forth, or moves repeatedly up and down along a pole, was to use code like this in my update loop:

    static bool moveUp = true;
    if (moveUp) 
    { if (shipPos.y < 100) shipPos.y += value; else moveUp = false; }
    else 
    { if (shipPos.y > -100) shipPos.y -= value; else moveUp = true; }

With sine waves, this code reduces simply to shipPos.y = 100 * sin(x)! Notice that I multiplied by 100 to get the desired range instead of the standard oscillation from -1 to 1.

Ocean Waves Demo - Download Program!

This demo illustrates the effects of adding sine waves and two different wave types, circular and directional. Use the specified keys to play with parameters and change the wave patterns.

As with the Point Light demo, you will need to have DirectX (from Windows Update) installed in order to run the program.

These are just a couple applications of the sine function. Because of its periodic repetition, it could have many potential uses; some fellow GCG forum members cited their implementations of a 3D carousel and a wavy spaceship flight path as additional examples.

I hope you enjoy the demo programs of this post, though I admit I still need to learn better methods of input handling. Part two will describe wave alterations, based on the Ocean Waves demo, in greater detail. Until then, feel free to let us know: What's the coolest thing you've done with sine/cosine waves?

Quick Random Update

So, Gamasutra is on Twitter too. You may recognize them, or at least you should if you have any business as a video game developer/designer. Gamasutra is one of the most popular game-oriented websites with full-featured articles and commentaries on the state of the industry, game reviews, yadda yadda yadda. So now you can check out not only the website, but also the Twitter feed. Oops, sorry if that last link didn't work; I suppose I should have linked it the proper way: @Gamasutra!

Enough hype, this post is mostly me checking in for a quick progress update. I blasted through reading about lighting, textures, blending, and stenciling in my Direct3D book and then found out the exercises required a fair deal of re-reading. Lesson learned, I have to work through chapter exercises before moving on to more difficult chapters! The same applies to the Game Design Concepts course I'm taking -- it's much easier to keep up with the readings than work through the exercises, some of which I have to skip. FYI, you can follow discussion for the course on Twitter too; just search for #GDCU!

The topic of my next post will be the power of sine waves. Yep, I'm talking about those tricky oscillating waves you learned about way back in high school. I've found some interesting applications and want to show off some of the cool stuff you can do with them. And now that I'm finally understanding the basics of HLSL (High Level Shader Language) shaders, the part that tripped me up big time in the last book I read, you can expect some posts on that stuff too.

Just curious, when was the last time you used something from high school you never thought you would need again? What's the trickiest math you've used in game development, and does calculus ever figure into the equation (pun... fully... intended!)?

The Problem with the Mythical Black Box

In programming, we occasionally make use of something known as a "black box." This Mythical Black Box is any library or chunk of code written by someone else that allows us to abstract a problem so we don't have to understand the details of solving it. For example, if we pass the values 3 and 4 to a "calculator black box", which might be a class library written by another developer, we would expect it to return the value 12 for multiplication. We don't care how it works internally, whether it computes 3+3+3+3 or 4+4+4; all we care is that it returns the correct value. A black box diagram for an encryption algorithm might look something like the following.

Password => { Encryption Black Box } => Encrypted Password

Jeff Atwood of Coding Horror has recently expressed seemingly contrasting views on this topic, both touting and refuting the benefits of abstraction. And for good reason, because it can be a good thing or a bad thing depending on whose library you choose. For one thing, you should never introduce code into your project if you aren't 100% certain it will fulfill its promise. Many developers (myself included) prefer the "roll your own" method for most tasks simply because you know you can trust your own code (not that it will be error-free, just that it won't be malicious). But sometimes it makes sense to use a well-tested library from another developer, such as the ever-popular JQuery library for Javascript development. In such cases I suggest ensuring you trust the developer (e.g. they're well known, such as Microsoft, and would be ridiculed if the library failed) or that you have full access to the source code. Many open source projects are reviewed by large numbers of people such that bugs are caught and fixed quickly.

Unfortunately, even if you take my suggestions your black box may someday fail. The whole reason I bring this up is that I faced this exact problem with my SkyCop demo. I developed it using the Common Files Framework presented in Engel's Beginning Direct3D Game Programming, 2nd Edition and provided in a specific version of the Microsoft DirectX SDK. When I ugraded to the most recent build of the SDK, my demo suddently stopped working and I started getting reports of others not being able to run it either. I ran into numerous problems trying to get it to work with the latest DirectX SDK and believe the Common Files Framework was removed altogether in the latest version. Having relied too heavily on that framework, I wasn't sure how to resolve the compilation errors and feared I would have to scrap the project altogether.

Fortunately, in his Introduction to 3D Game Programming with DirectX 9.0c: A Shader Approach, Frank Luna fully describes a working game framework instead of glossing over it and providing another black box. I was able to essentially rip out the core of my SkyCop demo, converting it to use the new framework, and am pleased to have an updated demo below that should work on any DirectX 9 (or newer) version, but let me know if you still have any trouble running it.

SkyCop v1.1 Demo Download

Black boxes can be a good thing when they're well-written by a trusted developer, but it's also a good idea to review the code (if possible) and at least have a basic understanding of how it works. In my case, as a learning newbie, I was happy to avoid the initial complexity and that later bit me from behind. One thing to keep in mind, though, is that black boxes come in many shapes and sizes. My black box was a game framework but the concept could also apply to a game engine, a single portion (Renderer, Physics, Sound, etc.) of a game engine, or some other game components I'm not even aware of yet.

Do you know what's going on under the hood of your game framework/engine? What black boxes are you relying on to develop your games?

June Monthly Checkup

Yep, another month has come and gone. Sadly I still don't have a finished game, but I do have some cool demos to show off in upcoming posts. I'm up to chapter thirteen (of twenty-two) in Luna's Introduction to 3D Game Programming with DirectX 9.0c: A Shader Approach and am learning a lot, but it takes a while to work through the chapter exercises. I'm also in the process of taking Ian Schreiber's free online game design course. My portfolio website is nearly completed; I just need to find a better host before posting the link here on GDJ.

So it's been yet another busy month of learning and experimenting, all while prepping for our big move to NC in August. After we get settled I plan to join the Triangle IGDA chapter so I can get serious about that whole networking thing.

Speedrunning

The Escapist recently caught my attention with this article on speedrunning. If you're not familiar with the concept, some people spend WAY MORE time trying to master games than you or I do. In fact, they spend countless hours and thousands of lives (digital lives of course) trying to master game levels, determining the most efficient paths to complete a level - or in some cases the entire game - in the shortest time possible. There are plenty of other worthy examples on YouTube; just search for "speed run" after the title of your favorite video game.

Would you have the patience to master this??? I doubt I would.

First Day of Class

As mentioned some time ago, Ian Schreiber's Game Design Concepts course began today and I personally believe it's off to a great start. I love reading things that make me think in a new way or help me understand concepts with simple examples. For example, have you ever played a game called "three to fifteen"? I had never heard of it and bet most of you haven't either, but once you read that first lesson you'll realize you've probably played it many times!

I know this image is far below par in terms of graphical work typically posted on this blog, but it's actually a very rudimentary game design I created in a matter of two minutes! Ian describes how simple it can be to create a game, and honestly anyone can do it. I call my game "Rat Race", with the concept being that two rat tokens are placed at the start and their goal is to be the first to get to the cheese. Each player must roll the die and get the numbers in order to advance (e.g. roll a 1 to advance to place "1", then roll a 2 to advance to "2", etc.) sequentially all the way from space "1" to the goal at "5". If a player rolls a "6" they send their opponent back to the start position but also forfeit their turn. They do not advance if they roll a number out of turn (e.g. roll anything other than a 1 from the start position).

As Ian points out, mine isn't necessarily a good game, but it proves anyone can do it and I look forward to learning more about designing good games.

Game Development Process

I read the article How a Game Gets Made in the free online edition of Game Career Guide magazine some time ago. It's quite a good read for anyone interested in the process, and I believe it's important for me as a programmer to understand what role I will someday fill as a game developer. What follows is a transcription of notes I took while reading to summarize the process; note that not all possible roles are covered and the steps are not listed in sequential order.

• Preproduction
  This is the phase where core game design decisions are made, game elements are prototyped, and the game story is developed. A basic prototype of the game is developed quickly and shown to the producer who either scraps the game or gives it the go-ahead to move into production.
  • Designers document objects, characters, levels, enemies, NPCs, etc. for the game
  • Artists work on character designs, level concept art, and storyboarding
  • Programmers work on tools, document technical specs, and perform risk assessment
  • Producer determines a production schedule and milestones


• Production
  This is the phase where the game is fully developed based on preproduction planning and detailed design documents. Some experimentation is allowed as long as it improves the game. The development team follows a "production methodology" to keep track of and divvy up remaining work.
  • Must determine dependencies early to complete child tasks sooner and keep teams independent (max efficiency)
  • Artists get a head start creating/texturing character models and world props (cars, buildings, crates, etc.)
  • Animators generate animations for character models
  • Programmers work on core functionality and data manipulation
  • Level designers create rough sketches of all levels in the game
  • System designer plugs in characters and tweaks animations and gameplay
  • Sound designers work on effects, getting voice actors for character dialog, and music tracks
  • Team meets periodically to review overall progress of the game
  • At 2/3 of production timeline additional staff is brought in for QA testing; most features are implemented so it's time to squash bugs


• Postproduction
  Postproduction is all about getting the game into the hands of consumers.
  • Final build of the game (the Gold Master Disc) is printed
  • Marketing publicizes the game to popular game websites, magazines, and as TV ads
  • Publisher handles game manual and box manufacturing, and has a distributor set up to deliver the game to retail stores
  • Developers may be tasked with creating donwloadable content (characters, costumes, levels, etc.) to update and extend the game

May Monthly Checkup

This has been a busy and difficult month with some unexpected events that nearly derailed my resolve to continue this journey. Nonetheless, I press onward, but with the realization that I may not be able to post as frequently or accomplish goals as quickly as hoped. So this is a pretty informal checkup this month and I've decided not to restate previously completed goals in favor of highlighting tasks that still need work.

The foremost goal in my mind is to complete a full game. I've started reading a new book that I plan to review once I've completed it, and the exercises of chapter five have me working on a 2D space shooter. Following completion of this mini-project I will start work on a PONG clone; the physics of a ball in motion (including collision detection) are quite interesting to me and may require further study.

I have been playing more games lately but don't own a fancy new console yet; picked up three older games for the original XBox (only cost $20 for the set) and want to get a Nintendo Wii at some point. Meanwhile, I have updated my old resume and started a portfolio site that is still a work in progress.

So that's about it for progress updates this month. I think my main takeaway from this month is that it's not how quickly you run the race... just that you eventually finish... and Rome wasn't built in a day. Finally, for some fun reading, check out The Escapist online magazine. They've got some cool game-related articles and a pretty cool RSS feed. Check out my devious guide for help with RSS.

Serious Games... Seriously?

As I continue reading and learning more about games, there's one categorical phrase I see repeatedly that always stops me in my tracks: Serious Games.

Every time I see it I have to wonder, "What is a serious game?" To me, the concept of a GAME always implies (or at least makes an attempt at, though some fail miserably) a connection to... FUN! Despite my limited research, I've learned that the phrase describes the type of games intended for simulators and educational purposes. In other words, a flight similator used by the Air Force to train new pilots might be considered a member of this category.

Perhaps I'm making too big a deal over terminology, but I think educational programs of this type should simply be called "simulators." But then someone might argue that they enjoyed the simulator, and so to them it is a game! :) Nonetheless, the phrase just always hits me as an oxymoron.

Have you played any serious games lately? Would you say they were fun?

Staying Busy

Father forgive me for I have sinned... it's been two weeks since my last post. Wait, two weeks?!? I know, it's terrible and I am ashamed (not terribly, but a little bit). Rest assured, despite my recent silence some good things are happening.

Firstly, I'm reading a new book titled Introduction to 3D Game Programming with DirectX 9.0c: A Shader Approach. As I learned last time, I'm going to avoid posting a book review until I've read it all the way through, but I will say that I'm on chapter six (of twenty-two) and learning some really cool things I plan to highlight in future posts.

Secondly, I've been playing some cool free online games over at Armor Games. One of my personal favorites is Crush the Castle and my wife, who loves hedgehogs, has been hooked on Hedgehog Launch. Check 'em out!

Finally, I've decided to create a clone of the classic Atari game Pong. For those who never played, you can play a version in your browser here using pop-up windows! Pong is a simple game that shouldn't require advanced concepts. I'm hoping to dress it up with some nice textures and add a twist or two.

So there's a few things keeping me busy. Stay tuned for Pong updates!

April Monthly Checkup

Has it been another whole month?!? Where does the time go? Here's my current goals checklist on my journey towards becoming a Game Developer.

	Create a finished game. I did some good work on my SkyCop demo, finally getting a playable demo posted. I plan to design a smaller-scale (possibly 2D) game at some point but need to work on learning more fundamentals first.
	Use personal projects to test different rendering techniques and programming methods. Check! See the SkyCop reference above.
	Continue learning and be competent enough to explain design decisions. In addtion to keeping up on the latest feeds for major game sites and participating in a couple forums, I've purchased five new books! Admittedly three of them were recommended for Ian Schreiber's Game Design Concepts course. The one I'm probably most excited to dig into is Game Coding Complete, which I'm hoping will be a good reference for proper structure and best practices. Despite these positive steps, I can't mark this item completed just yet. I am still learning, after all.
	Start networking! I'm staying active in a couple forums and planning to participate in a local IGDA chapter. The only problem is the local Columbus chapter (which I would still be a couple hours away from) appears to not be meeting at this time, so I may have to wait to participate with the Triangle chapter after we move to NC later this year. Attending the SIEGE conference is still a possibility, or I might consider a visit back up this way to check out the GameX Games and Media Expo.
	Play more games! I haven't bought a shiny new game to play yet, but I have tried out some independent games on Armor Games. Crush the Castle, where you get to use a trebuchet to destroy castles, is actually a lot of fun! Nonetheless I think I need to get better versed in newer games to mark this item completed.
	Update the outdated resume. This is a new goal and a worthy one I think will help me focus even better on my target. Darius Kazemi has some great tips on writing a resume for a game company and I plan to update my resume soon.

"If you wanna be rich, you gotta do rich people stuff." - Dave Ramsey
"Wanna be a Game Developer? Do Game Developer stuff!" - Me

See any holes in my plan or have useful tips/pointers to help get me further along? Post a comment!

Point-Plane Collision Detection Explained

In my previous post I presented a function for detecting collision of a point in 3D space with a plane (surface of an object). It works well enough in my SkyCop demo because all I need to check is if the tip of the primary ship intersects the surface of other ships. Here's a description of the code, broken into seven steps to help you understand this basic form of collision detection.

1)	Understand the Plane Equation: Ax + By + Cz + D = 0
	The plane equation tells us that a point (x,y,z) is on a plane having normal vector (A,B,C) and distance D from the origin when Ax + By + Cz + D = 0. If we plug in A, B, C, D, x, y, z and get any value other than zero, the point (x,y,z) is not on the plane. Also note that since the dot product of vectors (A,B,C) and (x,y,z) equals Ax + By + Cz, we can rewrite the Plane Equation as DotProduct(N, P) + D = 0 for N=(A,B,C) and P=(x,y,z).
2)	Get the collision surface's normal vector.
	As noted above, in order to detect if a point is on our collision surface (such as a wall we want to prevent the player from running through), we need to know the normal vector perpendicular to the surface. A normal vector is computed by taking the cross product of two vectors on the plane. The simplest 2D plane we can create in 3D space is a triangle with three vertices (call them vP1, vP2, and vP3) and I will focus on a triangular collision surface for simplicity. We compute the normal vector by generating a vector from vP1 to vP2 and another from vP2 to vP3 and then take the cross product of those two vectors to obtain the normal vector. Finally, the normal vector is normalized (made to have a length of 1.0) to simplify calculations. vN1 = (vP2 - vP1); vN2 = (vP3 - vP2); D3DXVec3Cross(&vNormal, &vN1, &vN2); D3DXVec3Normalize(&vNormal, &vNormal);
3)	Get plane distance using the Plane Equation.
	Using our revision of the Plane Equation, DotProduct(N, P) + D = 0, we can solve for D to get D = -DotProduct(N, P). So we compute D by plugging in the normal vector and any point on the plane; any of the triangle surface's three vertices will suffice. d = - D3DXVec3Dot(&vP1, &vNormal);
4)	Classify the start and destination points.
	Now that we've determined the collision surface's normal vector and distance from the origin (A, B, C, and D) we can use the Plane Equation for something really cool: determining if a given point lies on the plane! When we plug a point P=(x,y,z) into the left side of our revised plane equation DotProduct(N, P) + D we get a result value, p. If p > 0, the point is in front of the plane. If p < 0, the point is behind the plane. And of course we know that if p = 0 the point lies on the plane. Since we're only concerned with detecting collisions for moving objects, there must be a start position where the object moved from (pstart) and a destination position (pdest) to which the object is moved. The trick is realizing that a collision only occurs if these two positions have different locations in relation to the plane -- if they're both in front of or both behind the plane, no collision occurred and we can return from the function. p = (D3DXVec3Dot(&vNormal, &pStart) + d); if ( p > 0.0f ) pStartLoc = PlaneFront; else if ( p < 0.0f ) pStartLoc = PlaneBack; else pStartLoc = OnPlane; p = (D3DXVec3Dot(&vNormal, &pDest) + d); if( p > 0.0f ) pDestLoc = PlaneFront; else if (p < 0.0f ) pDestLoc = PlaneBack; else pDestLoc = OnPlane; if (pStartLoc == pDestLoc) return false;
5)	Get the ray.
	At this point we know that an intersection did occur! Great, but there is a small problem; we don't know where it occurred, which is equally important. The plane that was crossed is an infinitely expanding plane in 3D space, often called a hyperplane, so we need to check if the collision occurred within the bounds of our collision surface's borders. Computing the vector, called a "ray", from our object's start position (pstart) to its destination position (pdest) helps determine where the collision occurred. The vector is normalized to simplify calculations. ray = pDest - pStart; D3DXVec3Normalize(&ray, &ray);
6)	Get the intersection point.
	Vector math tells us that we can access points along a ray from pstart to pdest using the formula (pstart + ray * t). Since we know that a point along our ray from pstart to pdest definitely intersects the plane, we use the plane equation to determine the value of t below. Note that I've plugged the intersection point (pstart + ray * t) into the Plane Equation instead of a generic (x,y,z) because we know that point lies on the plane. I've also renamed pstart to "s" and the ray to "r" for brevity. A(sx + rx*t) + B(sy + ry*t) + C(sz + rz*t) + D = 0 A*sx + A*rx*t + B*sy + B*ry*t + C*sz + C*rz*t + D = 0 DotProduct(N, s) + t*DotProduct(N, r) + D = 0 t = - (DotProduct(N, s) + D) / DotProduct(N, r) We've already computed the normal vector N=(A,B,C) as well as the plane distance D and the ray so we can calcuate t. Then we plug it into our formula to get the actual intersection point on the plane. t = - (d + D3DXVec3Dot(&vNormal, &pStart)) / D3DXVec3Dot(&vNormal, &ray); intersect = pStart + (ray * t);
7)	Determine if intersection hit the collision surface!
	We're almost there! We determined the intersection point where our object collided on a hyperplane corresponding to the collision surface. So the final question is, "Does the intersection point fall within the bounds of our collision surface?" In order to answer that question we compute vectors from the intersection point to the surface vertices and measure the angles between those vectors. If we form a complete circle, we know the point lies within the bounds of our collision surface! v1 = intersect - vP1; v2 = intersect - vP2; v3 = intersect - vP3; D3DXVec3Normalize(&v1, &v1); D3DXVec3Normalize(&v2, &v2); D3DXVec3Normalize(&v3, &v3); // Angles around intersection should total 360 degrees (2 PI) thetaSum = acos(D3DXVec3Dot(&v1, &v2)) + acos(D3DXVec3Dot(&v2, &v3)) + acos(D3DXVec3Dot(&v3, &v1)); if (fabs(thetaSum - (2 * D3DX_PI)) < 0.1) return true; else return false;

There are a couple caveats to this method of collision detection. The first is that the triangle surface vertices vP1-vP3 must be specified in clockwise order so the surface normal vector is computed correctly. We also have to allow for a small margin of error in the calculation of the sum of angles due to the lack of floating-point precision. Finally, I've read that this method should only be used on convex (as opposed to concave) polygons which do not curve inward on themselves.

I know this is very low-level and there are probably simpler ways to do it (bounding boxes/spheres come to mind...), but it's kinda neat to see how the math makes it work! Please feel free to post comments/questions to let me know what you think of this tutorial. I hope it provides a clearer understanding of what's going on under-the-hood in basic point-plane collision detection.

Quick 'n Dirty Point-Plane Collision Detection

A couple weeks ago I was in a frenzy to implement collision detection in my SkyCop demo. Sure, I planned to go back and study it in more detail at some point, but for the moment I just wanted to get something done so I could avoid flying through enemy ships and start blowing them up. After a few days of searching, I quickly realized that collision detection is no trivial task; it's a field of study all on its own! I started with this flipcode article that served as a good introduction but left me a bit confused. After more research and trial-and-error I had a working example function that I would like to share with anyone needing to feed that same primal urge to get something working quickly.

The function, written in C++ for Direct3D 9, determines if a single point will cross a triangular plane (parameters vP1-vP3 specified in clockwise order). Parameter prevPos is the initial position your character/camera/object moves from and curPos is the position to which it will be moved. For example, if you want to detect if an FPS player will collide with a wall, you would call this function with the camera's initial position as prevPos and its predicted next position [prevPos + (speed * direction)] as curPos. Submit a comment if you have any questions, and keep in mind I will discuss the code in detail in a future post.

Btw, I'm sure there are engines that handle all this stuff for you, but since I haven't gotten into those yet it was a nice exercise for me. And I do apologize for the ugly formatting. I'll work on making code selections look better in future posts!

enum PlanePosition
{
   PlaneFront,
   PlaneBack,
   OnPlane
};

bool IntersectsTriangle(D3DXVECTOR3 prevPos, D3DXVECTOR3 curPos, 
          D3DXVECTOR3 vP1, D3DXVECTOR3 vP2, D3DXVECTOR3 vP3)
{
    float p, d, t, thetaSum;
    PlanePosition prevLoc, curLoc;
    D3DXVECTOR3 ray, v1, v2, v3, vNormal, intersect;
 
    // Compute normal vector for the plane
    v1 = (vP2 - vP1);
    v2 = (vP3 - vP2);
    D3DXVec3Cross(&vNormal, &v1, &v2);
    D3DXVec3Normalize(&vNormal, &vNormal);

    
    // Compute plane distance
    d = - D3DXVec3Dot(&vP1, &vNormal);

    
    // Classify positions using planar equation
    p = (D3DXVec3Dot(&vNormal, &prevPos) + d);
    if ( p > 0.0f ) prevLoc = PlaneFront;
    else if ( p < 0.0f ) prevLoc = PlaneBack;
    else prevLoc = OnPlane;

    
    p = (D3DXVec3Dot(&vNormal, &curPos) + d);
    if( p > 0.0f ) curLoc = PlaneFront;
    else if (p < 0.0f ) curLoc = PlaneBack;
    else curLoc = OnPlane;
        
    if (prevLoc == curLoc) return false;
   
    // Crossed the plane, did intersect occur inside triangle?
    // Get normalized ray
    ray = curPos - prevPos;
    D3DXVec3Normalize(&ray, &ray);

    
    // t = point along ray where intersection occurs
    t = - (d + D3DXVec3Dot(&vNormal, &prevPos)) 
        / D3DXVec3Dot(&vNormal, &ray);

    
    // Get intersection point on the plane
    intersect = prevPos + (ray * t);

    
    // Determine if intersection is within triangle plane
    // Angles around intersection should total 360 degrees (2 PI) 
    v1 = intersect - vP1;
    v2 = intersect - vP2;
    v3 = intersect - vP3;
    D3DXVec3Normalize(&v1, &v1);
    D3DXVec3Normalize(&v2, &v2);
    D3DXVec3Normalize(&v3, &v3);
 
    thetaSum = acos(D3DXVec3Dot(&v1, &v2)) 
             + acos(D3DXVec3Dot(&v2, &v3)) 
             + acos(D3DXVec3Dot(&v3, &v1));

    
    // If sum == 2PI we have an intersection!
    if ((thetaSum >= ((2 * D3DX_PI) - 0.1)) && 
        (thetaSum <= ((2 * D3DX_PI) + 0.1)))
    {
        return true;
    }

    
    return false;
}

That Whole Networking Thing...

So, I'm on Twitter too, and I have mittens to thank for it. I read his GameDev.net post some time ago, have been kicking the idea around and finally signed up. The cool thing to me is that Twitter can be a great resource to see what's going on in the game industry from people who just enjoy working on games. Click the link above for a list of industry professionals you can follow on Twitter!

This brings me to one of my weakest points on my original checklist to becoming a game developer, which is also one of the most important to getting a job in the industry: networking. I've already been fortunate to meet some interesting people like Matt Zitterman and Grant Shonkwiler on the Game Career Guide forums, and I believe this is another step in the right direction to getting connected.

It's not always WHAT you know, but often WHO you know. What are you doing to get connected?

Play the SkyCop v1.0 Demo!

I haven't been posting as frequently lately, but for good reason. I've been hard at work on SkyCop, which I introduced about a month ago. Keep in mind this is nowhere near a full-featured game, which is why I'm calling it a demo. But it is playable and can be "won" by destroying all red enemy ships, which is pretty fun for at least a couple minutes! :)

Features include:

• 3D Movement/Rotation
• Speed Boost (multi-texturing)
• Energy Shield (alpha blending)
• Basic Collision Detection
• Enemy Target Indicator
• 3 Backgrounds
• 2 Camera Modes

Some obvious enhancements include the addition of music, sound effects, more guns, explosions, and artificial intelligence so the enemy ships can fight back! Alas, these will come in time as I continue to learn. Click the link below to try it out (press number 1 in the program for controls) and let me know what you think. Thanks for checking it out!

Download SkyCop v1.0 Demo

System Requirements: Windows OS, DirectX 9.0 runtime (available from Windows Update or searching online)

Important Disclaimer: I did NOT create the background images in the program. I used brightday1, brightday2, and grandcanyon located here, where they are listed as coming from free or (L)GPL sources.

Game Design Concepts

Professional game designer and teacher Ian Schreiber will be presenting an online course via his blog this Summer. From his introduction, it looks to be an interesting college-level course without the college price tag. The course will not cover game programming, but if you're at all interested in game design this is sure to be a great learning opportunity. Class starts June 29th. Check out his blog to learn more!

Ian Schreiber's Game Design Concepts

Winding Road Ahead

Credit: nwebster!

Tonight I was awakened to the importance of reading a book in its entirety before posting a book review. My thrill of chapters 6-8 on the concepts of Direct3D animation and texturing in Beginning Direct3D Game Programming, 2nd Edition has quickly been eroded by the exponential complexity of chapters 9 and 10 on the High-Level Shader Language (HLSL). I am excited to learn about lighting/shading, environment mapping, bump mapping, reflection, and other techniques described in these chapters. But two frustrating evenings of incomprehensible reading have led me to conclude, as noted by a few other reviews on Amazon as well, that the book is not truly written with the beginner in mind. So I'm taking a new path.

I'm shelving the book... for now. I think it is still a good reference (up until chapter 9 anyway) and may be of use once I gain a better introduction to the concepts described in the later chapters. Until then, there are other resources, such as DirectXTutorial.com and the SDK Documentation itself, that will hopefully provide a more gradual learning curve. Could this be a major turning point in my journey to become a Game Developer? Surely the resources I select to learn Direct3D will affect my growth, but only time will tell...

What resources have you used for learning Direct3D? What worthwhile programming reference/guide would you recommend to someone who has never written a single line of Direct3D code?

Monthy Checkup

It's been a whopping two weeks since I started this blog, but it's also the end of the month, which means it's checkup time! At the end of each month, I will review my incomplete goals and determine how I'm progressing toward becoming a Game Developer. You may recall some of the following from my Inspiration post and I've added a few new goals too.

	Create a finished game. I'm still in the process of learning Direct3D and playing with various techniques. SkyCop is a wide-open testbed for experimentation, but once I feel more confident in my skills I will design a smaller-scale game that I can actually finish. I've read numerous articles stressing the importance of showing potential employers you can create a finished product.
	Use personal projects to test different rendering techniques and programming methods. Check! See the SkyCop reference above.
	Continue learning and be competent enough to explain design decisions. I've exponentially ramped up my reading of game development blogs and articles on major sites like GameDev.net and Gamasutra. I want to get another book or two to learn technical/design concepts; I've heard Game Coding Complete is a good reference.
	Start networking! I've started participating in the Game Career Guide forum; they have a bunch of bright and friendly people willing to help newcomers to the scene, and I'm hoping I will be able to contribute positively to the community. I'm also learning about different game development conferences and considering a trip to GDC next year or possibly attending SIEGE this year.
	Play more games! I love playing video games, and remember the thrill of playing multiplayer Quake 2 and Unreal Tournament back in the day. It's hard to find the time these days, but in order to understand modern game concepts I really should buy a new game. That's my rationalization, anyway ;)

Dave Ramsey, creator of Financial Peace University and an awesome motivational speaker, says "If you wanna be rich, you gotta do rich people stuff." Likewise, if you wanna be a Game Developer, you gotta do Game Developer stuff! I found these testimonies of actual developers/designers working in the field to be quite interesting. They're a good reminder that there's more than one way to break into the games industry, and I know that I can do it!

Recommended Reading: Artificial Stupidity

Gamasutra recently featured an article titled Intelligent Mistakes: How to Incorporate Stupidity Into Your AI Code by Mick West. It's a great read that I highly recommend for anyone, including non-programmers, regarding the topic of Artificial Intelligence.

For the uninitiated, Artificial Intelligence (AI) is the logic used in a game by your computer "opponent". The fun part of playing a video game in the absence of human vs. human interaction is the ability to play against the machine, which simulates the actions of a human opponent. However, knowing that a computer relies on logic, mathematics, and the ability to perform a million computations per second, there is no reason for the computer not to win every single time.

It wouldn't be fun to play against an opponent that never loses, which is why we need to decrease the computer's IQ! But as Mick points out, simply reducing the number of computations the machine is allowed to perform before making a decision would cause it to make abnormal blunders; it would be too easy to defeat and once again, not fun. Instead, a better approach is for the AI to perform its normal amount of computation and earnestly try to win, occasionally making a move that is more advantageous to the human player. If the human player takes advantage of these "thrown a bone" moves frequently enough, they have the opportunity to win. Yet they can still enjoy the challenge of playing against an opponent that is trying hard to win (and will win if the player fails to take advantage of certain opportunities).

My quick summary hardly does it justice. Read the full article now!

Program-ictionary

This post is dedicated to my good friend over at Heart Like Jesus blog, who recently reminded me we don't all speak geek. For those of us who do, even seemingly-simple concepts can deteriorate in the absence of a common terminology. The table below takes a stab at defining some key phrases used on this blog.

Phrase	Definition
C++	Currently the most common game programming language.
OOP	Object Oriented Programming. This is a conceptual way of structuring code to represent objects in the real world (e.g. creating a Person class that has properties such as Name and Age).
DirectX	Microsoft's collection of APIs for multimedia development for Windows-based systems. A few specific APIs include Direct3D (for graphics), DirectShow (for presentations), and DirectSound (for audio).
Direct3D	The DirectX API for creating computer graphics.
API	Application Programming Interface. An API simplifies work for programmers by providing them with a list of functions they can use to perform specific tasks in a program.
Pixel	Short for picture element, a pixel represents a single dot displayed on your computer monitor.
Texel	Short for texture element, a texel represents a single dot displayed in a texture (image) file.
Texture Mapping	See my post Texturing Fundamentals for a definition of textures. Texture mapping is the process of texturing.
Point	A position in 2-dimensional space specified by a horizontal X value and a vertical Y value.
Vertex	A position in 3-dimensional space specified by a horizontal X value, a vertical Y value, and a depth Z value.
Direct3D Vertex	A vertex that may contain properties (such as color, texture coordinates, etc.) in addition to a position (x,y,z) value.
Vertex Buffer	A hardware-dependent structure, accessible via Direct3D, to hold a list of vertices.
Render	The act of drawing content from a vertex buffer to the screen.
Object Geometry	Set of vertices that make up a 3D object.
Geometry	Math stuff I learned freshman year in high school and wish I could remember better now. Very important for graphics development!

This list is by no means comprehensive, but it's a start. I'll try to make sure I define new concepts clearly and am always open to correction from wiser experts. It's been said that blog comments are often better than the original blog post, and I'm excited to see if that proves true on GDJ!

Texturing Fundamentals

In my instroduction to SkyCop, I briefly mentioned textures without describing what they are or how to use them in game development. I fear I may still not be capable of providing a full explanation, but here is what I know so far.

The tricky part of defining the word "texture" is that it can be both a noun AND a verb. That is, you use a texture file (like the image at left) to texture an object. The process of texturing can be thought of as clothing an object. No object in a Direct3D game is particularly interesting without some color or texture applied to it, and textures are the most common means of adding realism to our favorite games.

To understand how a 3D object is textured, consider the SkyCop ship below. Every Direct3D object starts as a wireframe model having a certain number of vertices. Each vertex (think point) consists of a position (x, y, z) value and a texture coordinate (u, v) value. The texture coordinate points to a position in the texture file; the point referenced in the texture file is called a texel (short for texture element). Direct3D is able to wrap the texture onto the object by using a universal address scheme for texture coordinates; the values range from 0.0 to 1.0 inclusive, both horizontally and vertically. As you can see in the image above, the top-left texel is represented by texture coordinate (0.0, 0.0) and extends to the bottom-right texel at coordinate (1.0, 1.0).

So to map the tip of the SkyCop ship with the green tip in the image, we tell Direct3D to map the vertex at the tip of the ship with horizontal u = 0.5 and vertical v = 0.0. Similarly, we map the left and right wing tips with (0.0, 0.5) and (1.0, 0.5) respectively. Are you starting to see how the texture is wrapped onto the wireframe model?

I was planning to describe the SkyCop background texturing method, but this post is already getting lengthy and I think I have more to learn on environment mapping to get it done "the right way" first. Note that this post barely touched the basics of texture-mapping. There's a lot more to learn about how textures can be used to create cool effects, and this will likely be the focus of upcoming posts.

A Really Simple, Devious Guide to RSS

This is one of very few selfish posts on this blog, as you will soon see. If you already know what RSS feeds are, you may be more interested in skipping to one of my more technical posts. For the curious or those who, like myself just a year ago, have never used RSS, I urge you to continue reading and learn of my devious plans...

What is RSS? Wikipedia tells us that "RSS (abbreviation for Really Simple Syndication) is a family of Web feed formats used to publish frequently updated works—such as blog entries, news headlines, audio, and video—in a standardized format." Simply put, it allows authors on the web to say "hey everyone, I've published something new!" and people who are interested in the author's website to be informed of the new content.

How does it work? How do I use RSS? Technically, the author of a site sets up an XML standard-formatted file somewhere on their site. When they add new content, they also update the XML file. There are many sites (like Blogger) that automatically update this file when new content is added.

You use a program, called an "aggregator", to stay up-to-date with an author's latest content (e.g. to know automatically when a new blog post is published). A feed aggregator, more commonly known as a feed reader, is an online or offline tool that keeps track of your subscriptions (by checking those XML files) and shows when your favorite sites have new content to be viewed. You have the option to just view summaries, view full content of new articles, or go to the author's website. There are many feed readers available, but I personally prefer Google Reader. Using the Google Reader gadget on my iGoogle home page means I have quick access to my favorite content every time I open my web browser, as you can see at right (click to enlarge).

How is any of this selfish or devious? I'm glad you asked. I know you're thinking up til this point you've seen nothing but great information. But of course my purpose is to enlist as many new Game Developer Journey readers as possible! :)

Click either of the links shown in the screenshot at left (click to enlarge) to subscribe to GDJ. If you click the icon at the top (shown in IE7) you will be taken to the general feed page; the URL displayed at the top of the page can be copied into ANY feed reader of your choice. Clicking either link shown near the bottom of the screenshot allows you to subscribe to the feed using a specific reader.

So now you know that anytime you see the orange feed icon above or see a link on a page that simply says "RSS", you can subscribe to keep up-to-date with that site. My hope, of course, is that you will subscribe to GDJ and also provide some feedback! I've found numerous game developer blogs with only a few posts or that are now defunct, so please feel free to offer your insights and help me stay motivated to post frequently. If you have any questions, let me know with a comment and I will respond soon.

Until next time, happy (GDJ) reading! ;)

2009 Game Developers Conference

Hot Topic: This year's Game Developers Conference (GDC09) is almost here! Sadly, I don't have the time off nor the money to attend this year but would definitely like to go next year! This year's conference will be held March 23-27 at the Moscone Center in San Francisco, California. Check out the GDC website linked above for more information. If you are going, you might want to use the online schedule builder to make sure you have an awesome, jam-packed week. Also check out Grant Shonkwiler's tips to make sure you're ready and don't get burned out!

Are you going to GDC? I know it's highly acclaimed for the educational presentations and great networking opportunities and would be interested in the impressions of anyone who has previously attended.

Also, are there any similar conferences closer to those of us living on the eastern-US border?

Introducing SkyCop v0.7

I think it's about time I introduce my pet project. You'll be happy to note the screenshot to the left is not all there is to it, though it represents the base from which I started. The project shown to the left comes directly from Engel's Beginning Direct3D Game Programming book. It features two ships, both capable of turning left/right, rolling left/right, pitching up/down, and moving forward and backward in three-dimensional space. Even though Engel discusses basic texturing early on, I find it odd that he didn't include any simple textures for the ship objects, just coloring one yellow and the other red. Leaving various enhancements to the reader is, of course, a challenge I willingly took head-on!

Part of why I never get to the later chapters in the book is because I very much enjoy enhancing this basic project. I don't expect it to become a full-fledged game; it's primarily a demo project for my own experimentation, but only time will tell if it becomes something more. The screenshot below displays my updated project, tentatively named SkyCop.

You'll notice from the screenshot the first thing I added was some fancy textures, not only for the ships but also to create a background (more on textures in another post). Additional enhancements include: multiple camera modes, dynamic background switching, multiple enemy ships, a pyramid-shaped target indicator (lower left), speed boost for the primary ship, and custom key configuration.

I plan to provide the code and running executable so you can download and play with it soon. I'm open to constructive criticism, just try not to be too harsh. I am still learning, after all ;)

Next up: Guns, Collisions, Explosions, oh my!

Quick Tip: Ready, Fire, Aim!

I ran across this article a few days ago titled Start to Finish: Publishing a Commercial iPhone Game by Niklas Wahrman. Interestingly, Niklas didn't initially develop his Asterope game for the iPhone. It started as a project for a Google Android developer competition and he didn't win, but I like to think he's raking in the big bucks now that it's available in the iTunes Appstore.

I think the most important point he makes is for the independent developer to take a "Ready, Fire, Aim!" approach to development. Simply put, don't over-plan, over-design, or over-engineer. It's easy to get caught up in the design of the game engine, the layout of the world system, and minute details. But getting bogged down in the design phase ("Ready, Aim, Aim, Aim..." as Niklas puts it) can be a major inhibitor to getting the job done.

I've also seen it mentioned in a couple different articles that getting the graphics nailed at the beginning, giving your early prototypes a polished look before working on gameplay mechanics, can be a big motivator to continue working on your game. Food for thought.

OOP & Vertex Buffers

In my previous post, I listed some minor issues I had with the book Beginning Direct3D Game Programming, 2nd Edition. And I have another one: the book does not teach good class-based design. Admittedly it's hard to blame the author though -- he has a lot of material to cover and is trying to illustrate core concepts without bogging us down in extraneous code.

However, realizing that my simple flight simulator needed a CShip class, I dutifully created one to encapsulate the required functions (InitDeviceObjects, RestoreDeviceObjects, InvalidateDeviceObjects, etc.) of the Common Files Framework. I thought it pretty slick that I could simply call m_MyShip->Render() inside my application class' Render method, and I didn't have a problem with my custom ship class having it's own vertex buffer until I read Bubba's post (#9) on this forum. Although I certainly am leery about taking coding advice from a guy named "Bubba", I'm curious about his comment that "The renderer should draw all objects from one vertex buffer."

Understandably, if I have multiple ships with the same geometry it is somewhat wasteful to use multiple vertex buffers (one in each ship instance, used by its Render method). So which way is best?

It may be time for me to invest in a "best practices of game development" book.

Book Report: Beginning Direct3D Game Programming, 2nd Edition

Courtesy: AmazonI've been reading Wolfgang Engel's Beginning Direct3D Game Programming, 2nd Edition for quite some time now. And by that, I mean I've made numerous attempts at reading it over the past couple years. I diligently read through the first six chapters, as I have yet again quite recently, and inevitably get hung up on the texturing concepts in the later chapters. Part of my problem is that there is quite a bit of material covered and I like to try every example in code. I'm thinking I will put in less effort coding and focus more on the concepts for this read through so I can actually finish the book this time ;)

For the most part, I'm happy with what I've learned from this book. Wolfgang does a great job of getting the reader up to speed with the development environment and provides the necessary DirectX 9 SDK and other tools on an included CD. He provides a good overview of the history (DirectX version 2 thru 9) and concepts (HAL, COM, shading and texture mapping) in the first few chapters and then moves on to the more interesting concepts involved in 3-dimensional rendering: axes, vertices, matrix and quaternion rotations, etc. Chapter six is a heavy but highly valuable chapter on the basics of animation in three dimensions and provides you with a framework for creating your own flight simulator. I have of course written my own derivative, which I hope to post for your enjoyment soon.

As much as I enjoy this book, I do take issue with it on some points. Firstly, I believe a large number of mistakes slipped into the book. For example, if the author indicates that matrix values must be entered row-wise, the code sample should do the same; these kind of minor errors have caused me to scratch my head more than once. Secondly, the author tends to explain some concepts with assumed knowledge instead of explaining everything in detail for the student who is "beginning Direct3D game programming." Minor issues aside, I think this book is a great reference and look forward to the upcoming texture-mapping and HLSL (High-Level Shader Language) programming chapters.

If you've read this book, let me know what you thought of it. Also post a comment to let me know your favorite Direct3D books. I want to learn as much as I can and could use some good references!

Inspiration

GameDev.net recently linked to this Game Career Guide interview with Jean-Francois Lévesque, describing his path toward becoming a Game Developer at Ubisoft Montreal in Canada. This post is one of a few leading to my recent fervor to work harder to break into the field. As I read the interview, I kept saying to myself "check, check, got that... I can totally DO THIS!!!"

I'd like to summarize what I believe were his most important insights and define where I am with each:

• Learn the English language. -> Check!
• Have a plan. Read as much as you can on game development and work on your own games/projects in your spare time. -> Check!
• Have at least one complete personal project to show to potential employers. -> I'm still working on this one.
• Use personal projects to test different rendering techniques and programming methods. Continue learning and be competent enough to explain design decisions. -> I'm working on this one too.
• Expect rejection in the beginning. It may take a couple times, more college courses, or simply meeting the right people to succeed. -> This might be tough!
• Be willing to step up and ask for more challenges/responsibilities once you do get hired. -> This is me!
• If you start getting in over your head once you land the job, seek help and learn from your co-workers. -> No problem.
• Be prepared for a personal component AND technical test at your interview. Be passionate about what you do! -> I plan to keep learning as much as I can to improve my technical competency, but I know I can easily show my desire to work on games!
• Have a personal website so employers can learn more about you. -> Check!
• Start networking! Attend job fairs and gaming conferences, participate in video game-related forums, and do everything you can to make new contacts in the field. -> I need to work on this one.

Clearly I have my work cut out for me, but I definitely believe it is possible. I plan to keep checking this list to see how I'm progressing. In the meantime, for those of you with game development experience, what pointers might YOU add to this list??? I know this blog is new and won't have many readers yet, but please add your comments even if this post is a couple years old by the time you find it!

About Me

Welcome to my Game Developer Journey blog!

My name is Jeromie Walters, and I promise this is the only personal post you will ever see on this blog. Having held a long-time bias that many blogs simply disseminate unwanted TMI, this is a huge step for me. Having started the discipline of reading blogs related to the field of software development, particulary Jeff Atwood's Coding Horror and certain others I will add to my links section soon, I've come to learn that some blogs can be of great informational value and hope that this one will do the same. Jeff and others have convinced me that I should just start writing. Obviously my personal opinions will be expressed on topics related to game development, but my promise is that there will be no posts simply stating what I had for lunch.

Who am I? I am a software developer for a small engineering company in Ohio. I graduated from The University of Akron with a Master's Degree in Computer Science and truly enjoy the art of programming. Of course, I got into it with the idea of writing games but eventually learned that I couldn't translate my general software development knowledge into game creation. At my current job, I work on a large web application that helps companies manage their business. It's a great company to work for and I get to use the latest and greatest web technologies, but I still feel like something is missing.

I believe my passion is game development. I love to work on something and get to SEE something visibly change on the screen! It's such an amazing rush to work on something and see your creation come to life. I took a couple (sadly underwhelming) graphics courses in college and have spent some time learning Direct3D on my own, especially recently.

I've always been a highly-motivated, goal- and detail-oriented person and I figure if this person can use a blog to try to get a better job, why can't I? I don't expect the game development companies to come knocking quickly (though that would be great!), but even if this blog helps me to just capture my own progress and have a chance to learn from others' experiences (please comment!), it will have been a success. I believe the Internet is an amazing tool for knowledge sharing and hope you will enjoy following my journey to become a true Game Developer!