Nazeeh’s Little Corner on the Web

So this is something that I’ve been wanting to do for a while and just got around to getting it done now. XNA Game Studio has been brought to you guys by one of the hardest working and most dedicated teams I have ever had the honor of being a part of. You already know some of the team members through the forums and such, but it’s time you really get to know them! With that said, I want to kick off the “Team Interviews” series! I ask questions, a team member answers them, and I publish the interview here for you to read. I am delighted to start this series with one of our framework developers: Yuichi Ito

Who are you and what do you do at XNA?

My name is Yuichi Ito. XNA Framework developer.

What did you work on before joining XNA?

I’ve start working for Hudson when I was 18 year old and my first title was Bomberman `94 on turbo graphics.

After that, I’ve worked for Sega and did some work on the Dreamcast system library. Then I moved to U.S to work for Digital Anvil at Austin Texas (yee-hah!!). I worked on a particle system with editor for Freelancer, then on porting the particles system to Xbox. I also worked on XML based data system, physics based character movement, and animation for Brute Force.

How did you join the XNA team? Tell the story!

Unfortunately, Digital Anvil studio was shutdown at end of 2005. I’ve been working for game industry for more than decade and notice that it getting harder and harder to make game you want. Most games spend a couple years in pre-production and are then rushed into the production phase. And I’m not going to tell you about more details because I think you guys are already know about such realities.

But one day, one of junior programmers at studio told me “I’m not sure what I’m doing anymore. Because what I suppose to be doing is game programming but what I’m doing is tool programming.” And that’s when it struck me. When I was working on first title, it was so fun to work on it because I could concentrate on pure game programming the entire time.

Why did game development become such a boring and painful job? I’ve already had some (but not enough ;D) fun but seems like young people mostly suffer from that pain. I asked myself, how could I make them happy?

Then I met Boyd Multere and heard about XNA. I was so excited about his plan that I was practically begging him to join the XNA team.

What features did you work on for XNA 1.0 and 2.0?

On 1.0, I designed and implemented the math library. I also worked on BasicModel, BasicEffect, and XACT build.

On 2.0, well, I was not working on 2.0 stuff that much. I was working on other thing that I can’t tell you right now…

What’s their favorite bit of XNA, and why?

There are so many things!! But my most favorite feature of XNA is networking.

Networking is so simple and the  API is easy to use, and of course it works as expected.

What is your favorite Xbox game?

There are so many things!! Especially last holiday season. I bought game for almost every single week from thanksgiving to Christmas. (E.d hmm…looks like we pay our devs too much)

But most favorite game is COD4. Why? Because I beat it and got 1,000GP.

Share some tips and tricks for using XNA

Back in the day, when I was working on any kind of game, I usually have game dev environment that is a game editor that runs on Windows and talks to the target platform. For example, you can change parameters on windows and that apply to target platform in real time. On XNA 2.0, you can use networking to achieve this. The trick is XNA networking only connects to applications that have the same assembly GUID that typically in AssemblyInfo.cs.  So, easy way to let your game editor talks to the game is set same GUID value to editor side GUID.

Last words?

As I mentioned before, my goal is make game development easier and more fun. So if you feel that anything you do is too hard, not fun on XNA, let us know about it. We happily work for you.

Oh, and if you find any bugs, blame Nazeeh, he is Tester, all his fault. (E.d. While true, we can’t neglect the fact that HE put the bugs in there in the first place!)

Interview Comments

I wanted to thank Yuichi Ito for taking the time to answer my short interview. Now I ask you guys and gals, do you like this series? If so, what other questions do you feel I should ask? This is your chance to really get to know the XNA Game Studio team more personally. The people on this team are amazing and I am honored to do the introductions :)

As promised in my previous post, today I’ll try to take a stab at designing my own game. I told you  how important the game design process is and how you should know all that there is to know about your game before writing any code. Well, turns out that it’s not a very easy thing to do! I spent a few days brainstorming in my head and trying to come up with what I wanted to do. Finally, I got a good grasp on the major game mechanics I wanted to do and started to dig deeper and find more ideas. Here’s what I’ve come up with so far.

Project Name

If recall from the last post, I said that it’s pretty important to come up with a project name for your game. For me, I picked the name “Odyssey”! Why do you ask? I don’t know… it’s all I could come up with. I didn’t say it had to be a good name! Just that you should have one! Mine’s lame, but I am gonna stick with it!

Game Description

Odyssey is planned to be a 2D side scrolling shooter that is pretty simple. In one player mode, you play as a flying ship (how original! I know) with enemies attacking you from the right side of the screen.

In two player mode the game really shines! The second player controls a tank on the ground and both players work together to fight the enemies. Each player has a dominant color (indicated by the color of their ship/tank). Enemies that carry your color only you can kill, while other enemies you can’t harm. This leads to a game play where the two players have to work together to eliminate the correct colored enemies otherwise they will both die by an overwhelming force. Enemies not of your color will attempt to attack you more frequently and thus cause a great threat to you that can only be eliminated by your buddy.

In two player mode, the ship can move up/down/left and right while the tank can only move left and right. The ship has less health than the tank as well as less firepower. But the agility/speed it can move with offsets that weakness.

The game will progress via levels. Each level will have a preset number and type of enemies that will attack you ending with some sort of boss battle. Boss battles will utilize the same color based combat, details will differ per boss. You win the game if you finish all the levels. You lose when you consume all the available lives you have. In two player mode, you and your buddy share the same pool of lives, so you both lose when you both consume them all.

The enemies will come in different flavors:

• Neutral color enemies: These guys can be damaged by either player. They are the only type that is available in the single player mode.
• Color matching enemies: These enemies match either of the two players’ color. They can only be killed by the correct player. They will attack the non-matching player more frequently and hence cause a threat to them. These are only available in two player mode.
• Boss: Bosses occur once per level at the end. They are unique per level and need a strategy to beat them.

You have a pool of lives in the game, once you go through them all, you are dead and the game is over. Two player mode both players share the same pool. Players gain an extra life everytime they score 5000 points (might change that based on how the game plays, might increase or decrease it).

The game will have power-ups in multiple flavors. Power-ups are spawned based on certain triggers from dead enemies:

• Health: These will start first floating in the air for 2 seconds to give the ship a chance to get them then will drop on the ground for the tank and stay for 2 seconds before they disappear. These will spawn after you kill X number of enemies. X is to be determined.
• Weapon Fire Rate increase: This power up will increase the firing rate of your weapon. It will spawn and start to float downwards towards the floor. Will live on the floor for 3 secs then disappear. Either player can pick it up. Will spawn after you kill X enemies and will last for 20 seconds indicated by a timer on the HUD.
• Nuke power-up: This power-up will drop randomly and allow you to detonate a nuke that clears all enemies on the screen.

Odyssey might have an achievement system. This is yet to be determined. If it does, it will be based on number of kills, length of time you survived, etc.

Network play is a possibility based on time and cost needed to implement it. Same console/PC play remains as priority 1 for now.

Game will support Xbox and PC and use keyboard/controller.

Game Story

The game will not really have much of a story. Your basic alien bad guys attacking our planet and we have two new war machines in the form of a ship and tank that work together to fend off the attacks. I might re-think the story later as I get more of the game mechanics nailed down.

Inspirations

The game is inspired by a lot of games out there. The first one that comes to mind is Heavy Weapon on Xbox Live Arcade. I like the way the tanks in that game move around and the way the enemies attack. Here’s a screenshot of Heavy Weapon for reference:

Things I like:

• I like how the tanks move horizontally from that game. I will use that same motion in Odyssey.
• I like the coloring of the tanks to differentiate them. This is basically a Color.Blue argument to spriteBatch that tints the color of the sprite. I will use that same method in Odyssey two player mode.
• I might borrow some of the weapon ideas from here too.

Another game I looked at is Jet’n'Guns seen here:

I particularly like the HUD in this game. Check out how the health is indicated by the small gauge at the bottom left corner. Simple HUD, and very non-obtrusive. The graphics are cool as well, not that I expect to get anywhere close to that kind of work ;)

Experimental Ideas

I have this one idea that I am experimenting with in my mind because I am not sure how well it will work. The game will inevitably reach a point where one of the players has more health than the other one and wants to help them out. I am thinking of integrating an ability that sits on a long cooldown timer that allows you to transfer some of your health to your buddy to help them out. You lose that health of course, but you give them the boost they need to stay in the game and not consume a life. Still thinking about that one though.

So what’s next?

So now that I have a basic idea of what I want Odyssey to look and play like, I will start to think about what technologies and techniques I want to use for the game. Next post, we’ll talk about a very popular and heavily used sample that I plan to use for this game. I am talking about the GameState Management sample that you can grab from http://creators.xna.com. It’ll be a good idea to take a look at it now and be familiar with it in preparation for next post!

This is the first post in my “Building a game” series! The aim of this series is to walk through building a game from scratch and try to include as much of the thought process involved as possible. So how about you grab yourself something to drink and let’s sit and chat about game design!

Before I sat down to write this post, I walked to Shawn Hargreaves and Eli Tayrien’s office and talked about game design with them. These guys know a whole lot when it comes to game development and I highly value their input. The question I asked was “How does one go about designing a game?”

There are two different aspects of game design that you want to think about: Game play mechanics and Game architecture. One has to do with how the game will play while the other is about how the game code/engine will work. For this post, we’ll talk about game play mechanics. These are the sort of things that you really need to have nailed down before you write a single line of code. The reason you want to flesh all that stuff out early on is to avoid being halfway through developing the game and then realizing that you really want to add this awesome new game concept. Knowing something like that late in the cycle will probably cause you a lot of pain to get it to fit in. Take your time now, think about stuff early on and get your blue print drafted out.

Project Name

This is the first thing in my opinion that you should come up with. Every project needs a name, and your game is no exception. A project name is not the final name of your game though. I mean, it can be if you want, but most of the time it isn’t. Windows Vista was called Project “Longhorn” for instance. XNA Game Studio v1.0 was “Rogue” while v2.0 was “Shaman” (Yeah… I know what you’re thinking…).

So why is a project name important anyway? Because it gives your project an entity. If you cared enough to name it, then you probably will care enough to finish it. Once an entity gets a name, it starts to get somewhat of a virtual soul. You refer to it by name, you talk about it as if it exists. Plus, depending on your project name, it can make it sound very cool and top secret-ish vs geeky and nerdy like our project names.

So go ahead, name your project something cool! It’s step #1 in the fun.

Game Description

This is a very important step in game design. This is the overall description of what your game is all about. Start with the idea you have for how it will play and then add to it. Someone reading this should be able to know everything about your game without playing it. It’s almost like writing the manual for the game before the game is written. So what kind of things do you want to think about for your game description? Let’s list some out:

• What is the game play about? Is it about a player controlling some entity in the world and shooting enemies? Is it a puzzle like game where you have to solve a puzzle of some sort?
• Is your game single player or multi-player? If it is multi-player, is it co-op or competitive? How are players going to interact together? Will I have to kill my opponent or work with them by sharing powers and/or resurcting them when they die?
• Is your game’s progression based on levels or increasing difficulty? If you’ll have levels, how will they be different from each other? Will levels introduce different challenges to the player or just provide a backdrop?
• What kind of behavior will my enemies have? Will they be coming at me in waves? Will they shoot at me and if so, how accurately? Will they have varying movement speeds? like some will travel fast while others slow?
• If you’ll have weapons, how will they work? Are they upgradable? if yes, then how? Are they balanced? Can you carry more than one kind of weapon?
• How will the player achieve victory or defeat in your game? Do I win if I kill everything on the screen? Do I lose if I take too long to finish a level? How can you make it very clear to the player that they are winning vs losing?
• Do I have power-ups in the game? How do I get them? What do they do? Are there power-downs? as in items that if I pick them up they actually hurt me?
• How does scoring work in the game?
• What happens when I die or lose? Do I have the concept of “lives”? Do I start from the beginning or can I continue from where I died?
• Will my game have network play?
• Will the game have some sort of achievement system? How will that work?
• How will the controls of the game work? If the game is PC/Xbox, then how can you make sure one platform doesn’t have an advantage over the other due to controls? It might be ok to have that, but it’s a decision to be made.

Game Story

So what about the game story! The world where my game is set in? I have this awesome story about an evil alien race that is determined to wipe humanity out by seeking ring like structures left by an ancient advanced race that is long gone! But wait! There’s a twist, there’s another alien race that will start messing with BOTH the humans and the evil aliens!

Yeah… there is a reason that I put game story after game design. According to Shawn Hagreaves, you can spot a good game designer from a bad one by focus on game story first. In the real world of game development, it is very possible that your sci-fi based game will be changed to a Viva Piniata like game by the publisher if they feel the game play mechanic works and the market needs such a game type now vs sci-fi.

Having a good game story is important and all, but make it a priority 2 while game play mechanics a priority 1. It doesn’t help if you have an awesome story but once the game starts, the player is bored out of their mind. While it is possible - and happens quite often - that a game with a pretty poor story and world but has amazing game play will win in the end. Having both story and gameplay being equally good is the holy grail of game development I guess. Some examples exist, but not many.

Stand on those shoulders damn it!

See those giants? Stand on their shoulders! Once you identify what kind of game you want to make, it is very helpful to go out there and find similar games. Play them. Take notes. Have fun. Spend a lot of time criticizing them and reading what others said about them. Find things that you like about them vs things you don’t like.

For instance, let’s say you’ll be creating a Real Time Strategy (RTS) game. Go out there and find what others have done with RTS games. You’ll find that they can be quite different. Some games like Warcraft 3 have the whole Hero RPG element in the game. Some people love that while others hate it. Some RTS games have very different races to play with like Starcraft. What kind of destructive super powers did you like? What elements seemed really fun while others were meh. Resource management in RTS games can be very different. Some have you gather one or more kinds of resources. Others make you hold points on the map to gain resources.

The point is, see what’s out there and learn from it. It’s not about copying what others have done, it’s about improving and adding your own touch to already successful ideas. It’s a delicate balance between improving upon vs flat out copying. Don’t worry though, if you do copy something, people playing your game will let you know very quickly :)

It’s the little things

This is the trickiest part of game design if you ask me. There are games that do this very well. You’d be playing a game and something very small and seemingly insignificant would happen that would make you feel so good! It’s kind of hard to explain without an example.

Take Call of Duty 4 for instance. One of my favorite games right now. I noticed that one of the things that I LOVE about it and actually makes me want to play it more is the feeling it gives you when you shoot an enemy. It’s a mixture of the way the aiming reticule changes to an X indicating that you are hitting an enemy and that awesome DUB DUB sound it makes when you’ve landed a killing blow. The experience points that show up as well seal the deal. Check out what it looks like:

I don’t know what about this whole experience that makes every kill in CoD4 very enjoyable. You feel you’ve done something! You’ve made a change. Now how do you think something like that sounded on paper?!

CoD4 Design team: “Yeah… so we want the aiming reticule to change to a X when you’re hitting a person. We also want to have this like… eh… DDDUB DDUB sound play as your bullets hit the target. It’ll be awesome!!!”

Dude with $$$ (i.e. Publisher): “Yyyeah… that sounds… like a lot of fun. What else you got?”

Stuff like that are pretty hard to come up with. But it’s better to think about them and try to come up with some than to not at all. Think about how you can make your player feel good when they do the right thing. Prototype such ideas even if on paper. Believe me, once you find that little hook, you’ll be very happy.

Here’s another example for you, I am just so full of them today :) We had a game internally developed by some dude from Rare studios while we were working on version 1.0 of XNA Game Studio. The game just couldn’t be simpler than it was. You and up to 3 other people control 2D ships on the screen and you all have to work together to destroy all the asteroids on the screen. Every level, you have to destroy more asteroids. The hook though was when one of your buddies died. You can bring them back to life if you collect a randomly spawning star that is the same color as their ship. Once your buddy would die, they would instantly start yelling “BRING ME BACK!!! QUICK!!” and everyone would be searching all over the screen waiting for their resurrection star to show up. Once it did, we would ALL rush to it to bring them back and more often than not, we’d all ram into an asteroid and die together. Such a simple concept but it was so fun that we played that game for hours! Probably caused us to delay the release a little bit ;)

Last words

Spend the time doing all this for real. Get yourself some sort of notebook or something, write the project name on it and write down all the ideas you have. Flesh them out, discuss them with others or teammates. Criticize them, find the gaps, find the fun stuff, etc. Before you start coding your game, you should know everything there is to know about it. This way you won’t be slamming your head on a wall later because your design is not flexible enough to add that awesome feature you just thought of.

Next post we’ll actually go through the exercise of me putting all this into practice as I design what will probably be a super lame game :) It’ll get the point across though. In the meantime, start thinking about your game!

Some of you may be asking… where did I go? Why no new posts? Or…maybe you’re not asking that, but I’ll go with my first thought! I am still here totally alive and kicking. Got back to work from the holidays and been kind of busy ever since. That doesn’t mean that I forgot about my blog though. Now that we’ve been through enough basics to qualify us to write a game, I’ve been thinking of one to blog about. Here’s what I am thinking about…

One of the things I tend to see a lot on our forums is people asking for more tutorials and posts about how to actually write a game vs how to use the framework to do standalone things. There are plenty of posts and articles on the net on how to draw models, textures, etc. But not very many that will walk you through writing your own game and structuring it. That is what I am about to tackle with my next series of posts.

I am thinking of putting together a series of posts detailing how to write a simple 2D game. The posts will talk about concepts such as:

• Designing your game from a gameplay point of view.
• Designing your game code structure.
• How to use some of the cool concepts in XNA GS such as components and services.
• Learning some more cool effects like background scrolling, etc
• How to design a level and have your game load it up and use it
• Maybe even touch a bit on 2D effects using slightly advanced topics such as shaders
• and more…

Through this exercise, I am hoping that all the concepts would be very clear through seeing them in action step by step in an actual game that we build together.

So that’s what I’ve been up to for a while now. I am starting to work on it now (like really now) and am hoping to have some posts up during this week or so. Stay tuned :)

This is a quick post for something that I just had to share with everyone. I can’t believe I haven’t come across this BRILLIANT utility until now! Trust me, I look for stuff like that all the time yet still managed to miss it. Allow me to introduce to you: WinTabber! So…what is this thing?

If you have used any browser that has tabs in it for instance (or any application that has tabs), then you’ll love this thing. One of the things I really enjoy when using my Linux machine (yeah…I use Linux too…even have some literature about it) is using Konsole in KDE and having multiple shells in the same window with tabs. Love it! So when I came to fall in love with Powershell, I wanted the same thing. Using something like WinTabber, I can do that now!

With WinTabber, you get an initial window, then you can have it put any application on your desktop in a tab in that window. Here’s a shot of me using it with Putty and FileZilla hosted in it:

I love it :)

Note: This is a shot from my wife’s laptop… I am not using Pink as my border color. Just saying…

Starting off 2008 with some collision detection! Now that we’ve slowly learned how to work with XNA framework, we’re getting very close to knowing most of what we need to build an actual playable - and maybe even a fun - game. Let’s get right to it then: What is collision detection?

Collision detection is one of the methods you can use to detect if two objects in your game collide. Why would you want to do that? Let’s say you have a very simple game where the player controls a ship that shoots missiles. You have enemies that fly around and you shoot at them. How will you know when your missiles hit an enemy? That’s where collision detection comes into play. You want to detect when two objects - missiles and enemy ship - collide together.

How does collision detection work? Here’s the “theory” behind it. Check out this diagram here:

See how we have two rectangles? Obj 1 and Obj 2. Right now they have not collided together, right? Let’s see what happens when they do collide:

See that? The rectangles have collided and we can see that due to the intersection that happened between them. This is how you can detect if two rectangles have collided together: if they intersect together.

So how do that apply to a game? What you need to do is specify a rectangle for every object in your game that contains that object. Such a rectangle is called a BoundingRectangle. As objects in the world move around, you check for collisions at every Update call to see if the rectangles intersect, if they do, you got a hit!

Visual example:

See how we have a virtual rectangle drawn around each texture in the game? They are not actually rendered of course, just defined in the code and kept around for collision detection. If these two creatures actually collide, the rectangles are going to intersect and we get a hit.

Show me the code!

Let’s have a quick look at how this would work in code. We’ll have a very simple scenario where you have an enemy and a missile that is aimed at them. We want to know when the missile hits the enemy so that we can render an explosion or something cool.

First we see what data structures we need to create:

   1: Texture2D enemy;

   2: Texture2D missile;

   3:

   4: Rectangle enemyBR;

   5: Rectangle missileBR;

   6:

   7: Vector2 enemyPosition;

   8: Vector2 missilePosition;

• Lines 1 & 2: Simple declaration of the enemy and missile textures we’ll use.
• Lines 4 & 5: These are the two Bounding Rectangles we’ll use for collision detection. One for the enemy and one for the missile. We use the Rectangle structure from XNA framework for this.
• Lines 7 & 8: Two Vector2 objects that we’ll use to track the position of the enemy and missile in the world.

Next we initialize everything, I did that in my LoadContent method:

   1: protected override void LoadContent()

   2: {

   3:     spriteBatch = new SpriteBatch(GraphicsDevice);

   4:     enemy = Content.Load<Texture2D>(“enemy”);

   5:     missile = Content.Load<Texture2D>(“missile”);

   6:

   7:     // Init positions

   8:     enemyPosition = new Vector2(10, 10);

   9:     missilePosition = new Vector2(70, 70);

  10:

  11:     // Init Bounding Rectangles

  12:     enemyBR = new Rectangle((int)enemyPosition.X,(int)enemyPosition.Y,

  13:                                 enemy.Width, enemy.Height);

  14:     missileBR = new Rectangle((int)missilePosition.X, (int)missilePosition.Y,

  15:                                 missile.Width, missile.Height);

  16: }

• Lines 8 & 9: Nothing new here, just initializing the positions of the enemy and missile in our world. I just put whatever values in there, they are not really accurate ;)
• Lines 12-15: We initialize the Bounding Rectangles. The constructor for the Rectangle struct takes a position in X,Y and a Width and Height values. I use the initial positions of each object for the X,Y and the Width and Height of the texture for the rest. Very simple.

Finally, we go to the Update method:

   1: protected override void Update(GameTime gameTime)

   2: {

   3:     // Allows the game to exit

   4:     if (GamePad.GetState(PlayerIndex.One).Buttons.Back == ButtonState.Pressed)

   5:         this.Exit();

   6:

   7:     // Move stuff around based on input or whatever

   8:     // I removed that part of the code for simplicity

   9:

  10:     // Make sure to sync the Bounding Rectangles with the current position

  11:     // of the contained object

  12:     enemyBR.X = (int)enemyPosition.X;

  13:     enemyBR.Y = (int)enemyPosition.Y;

  14:

  15:     missileBR.X = (int)missilePosition.X;

  16:     missileBR.Y = (int)missilePosition.Y;

  17:

  18:     // Now check if they collide or not

  19:     if (enemyBR.Intersects(missileBR))

  20:     {

  21:         // We got a HIT! Do something!     

  22:     }

  23:

  24:     base.Update(gameTime);

  25: }

• Lines 12-16: As we moved the sprites around the screen based on user input or whatever, we have to make sure we synchronize the Bounding Rectangles as well! They won’t move on their own. So at every update, I make sure to update the X,Y values for the Rectangles.
• Lines 19-22: This is where the magic happens! We use the Intersects method in the Rectangle struct to see if the enemy rectangle intersects the missile rectangle. If they do, then we know we got a hit!!

That’s it! How easy was that eh? What’s even cooler is that these same concepts pretty much work the same in 3D graphics. But we’re getting ahead of ourselves, we’ll get there soon.

Tips & Tricks

Some food for thought:

As you probably figured out by now, it’ll be easier if you create a container object for your objects in the world that has all the data needed by that object. So things like the texture that represents it, the position in the world, the bounding rectangle, etc. This way you can have everything self update in a more automatic and contained way. Manually updating the bounding rectangles like the code above is not the most efficient way to do things.

When you initialize your bounding rectangles, you don’t have to make them the exact size of the texture like I did above. Actually, most games like to make them smaller so that a collision happens when the two objects rendered are overlapping more than in my example. This way you use the rectangle to mark the “hit-able” part of the image which for a ship might be the power core or something.

Another REALLY cool use of bounding rectangles is to mark areas in the world where you want to know if something enters or exits it. For instance, let’s say you have your ship moving left and right along the X-axis at the bottom of the screen. How do you make sure it doesn’t move off the screen edge? You can keep checking the x-value of the ship against x = 0 (left side) and x = screen width (right side) and make sure you don’t move it beyond those points. OR… you can put small bounding boxes at the right and left of the screen and check for intersections.

Tip conclusion: Bounding rectangles can be used to detect when objects hit areas of the screen! Use that to achieve things such as event triggers or movement restrictions.

Last tip… hmm… I got nothing for you… I just don’t want to end on a “Tip Conclusion” since it kinda looked ugly ;) Maybe you guys have some more tips to share!

Tips from you guys! (Keep them coming!)

From KaBaL: Don’t forget, you can use more then one Bounding Box for a single object (sprite) that way you can get better detail for irregular shaped objects (ship’s nose, wings, tail)