handmade.network » Forums » Work-in-Progress » Handmade Asteroids
den_v
Den V
17 posts

None

#11276 Handmade Asteroids
2 weeks ago

Hello All,

I wanted to share something I've been toying around with in my spare time that was inspired by Handmade Hero.

https://github.com/dvorontsov/asteroids-clone - My toy project in C++ with minimal C++ features. Purpose: to learn to draw and manipulate basics shapes using software rendering techniques and build things from scratch with minimal dependencies.

do {
iLookAtMyCode();
andSeeItNeedsDebugging();
} while(myGuitar.weep(WeepType.GENTLY);
anael
anaël seghezzi
15 posts
1 project
#11279 Handmade Asteroids
2 weeks ago

Hi,
very cool, the code is clear and simple.
It looks like to be Windows only ?
mrmixer
Simon Anciaux
175 posts
#11284 Handmade Asteroids
2 weeks ago Edited by Simon Anciaux on March 13, 2017, 8:04 p.m. Reason: Line brakes in comments

I tested it for a few minutes, here are some comments:
- There are several places in the code were you're using double literals when you could use float. There is also some places where you are storing floating point values in integers or the inverse. The compiler gave me several warnings/errors about that.
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
float a = 1.5f; // The 'f' at the end indicates that the literal is a 32 bits floating point value.
double b = 1.0; // Without the 'f' the value is a 64 bits floating point value (double precision).
float sum = a + 5.0; // If you don't put an 'f' at the end, you're adding a 32 bits value with a 64 bits value.
// The compiler will promote the float (32 bits) to a double (64 bits) for the computation,
// but since we want to store the result as a float, we either have to cast the result to a float or use a float literal.
float sum = a + 5.0f;
float sum = ( float ) ( a + 5.0 );

int c = ( int ) a; // Placing a type in parenthesis in front of a variable will indicates to the compiler
// that you want it to "interpret its type" differently (it's called casting).
// Here 'a' should be interpreted as an int. Since 'a' has a value of 1.5f, the CPU will truncate the value, so 'c' equals 1.


- You are doing collision detection by intersecting lines, but if a bullet move fast enough, it could enter an asteroid and be at its center without any line crossing and do the same to go out and there would be no collisions. If you're interested you can look at GJK (a video of Casey explaining it in 3D but you can do it in 2D, you only need to find a triangle. And it's easier than it looks) or Separating Axis Theorem (SAT).

The rest is about gameplay/features:
- The ship is too big and the screen area is too small (and maximizing the window doesn't work)
- The ship accelerates too fast, and it seems to go faster when you turn and thrust (I didn't check, but maybe you don't use the frame time in you movement computations and if the framerate is higher on my machine, the gameplay is faster than on your machine).
- In asteroids a big part of the game is the fact that if something goes of screen on one side it comes back the other side. In your version for the moment, you can go off screen and get lost.
- In asteroids there is no air friction (it's in space) and no brakes, if you don't turn around and thrust you keep going in the same direction forever.
- I use an azerty keyboard layout so the default layout doesn't work right away. I wrote a post about keyboard input if you're interested.

I'm also working on a small game vastly inspired by asteroids that I hope I'll be able to show soon.

Good luck
den_v
Den V
17 posts

None

#11329 Handmade Asteroids
1 week, 5 days ago

Thank you for taking the time to review my project.

anael,
It is Windows only at the moment. This started as scratch work where I was mimicking Casey's early Handmade Hero lectures where he showed Win platform layer and pixel drawing.

mrmixer,
- I will go through warnings to add casts. Where I store floats in ints I am not worried about precision and I expected implicit cast, but I will work on cleaning up compiler warnings.
- You are right about collision detection. What you described is actually the case that happens. Thanks for the links, I will check it out and review collision code.
- Gameplay is something I didn't prioritize. I was more interested in the technical implementation side. I did add start and end screen, but I don't have any way of completing the game (like score or levels). I also didn't want to do a one to one copy of asteriods with all its gameplay mechanics, so absence of screen wrapping in intentional. I actually did have it at some point, but then removed. I agree on friction, but I don't remember how original asteroids played, so I looked at some current web based implementations, and they had "friction".
- I'll check out your keyboard input guide. Thanks for the link!

do {
iLookAtMyCode();
andSeeItNeedsDebugging();
} while(myGuitar.weep(WeepType.GENTLY);