C++ game using DirectX

[gurps1]

Hey guys & girls.

I have been given the following task to be completed by August 5th of 2011. It is a part of my university course. I was given the task yesterday morning, and i'm trying to get started on it straight away.

Pseudo 2.5D game in DirectX making use of point sprites/billboarding. A basic shooting
gallery type of game, that is set in a semi-3D environment (full-screen resolution). It can be like duck hunt, police training or carnival fair (bottles, barrels etc). It should have single and rapid fire, different weapons etc. The game will have a mouse cursor target, moving opponents, audio both in the background and for events fired, collision detection within rectangle bounding boxes and a difficulty setting based
on a timer clock counting down (easy = 90 seconds, hard = 40 seconds etc).

I want to make clear that I am not asking for you to code my game for me. I genuinely want to learn how to do it for myself. All my lecturer has provided me with are some demo games that allow the player to move a sprite around on the screen. No shooting etc as i will have to code this myself.

I am opting to go for a copy of duck hunt that was on the snes...my lecturer has confirmed this is okay.

My main questions are where should i start and how do i start.
If someone points me in the right direction i would appreciate it.

Thank you very much...

p.s i intend to keep this thread updated with all of my progress.

[shacktar]

duck hunt that was on the snes...my lecturer has confirmed this is okay

If you got your lecturer to agree with this in writing then all you have to do is hand him an empty file. Although Duck Hunt with the Super Scope 6 would've been something. It probably wouldn't have been enough to save the Super Scope from the scrap bin, though.

where should i start

First thing I would do is to make a simple app with a few sprites (like 2-4) moving randomly across the screen (black background). For instance, start them in random positions, set a random initial direction for each and have them bounce off the sides. At first, they don't even have to be sprites. They could be white squares. Once you have your white squares moving you could then draw some quick placeholder sprites (with like 2 frames) and substitute them for the squares.

Next, I would figure out how to get the mouse position and draw something at the current mouse position. Once you have that (current mouse position drawn, squares/sprites moving on the screen), you could then change the background (from black) to be a 3D environment as per the requirements.

how do i start

I didn't look at the demo you provided, but if it is as you say it should contain basic DirectX setup code as well as sprite movement based on user input. You could take this and change the sprite movement to automatic (as per above). Then, add some more sprites. You could tweek the crosshair code to your own benefit.

[brokenbot]

Well, you can take a very profession approach. Might be overkill for one project, but you can take key organizational factors and tidbits of tips to speed it up etc.

http://en.wikipedia.org/wiki/Video_game_industry

You might want to visit actual game development forums. This is simply a c++ forum.

[shacktar]

That said, if you have any C++ specific issues, feel free to post here. For game specific issues there is always gamedev.net (they have a DirectX forum as well).

[gurps1]

Thanks for the reply.

Since posting here, i've changed the project to a more simple game, where the player is controlled by the arrow keys and he has to chase enemies and collide with them in order to kill them.

My progress so far...i have a background, a player that is responsive to the arrow keys, and i have managed to get some enemies on the screen.

Right now i'm trying to figure out how to get collision detection working. I have no idea where to start on this part...in terms of how i would go about coding it..(i would really appreciate some examples). Please note I am a n00b to all of this and would really appreciate "back to basics" tips and advice.


Thank you

[shacktar]

As per the requirements, I assume you need bounding box collision detection? Per-pixel is harder, but not that hard if the sprites don't transform.

would really appreciate "back to basics" tips and advice

Alright, so we're looking for the answer to "when does a sprite touch another sprite"? For the purposes of this, a "sprite" is just an image (which may have transparency). The image has a boundary, which we call the bounding box.

Let's say we have a sprite whose bottom-left corner is at (5,6), with a width of 100 and a height of 200 (I assume a bottom-left origin though this may be different for your application). We would say that the width of the bounding box spans from x=5 to x=105 (let's call this set Span_x) and the height spans from y=6 to y=206 (let's call this set Span_y). So far, so good.

Now, let's say we have a point (x,y). How do we determine if the point is within the bounding box above? (spoiler ahead) It is sufficient to check that x lies within Span_x and y lies within Span_y.

int checkX = 100;
int checkY = 210;
bool pointInBoundingBox = (checkX >= 5) && (checkX <= 105) && (checkY >= 6) && (checkY <= 206);
//pointInBoundingBox == false because checkY > 206 

The following is wrong (see my next post)

This simple observation is all we need to answer the question "does sprite A collide with/touch sprite B". (spoiler ahead) To answer it we simply need to check the four corners of one of the sprites. If at least one of the corners is within the other bounding box (see above) then the sprites collide!

Now, judging by your requirements, for each frame, you only need to check if the player touches/collides with any of the enemies. If there are N enemies, then the brute force "check the player's bounding box with all the enemies' bounding boxes" is O(N) (linear time), so going that approach won't hurt rendering time very much (unless there are many many enemies on screen).

Hopefully the above will satisfy the requirements for your assignment. A more scalable approach would be to use a "broad phase" collision detection step which would rapidly determine pairs of sprites that may collide followed by the test above for each pair. There are many ways to partition the scene for the "broad phase" step such as using a simple grid of cells or a quad tree. I doubt your professor would require that, but if they do I would be happy to explain further.

[shacktar]

shacktar wrote:

to answer the question "does sprite A collide with/touch sprite B" ... we simply need to check the four corners of one of the sprites. If at least one of the corners is within the other bounding box (see above) then the sprites collide

This is wrong for two reasons. One, what if a corner of one the bounding boxes is within the other (and you checked the corners of the other bounding box)? You could check the corners of both bounding boxes with respect to the other, but the bounding boxes could be colliding in such a way that their corners are all outside the intersection region!

The actual check is, given sprite A and sprite B, check if A_Span_x overlaps somehow with B_Span_x and that A_Span_y overlaps somehow with B_Span_y. This covers all cases.

The other thing to take into account is the case where the sprites are moving so fast that they go through each other. For instance, if the sprites are unit squares, one unit apart, moving towards each other at 2 units per frame, they will exchange places without the collision detection code realizing that they intersected thanks to the discrete time steps. To deal with this, you could ask, "over the last frame, did these two bounding boxes overlap?", or, you could fix the speeds such that this never happens.