Journey To Mars (Game)

[Stormboy]

Hello, this is my first 2D game in C++. Please take your time to try it and comment. Also, the collision detection isn't perfect and so sometimes you may see the bullet touches the side and passes but there is no effect.

Note: Space button for firing bullets.

Binary (for Windows): https://bitbucket.org/StormboyXZ/journey-to-mars/downloads

Source: https://bitbucket.org/StormboyXZ/journey-to-mars/src

[N36fSL3A]

[semi-joke]Why don't you give us the source instead of sending us a trojan?[/semi-joke]

[Stormboy]

You seriously think its a trojan? Allright, show me the proof. The reason I didn't give the source is, people might not want to get and setup a library just to compile and play a simple game.

[Mats]

Nice job on making your first game! :)

I have a few comments:

Make it so if you hold the arrow keys it's a consistent movement, rather than a pause and then shooting across the screen.
Make it so you can play again when you die, rather than a forced exit.
Delete the bullets when they hit an asteroid.

About the collision detection. It seems like your collision mesh is always skewed to the left, so a bullet just missing to the left actually hits and a bullet just hitting to the right misses.

[N36fSL3A]

Just to make sure. I don't believe it's a virus.

[Stormboy]

@ Matz: Thanks. I had trouble with the collision detection so its based on the absolute-difference between the two object's positions. Can you help me on the collision detection and improve the movement? (Library is SFML)

Collision detection(enemy[i] at windowSize.y+20 is not drawn to the screen in a later part of the code):

if((abs(enemy[i].getPosition().x-bullet.getPosition().x)<=20) && (abs(enemy[i].getPosition().y-bullet.getPosition().y)<=20))
            {
                score+=5;
                aRemaining--;
                enemy[i].setPosition(0, windowSize.y+20);
            }

Movement (in a pollEvent loop):

case sf::Event::KeyPressed:
                if((e.key.code == sf::Keyboard::Left) && ship.getPosition().x > 0)
                    ship.move(-30,0);
                if((e.key.code == sf::Keyboard::Right) && ship.getPosition().x < windowSize.x-71)
                    ship.move(30,0);

[Mats]

I've not used SFML, but you're tempting me to spend time installing it. lol (where did my nice non-programming evening go today?). Anyways, just from looking at this code you posted.

I would put the movement in a timer that flowed nicely. I usually place a movement timer of 0.04 - 0.1s as a condition of execution for the movement in-game. These seem to be values that give seamless movement.

For the collision detection, I'm not quite sure how it is done in SFML, but does it happen to be calculated from a point at the top left corner? This would explain your error and you also will have a y error, which will be far less apparent. Anyway, you could fix the problem by asking something like.

if((abs(enemy[i].getPosition().x-bullet.getPosition().x - n)<=20)

Where n should be the current error, say, 20 pixels or whatever it is.

[N36fSL3A]

Nice game, but I think the bullets should die as soon as they're hit, because you can get 2 in a row with one shot.

Also, you should smooth out the movement, sometimes there's no way to shoot the asteroids because they're off path.

[lockandstrike]

I would be thanked if you could provide the source code for those of us who use linux or other operating systems.

[N36fSL3A]

You should really dualboot with Windows... but yea like he said some people use *nix and macs.

[twiggystardust]

I agree with everyone about the movement, it should be much more fluid, also, unless it was on purpose, you should be able to shoot more than one bullet at a time.

[pivottt]

I didn't try it yet, but I'm making a space shooter engine in SFML for my own game right now, so perhaps I can give you a few tips. As Mats hinted, by default the origin of a sf::Sprite is it's top-left corner. It's very common to change it to the center of the image, so you can rotate, flip or resize the sprite without moving it, and it allows easy collision detection.

For the others who don't know SFML much, this library doesn't do collision detection. It only manages inputs, drawing based on OpenGl, sound and network.

[Stormboy]

Thanks everyone for your wonderful comments :). I'm improving the movement, collision and bullets. When I'm done I'll post the new one with the source code (as some has asked).

[Z e r e o]

pivottt wrote:

As Mats hinted, by default the origin of a sf::Sprite is it's top-left corner. It's very common to change it to the center of the image, so you can rotate, flip or resize the sprite without moving it, and it allows easy collision detection.

The sf::Sprite's origin has nothing to do with collision so not sure how that would make easier collision detection... Changing the transform's origin to the center of a sprite won't effect the rectangle that is returned from sf::Transform::transfromRect(). But otherwise as for changing the origin to the center of the sprite to make transforms like rotation and translation easier you are correct and usually it is a good thing to do.

[Mats]

The sf::Sprite's origin has nothing to do with collision so not sure how that would make easier collision detection...

I had trouble with the collision detection so its based on the absolute-difference between the two object's positions

The reason the origin has to do with collision detection in this case is a distance check is being used rather than mesh collisions.

[Z e r e o]

The reason the origin has to do with collision detection in this case is a distance check is being used rather than mesh collisions.

Totally missed the post where he posted some of his collision code sorry about that ;p. I would highly suggest you change to actual rectangle(sf::Sprite::getGlobalBounds()) collision detection which simplifies things greatly. Once you get the hang of the process a bit more you can start to experiment with other techniques.

[Stormboy]

Hey all, I've fixed most those stuff you've all told me to :). The new version has:
-> Smooth movement
-> Better collision detection
-> Bullet is removed after it hits asteroid

Hope you take your time to try this out and comment.
Link: https://bitbucket.org/StormboyXZ/journey-to-mars/downloads

I'll try and upload the source on Github sometime tomorrow for all those who want it.

Thanks.

[Stormboy]

Update: You can get the source code at my BitBucket repo: https://bitbucket.org/StormboyXZ/journey-to-mars/

[Computergeek01]

Wow! From "Hey guys I want to do this but I haven't even picked a library yet" to "Here is my Alpha" in a little more than a day, that is an accomplishment to be proud of!

A few extremely minor notes now that you've posted your code:

- Copying sprites and setting textures is expensive and it doesn't need to be done at every game loop iteration. This was probably an oversight and should be easy enough to fix with a few Cut & Pastes.

- I noticed that there are four drawings of the ship in your "ship.png" file; if this is because you plan on adding animation in later then I'll just shut up right now otherwise they're all the same so ...

- Your splash screen is your largest image, it is only used once but it stays in memory the whole time. Sure it's only 25KB but this is a perfect time to use the 'new' and 'delete' operators.

- I can't really tell what the Vector variable 'spriteC' is for, if I spent a little more time on it I'm sure it would become obvious but when posting code it's helpful to other people if you run a few Find & Replace operations against your more ambiguously named variables.

Overall great job though. You might want to use the 'sf::Sprite::Rotate(); function to add some simple animation to the Asteroids but that's up to you.

[cire]

Computergeek01 wrote:

Copying sprites and setting textures is expensive

Sprites are lightweight objects. Neither copying them nor setting textures is expensive.

Computergeek01 wrote:

I noticed that there are four drawings of the ship in your "ship.png" file; [...]they're all the same so

You might want to look at that a little more closely - they're not the same.

Computergeek01 wrote:

Your splash screen is your largest image, it is only used once but it stays in memory the whole time. Sure it's only 25KB but this is a perfect time to use the 'new' and 'delete' operators.

I don't see much reason for new and delete here, but limiting the scope of the texture might be in order.