Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

The legendary rating...

Sign in to follow this  


It seems for a short time I had achieved the legendary rating of 1337. For most of that time I was asleep, but hey, it was fun while it lasted[smile]

It would appear that I was rated down since then, so I still might have a good chance to get it back...

Anyways, I've added temporary invincibility after taking hits in the game. Already the game is alot more fair. However, I was forced to go back and raise some hard-coded damage levels to at least make the game difficult.

Next I'm going to try and make the homing missle weapon. This was probably the toughest of my goals, which is why I wanted to take care of it now.

So why is this so tough? Well, it's simply because the way my code is organized.

However, one of the problems has nothing to do with that. The first problem I thought of is how would I rotate the missle? My first thought was to use SDL_gfx and then use the rotozoom library. However, I realized that this would be an overkill, because the missle would only travel in 8 different directions: north, south, east, west, northeast, northwest, southeast, southwest. So I decided to just draw 8 different missle sprites given the missles orientation. So with that problem solved, I thought about how to implement the weapon more...

Now here comes the biggest problem, finding out what to actually lock onto. Now if this wasn't bad enough, the way I wrote the code makes it worse. Alot of the classes in the code don't "know" that some other classes exist. For instance, the weapon class is used by the player class, but the weapon class doesn't know of the existance of the player class. The same is true with player and enemy. So how would I even tell the missle what to lock onto?

This seemed quite hopeless, but than I realized that all weapons are stored as global variables. When a player uses a weapon, it obtains a pointer to that global weapon object. So I can write my enemy code so that it passes the missle launcher object a list of coordinates that it can lock onto.

One more problem remains. Suppose your using the missle launcher, and you jump over an enemy and then try to shoot an enemy in front of you. If I were to write the weapon as I've explained so far, the missle wouldn't aim for the enemy in front, but would indeed, lock-on to the enemy in back. Worse yet, it could try to hit an enemy that is offscreen. This is simple though, just give the player a certain range of which the weapon can lock on.

I haven't tried out any of these solutions yet, so they might not even work. But, I'll give it a good try and attempt to get this weapon working.
Sign in to follow this  


Recommended Comments


I think someone rated me down just to dethrown me. Yes, it's all a conspiracy...a vast conspiracy...

Share this comment

Link to comment
It's not fair, I never achieved the profound and life-changing coolness of the 1337 rating... [sad]

Share this comment

Link to comment
It's not fair, I never achieved the profound and life-changing coolness of the 1337 rating...

Want me to help ya try? :p

Share this comment

Link to comment
I modified level one's background a little bit on a whim, don't know if you have any use for it:

Hope the image code works...

Nope, sure didn't... here's the links to the images...


Share this comment

Link to comment
Two little checks will solve all your problems:

- Is the target facing the same way as Stompy? i.e. if Stompy faces left, make sure (Target.X + Target.Width) < Stompy.X, and if Stompy faces right, Target.X > (Stompy.X + Stompy.Width)

- Is the target currently inside the viewing region?

Even a short range won't prevent off-screen firings (for instance, if Stompy stands facing left near the left edge of the screen, the range might still be enough to hit an enemy off-screen) but checking if the enemy is visible should work. A simple rectangle-overlap check will tell you (test screen rectangle and enemy sprite rectangle).

Only other suggestion I'd have is to make a little "crosshair" type image that moves over to the target and then sits on them once the lock is established.

Share this comment

Link to comment
mikedoty: That's pretty cool looking. I like how there are cracks in the building in the second screenshot.

ApochPiQ: Yep, basically I have to make sure only to lock on to what's in front of stompy, and also only to enemies currently on screen.

As I delved into some code, I realized again that it will be harder than it appears with what I have.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!