Code Isn't Everything

I recently saw this Gamasutra blog post by Pascal Bestebroer, titled "My game's done. Now comes the stress, struggles, and adrenaline of a one-man team doing his own PR". And I thought... HOW RELEVANT!

For the longest time I was laser-focused on writing the code for my game. And I would occasionally blog about it. But I didn't give much thought to marketing the game after it was completed. Kudos to Mr. Bestebroer for starting his PR as early as the first week of development! This guy clearly has had more time in the trenches than I.

Marketing is perhaps more important than the coding of a successful game, at least by conventional definition of success. For me, I think just getting my game out on the Google Play store will be a success. But it's good to realize, as I'm learning, that you're not done once the game code is completed. And if you can get a head start on your PR efforts, the earlier the better.

Three Lessons Learned

So I think I mentioned in my last post (two months ago?) that some buddies and I were working on a tower defense game that we hoped to demo at an upcoming conference in September. As you may have noticed, September has almost come and gone but I haven't posted any stellar updates detailing the success of our demo at said conference.

Part of this is due to an unavoidable stall in development progress, which brings me to my first lesson learned. When I realized the ever-increasing scope of the game I would soon be writing, I should have pulled in more developers. As it is, I am currently the only programmer among a group of two 3D artists, two concept artists, and one musician. Although there is a certain amount of pride in being able to take full ownership of the (increasingly large) code base, there is also much to be said for having a fellow to bounce ideas off of and having someone to share the load when you're not available.

Another thing that's bitten us in the development of our game is not understanding core requirements in the beginning. We think we have a great idea for a game and started prototyping the basics right away. For a simple tower defense game, you have enemies moving from one end of the screen to the other, and that's what we created initially as a 2D game. Once we had this basic prototype, we realized that it was pretty darn difficult to make projectiles with faux-depth in a 2D isometric view look right. So we had to make the leap to the third dimension, which involved converting our 2D sprites into 3D rigged/animated/textured models. We started creating 3D animated models right away before adding concept artists to the team; so the models had to be recreated. But once we had our concepts, we needed to make specific decisions regarding Art Style - the overall game appearance - and this required new models yet again. As a programmer I occasionally overlook these finer details; I mean, if all the characters on screen are moving to their correct destinations... it looks good! But the second lesson I've learned is that Art Style is something that should be seriously considered early on in a game's development.

Performance is also a major consideration for our game. Although we want to have the best-looking game we can build, we also want it to be playable for as many people as possible, so limiting it to the highest-end graphics cards didn't seem right. And given the fact that I was developing the game on a laptop with only 32MB of dedicated video memory at the time, I had a big problem creating a game I wouldn't be able to play! So we took a step back and realized that our 3000-polygon models probably weren't going to cut the mustard. But even with reduced-poly models, we wanted to do some fun stuff in our game like using outlines on our toon-lit models, particle effects, etc. And some of these special effects are expensive operations that quickly drop frame rate and can cause the game to lag. So as our designer likes to say it, the final lesson for today is to "prototype everything." Although he doesn't really mean to prototype everything. What should really be prototyped is all of the core systems of a game that could be rendered/executing together at the busiest point of the game's interaction: music, sound effects, lighting, particle effects, blur effects, and so on. And provide a way to instantly, with the push of a button, drop a hundred or more models on the screen to simulate the game at its most computationally-intensive point to see how it will perform in the worst-case scenario. Doing this type of prototyping early on can help identify where you need to save polygons or cut features that could prevent your intended audience from playing your game.

The cool thing about my team is that we're all learning as we go, and sometimes part of that involves looking back and saying "You know, we could have..." So I hope this helps as you start your next project.

XNA Frustrations

I've been working on a tower defense game in XNA (C#) lately. I like that XNA simplifies a lot of tasks, which means I can write less code than I typically would in a C++ game. For example, I can make a simple spriteBatch draw call to get a texture on the screen without creating my own vertex/index buffers. Or I can create the view and projection transformation matrices with a single utility method. XNA handles window creation and setup with very minimal code and generally makes the process of creating a 2D game a very simple task.

However, creating a 3D game with XNA is a completely different beast. One thing I've beaten my head against is lack of support for animation out-of-the-box. XNA apparently has some classes at a very low level, as described by my buddy Priyank over at eNtropology Games. XNA Animation Component Library looks promising, though I have yet to play with it. And then there is the XNA Creators Club skinning sample that implements runtime animation classes for a skinned model.

But my latest frustration concerns the lack of something much more basic than animation; I can't create a sphere in XNA! Some folks have created their own classes to implement a sphere as a game "component" object, but what I really need right now is a class that can be instantiated dynamically so I can preview my bounding boxes for collision detection. Naturally C++ has simple utility methods for creating the basic meshes: cubes, spheres, cylinders... even doughnuts and teapots! But no such luck with XNA yet, and the most annoying part is that I'm wasting time trying to render a sphere when I should be doing more important tasks, like making sure my models can avoid walking through each other.

It seems XNA is more of a toy than a tool for serious game development, and I think in the future I will be limiting my use of it to more basic projects. But for now I press on, forced to create innovative solutions (translation: hacks) to make it work... grrr....

Carolina Games Summit 2010

"Making a game is like shooting a movie while you're building the camera."
-Shaun Peoples, Ubisoft's Red Storm Entertainment

Since our arrival in North Carolina six months ago I've had the pleasure of attending three game industry events: an IGDA meeting, the Global Game Jam, and the Carolina Games Summit (henceforth referred to simply as CGS). Participating in these events (not simply attending) is particularly exciting for me because it means I'm making progress on that whole networking thing I admitted I needed to work on a while ago. But this post isn't about networking; Darius Kazemi already has an amazing blog to help you out with that. I figured I'd take a few minutes to describe my experience at CGS, which took place February 6th at Wayne Community College in Goldsboro.

The day started off rough. I woke up late and, giving the expected minor snowfall I almost considered not going. Since it rarely snows here, people spaz out when it does and the news folk generally recommend not driving at all. But in addition to wanting to go, I had my friends Wes and Andrew counting on me, so I rushed over to pick them up. To my happy surprise, Wes offered to drive and the snow held off. We arrived a little before noon, when the first speaker session started. Numerous game tournaments were scheduled throughout the day on the second floor, but we were there primarily for the educational sessions.

The first session at noon titled "Wow, That Was Cool! Wait, What Was That?" was presented by technical artist Jason Connell and software engineer (programming) Shaun Peoples of Ubisoft's Red Storm Entertainment (Rainbow Six, Ghost Recon). Unfortunately due to a scheduling snafu (more on this later) there was a delay while the coordinators attempted to find our speakers, so we were treated instead to a Q&A by Ben and Stefan from Electronic Arts. Responses of interest to me were the importance of being good at something specific but also being agile and also the fact that even a giant like EA outsources some art/engineering.

As the session proceeded, the scheduling glitch was somehow resolved, as Jason and Shaun stepped in to give their now-quickened presentation, which gave good insights on the daily life of an artist or programmer in the industry. I took a lot of notes here but will summarize the key points for programmers:

• Knowing the hardware helps you write more efficient code and stay competitive.
• Be passionate... but also realize you will never make "your" game.
• Knowing engines helps you understand what your competition is doing.
• Expect constant changes during the development process; you will work on different things from day to day.

The next session we attended, titled "Landing a Job in the Game Industry", was presented by Ryan Stradling, the Senior Development Director at EA in North Carolina. I found it interesting that EA NC only has nine employees, and they've worked primarily on NASCAR titles at this point. This session covered most things I've heard before: create a complete game, be a team player, get experience any way you can, etc. But I learned some new stuff too. For example, did you know the game industry reels in $8.7 billion each year in the US alone and $24 billion worldwide? Ryan also gave these insights to making it 10+ years in the game industry:

• Accept change
• Accept that fun is an elusive target
• Be motivated and passionate.
• Continually learn, pushing yourself and others
• Love what you do, and do what you love!

Mr. Stradling was very down-to-earth and willing to chat with attendees after his session. So I was able to meet him, ask a couple questions, thank him for his presentation and shake his hand. His advice to me directly, as a programmer, was to "Know your stuff!". This was definitely the highlight of my day.

My friends and I attended two more presentations, one by an indie developer on the challenges of starting a game company and another by a lawyer on the top legal pitfalls of game companies. I took more notes but will save those details for a later date since this post is getting long already.

Unfortunately the CGS did not seem well-organized, due to the initial presentation confusion and meager dining options. We went with the barely-warm Chick-fil-A over the $2 per slice of Papa John's pizza. Also the fact that all sessions were in the same room and scheduled every hour on the hour (with no breaks in between) meant some sessions ran over and others had to start late. But for the sake of education and networking opportunities, I'd still have to say it was a worthwhile experience.

Next up? The Triangle Game Conference is coming April 7-8th...

Global Game Jam 2010

I had the unique opportunity to participate in the Global Game Jam this past weekend, January 29-31. The GGJ is a 48-hour, world-wide game creation marathon. Creating a game is no easy task, let alone doing it in such a shortened timeframe. But we did create games, many of us in small groups across the world, and it was truly an amazing experience to be part of this global event!

The Triangle Game Developers division of the Global Game Jam started off at Icarus game studio in Cary, NC on Friday the 29th at 4:30pm. Unfortunately, due to snowy weather we were not able to remain at the studio location for the entire weekend as planned. We had just a few hours to get together, meet our peers, view the keynote speech, and then get started by discussing game ideas and forming teams. After a short period of discussing our game with our new team members, we left for the evening with everyone's contact information in hand, and that's when the real fun began.

This year's theme was Deception. We had to think up game ideas incorporating some means of deception and, as an additional requirement, had to include one of the following three items in the game: a pet, a set, or a net. The idea our group settled on was a type of Bejeweled clone where players secretly choose the gems they use to score points and can also sabotage each other! Our game is called Befuddled and can be downloaded here, along with other games from the Triangle Game Developers.

One thing I learned from this event is that it takes a LOT of work to complete a game. And a lot of communication. In fact, I think that's one of the things my group did particularly well. One of our team members set up an IRC channel so we could all communicate real-time, and we were mostly connected the entire 48 hours for making design decisions, asking questions, and just chatting in general. Another thing we did really well was picking a simple game idea. It started very basic, but we were able to add on to it, giving it new visual styles and gameplay features as we went along.

One problem we had throughout was, with a basic game, trying to add the right things to make it fun. We know it still needs more playtesting and iteration to figure out the missing "fun" factor. But the best and most exciting part of it all is having something we can call a complete working game. Of course nobody stayed up the full 48 hours, but some of sure did try, and we're all very proud of our successes on this project!

Be sure to check out Befuddled and a ton of other Global Game Jam games by visiting the Global Game Jam website. You can also search Twitter for #GGJ to see posts about GGJ games.

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...

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 :)

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!

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?

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.

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;
}

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?

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! ;)

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.

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!