3d Asteroids experiment

Game Engine Works in Progress and Game Demos
1

Here’s a 3-d, 6 degree of freedom asteroids game, an exercise to get familiar with Blender.

blend file: http://www.tomlechner.com/games/Asteroids.blend

(yikes the youtube image preview looks really ugly!!)

Being my first try at really anything in blender, I’m sure there’s a lot of stuff that I’ve not done in a reasonable manner…

Some problems still to be solved:

Text is rather annoying. Using dynamic text objects for the moment, with a terrible hack to get it to not be pixelated, I need to figure out the text as texture approach. I tried to use the text sheet creation program at ashid.sk, but it won’t run for me…

There’s a horrible stutter that sometimes crashes the game when blowing up asteroids nearby. It just involves spinning objects that are not supposed to be collidable, but somehow, physics starts hogging everything, resulting in the stutter… Doesn’t happen when further away. Otherwise, it stays around 60 fps pretty constantly.

I tried to use an equirectangular image mapped to a uv sphere, but around the poles there was a horrible pinching, even when the unwrapping had full rectangles for the polar polygons. It seemed the default shader was dividing that square into two triangles, and favoring one. The square is distorted into a triangle, so the result is only one half of the square is visible. Arrrgg!!! For a star field, this is very noticeable. Tried to triangulate, but got frustrated. To fix this, I remapped to a star-cube instead of a star-dome.

Some objects I tried to have a local spin, but when parented to another object that was spinning, the spins didn’t compound. Is there an easy way to do that? Ended up having a script keep the object origins synchronized, and no explicit parenting.

2

Opinions:
It would be super neat if this had the original-styled repeating asteroid field (not sure how that would be accomplished).
As far as being true to Asteroids, the motion seems a little too tight. Maybe some more thruster-based momentum?
Would the camera be better somewhere else? I feel like fixed behind the ship kind of limits the player FOV. Does it need a radar readout? Or would it make sense to have a fixed-angle camera in a position closer to the original game?

anyway, looking good so far! I like the concept, I’d like to see it develop.

3

I like the Gfx of the game, especially when you shoot an asteroid. Looks really neat.

4

Thanks!

I’ve thought about a repeating field… like having “shadow” asteroids in adjacent world cubes, then when the ship goes to an adjacent cube, it’s position is just wrapped to the other side of the original cube. It would mean having quite a lot of shadow objects per asteroid… I’d have to do a stress test to see if that would destroy frame rates… The bouncy edge force field is definitely easier to implement, and kind of fun in its own right too, though. Possibly non spherical bounce fields would be fun.

I do have an overview camera (press ` ), but since it’s not 2d, it becomes very hard to navigate with just a fixed point camera. The thrust is all momentum based. It does top out, but I’ll probably make that optional just to be more “space” like. You can toggle the auto-orient to camera view (called mouse steering in options) so the camera can look along side the ship instead of always from behind. In that case, pressing right mouse button orients the ship to the camera. Also, mouse wheel adjusts distance of camera to the ship. I need to implement a first person mode, though.

Radar… absolutely! I have a proximity sensor kind of working, shows a distance number to closest object but the text issue destroys frame rate when text is large. Still trying to figure out ray casting mechanics. Then I’ll probably do a more thorough radar.

If i ever have time, I want to do something with giant space slugs that consume the energy of the bullets. And huge asteroids with tunnels.

5

You could probably get away with a repeating field if you only rendered one repeat (for a total of 26 duplicates, which would only be instances and therefor not add much to memory) and had a short fog falloff (instead of fog, you could fade to black, which is the same thing but styled spacey). Then it would look less like you’re stuck in a time paradox and more just like you’re in a vast field that slowly gets whittled down to nothing.

6

Hmm… in a typical game, I’ve ended having about 200 asteroids floating around at any one time…5200 extra objects might be a stretch, but it would be a good experiment… I wonder if instead I could render different viewpoints, as if taken from the current camera, then make those renders visible along the faces of the current cube. I’m not sure how to capture such different views, or apply them in realtime if I had them though!

7

Again, it wouldn’t be 5200 extra objects, it would be 5200 extra instances. Maybe I’m overestimating the capabilities of the BGE, but it seems plausible it could work. You could optimize it by only showing asteroids that appear in the camera frame, as well.

and besides, it’s not really necessary (or that valuable, to be frank) to give the player the ability to decide the exact parameters of the game. Just design it to be fun, and work on reasonable hardware.

8

Did a test with just having “shadow” objects in adjacent cubes… Slows down frame rate from 60 to about 3. I use (add actuator).instantAddObject() to get new objects. I don’t know if there’s a better, more lightweight way.

There are still some optimizations to try, but the other thing about cubic repeating I see from the test is that the cubes would have to be rather large to make adjacent cubes appear further away, and not look like an obvious lattice structure, at least from a 3rd person camera… The density of asteroids crashing around also suffers a great deal for larger world sizes, as everything spreads out so much. It’s a lot more fun with high density. In short, repeating cubic space asteroid fields, not so easy for now!