Phase 5: Complete (???)

It looks like collision detection is working! I implemented the method mentioned in my last post (hint: ????? was a much more involved step than I thought it would be), and now when the playership fires bullets at the one enemyship on the screen, it registers as hits. Time for some extensive testing...

Also, time to do some SERIOUS code cleanup. I need to go back and finish phase 4 (give enemy ships the ability to fire), and then tie all 5 phases together into what would technically be a "working" prototype for the game. I'll also need to do some pretty basic things (set up boundary conditions for all of the game objects, figure out what the final function prototype is going to look like for the collision detection function, create a GameManager class and throw everything into it instead of in main(), etc). So, as simple as phase 4 will be, it probably wont be done for a little while.

RANDOM tip of the day: I noticed that when I moved my ship diagonally up-right, I could fire at the same time. However, when I moved diagonally in ANY other direction, I couldn't fire! The code that handles movement and firing is extremely simple, so I was pulling my hair out before I finally did a little googling and realized that.... certain keyboards have limitations to how many keys can be pressed at once in certain regions of the keyboard (not even kidding). Once I changed my "fire" button from Space to S, everything started working.

New machine!

I finally broke down and upgraded/rebuilt my desktop. The limitations of programming on a laptop started to become unbearable.

Current rig features:

• i7 930
• Asus P6T
• 6GB OCZ Gold DDR3 12800
• Corsair 750TX
• 2xSamsung S2333SW (23" displays, 1920x1080)

So... life is good! But it's time to get back to coding. I still haven't started the collision detection algorithm, but I've been reconsidering the method mentioned in my previous post. I might be better off doing something like this:

• Call the "relative velocity" vector AB
• Call the "stationary" point P
• Create a vector AP, that starts at one end of the relative velocity vector and ends at P
• Project AP onto AB (something like this: http://en.wikipedia.org/wiki/Vector_projection)
• ??????
• Profit

Phase 3: Complete

Phase 3 (adding enemy ships) took a little longer than planned.... mainly because I've been teaching myself object oriented design on the fly and had to rearrange my inheritance hierarchy a little bit to enable greater flexibility down the road.

Still, I can now throw enemies on the screen and the player can shoot at them. Granted, the bullets don't do anything, which brings me to my next point...

I'm skipping Phase 4 (enable the enemies to fire) and heading straight to Phase 5 (collision detection). The more I've been thinking about it, the more I realized how tough this could be. Short version of the story: If a bullet is travelling at 10 pixels per frame and the player's hitbox is 5 pixels, it is possible that bullet could jump right over the player in one frame! (I made a post about this on gamedev.net: http://www.gamedev.net/community/forums/topic.asp?topic_id=570333 )

In any case, between the suggestions made on gamedev.net and some collision detection articles I read, I've decided to go with something like this:

• Assume every collision object is circular. Not ideal, but will work for now.
• For each frame, calculate the relative velocity of two items (say, a ship and a bullet) by subtracting one motion vector from the other.
• Now, all I'll have to do is see if this "relative velocity" vector ever get's too close to the ship (or bullet, depending on how I subtract the vectors). This will be done by...
• Taking the inverse slope of the "relative velocity" vector
• Use this slope and the position of the ship to determine the equation of the line perpendicular to the vector that passes through the point.
• Find the intersection of this line with the relative velocity vector. This is the closest that the vector comes to the ship. Calculate this distance.
• If this distance is less than the radius of the ship and the bullet, there's a collision

Disclaimer: I may be horribly misrepresenting the notion of a vector when I refer to the "relative velocity" vector. But hopefully the idea is clear. The idea is that I'll run through these steps for each pair of objects that need a collision check. Eventually, I'll add some code to minimize the number of checks that need to be made (but I'll save that for another post).

Time to post these ideas to gamedev and make sure they make sense!

Phase 2: Complete

I'm pleased (and surprised) to announce that phase 2 is already complete. Now the ship moves around AND fires bullets.

I'm finding one major challenge with writing graphic-driven programs is that debugging isn't as simple as writing a bunch of text to the screen every step of the way. While I could still write log files if I wanted to, I'm going to use this as an opportunity to learn how to properly use a debugger. I'm using Microsoft Visual C++ 2008 Express, so there's already a solid debugger at my disposal. So far, it's already helped me work my way through a couple of potentially nasty bugs with relative ease, so I'm definitely feeling good about deciding to use it!

On another note, for some reason whenever I tried to use an STL iterator, I would get a bizarre Linker error:

"...error LNK2019: unresolved external symbol __imp___CrtDbgReportW referenced in..."

It took a little Google-ing for me to find that I needed to remove the _DEBUG; entry from my project properties:

Alt+F7 (Project Properties)->Configuration Properties->C/C++->Preprocessor->Preprocessor Definitions

After deleting _DEBUG; from this entry, the program compiled and linked without issues.

Phase 3, here I come...

First Post

Ever since I was a kid, I've always wanted to design and create games. This blog will track my first real attempt at something beyond tic-tac-toe or connect four. I've always been a big fan of bullet hell shoot-em ups (shmups), so this project will be a basic attempt to create a shmup engine written using C++ and SDL. My biggest hope for this blog is that it will reach a point where it can be used as a road-map for future shmup creators. If the project goes well, consider this blog to be a guide. If it doesn't, consider this to be a list of things to avoid. Another hope is that this keeps me on track and organized, so if anyone is reading this and doesn't see an update for a long time, please e-mail me (shmup@matrisking.com) and kindly remind me to get my ass in gear.

Short Term Goals: The overarching goal of this project is to create a very basic shmup where you can shoot at some static enemies and they'll shoot back. I've created five benchmarks:

• Phase 1: Display the player's ship on the screen, move it around with arrow keys (complete)
• Phase 2: Enable to the player ship to fire bullets (complete)
• Phase 3: Create some static enemies (complete)
• Phase 4: Enable the enemies to shoot at you on regular intervals (complete)
• Phase 5: Implement basic collision detection (complete)

This is pretty much the most basic shmup I can imagine. I'd also like to adopt a version control system and some standard comment/documentation schemes. Provided I make it this far, I will attempt to extend this functionality with...

Long Term Goals (roughly ordered by level of ambition):

• Intelligent collision detection, which should go a long way to creating "bullet hell"
• Moving enemies
• Non-linear bullet paths
• Score
• Powerups
• Multiple player weapons
• Learn how to draw (or make friends with an artist, or hire an artist)
• Learn how to compose (or make friends with a musician, or hire a musician)
• Create an XML representation of levels
• Create a level editor
• Create an Android port of this engine
• Create an XNA port of this engine

Future posts will (hopefully) contain the following:

• Status updates
• Links to useful resources that I find
• Discussions of the various software engineering dilemmas I will encounter