Asteroid Explorer (Custom physics using verlet integration and SAT)

[whateverest]

screenshot.png (13.69 KiB) Viewed 1928 times

How to play
The goal of the game is find and get to the green target zone.
Touching any terrain leads to instant game over.
Turning and accelerating uses fuel, you can see how much you have left in the top left corner.

Controls:

• Arrow keys: Steer ship
• R: Restart level
• B: Generate new level
• Escape: Quit

Inpired by a (Youtube video) I wanted to try to implement verlet integration and SATand play around with it.
When I was done implementing those, I tried to create a lunar lander-ish game, using my newly created own physics library. The levels are created procedurally.

It went quite okay so far I think, considering the actual game took only around 1 day to make (excluding the countless hours debugging why my verlet and SAT implementations were sometimes failing spectacularly).
Since I originally did not even want to make an actual game, the presentation is rather ugly for now.

My custom verlet and SAT implementations work quite good I think. Some weird bugs I haven't ironed out yet show up from time to time, but nothing gamebreaking.
I really love how simple verlet integration (compared to rigid body stuff) is at its core, but how powerful it is.
I had a lot of fun implementing this and playing around with it.
Even though this example game only features rectangles and triangles, arbitrary convex polygons and also circles are supported.
I might write a blog- and/or forum post about the implementation and properly release the source, if I find the motivation and the spare time. Let me know if you are interested.

The main references I used for implementing the physics were:

• https://github.com/johnBuffer/VerletSFML
• https://www.sevenson.com.au/programming/sat/
• https://gamedev.net/tutorials/programmi ... ics-r2714/

Because I was too lazy to create the level(s) myself I looked into procedual generation.
The levels are generated with a Drunkard Walk-like algorithm.
Even though it is so simple, it sometimes manages to generate somewhat interesting and fun to play layouts.
But unfortunately many levels are either fairly boring or very hard/unbeatable. In the end one can not expect great results when using such a primitive algorithm.
If I continue work on this project this is the main area I want to improve, apart from the presentation.
Maybe I'll check out some "real" maze generation algorithms or cellular automatons. I'm grateful for any suggestions .

For now, if you find such a boring or unbeatable level, you can simply press "B" to generate another one.

Things I really would like to add and change are:

• Presentation: Replace the placeholder "graphics" with better ones and maybe add sound
• Generate more interesting levels.
• More danger (eg. faling rocks)
• More interesting goals (eg. landing)

As I see it, the game could also be expanded in various other ways, including but not limited to:

• Items (eg. Fuel canisters in the caves)
• Progression
  • Ship upgrades
  • Collectables in the cave which you could sell to get ship upgrades
• Destructible terrain

Art and libaries used

• https://opengameart.org/content/spark-effect
• https://github.com/kikito/gamera

[steVeRoll]

This is surprisingly good! At first, I was super infuriated with the controls, but after completing two levels I somehow really got into it! The randomly generated levels are fun to navigate.

With that, I think the slipperiness of the turning controls is a bit too unforgiving, and could use a bit more friction.

The main thing I'd like to see this game have is some kind of motivation to progress through levels.

[dusoft]

Yeah, the controls are difficult. Either disable the engine when using left-right side arrows or lower the angular velocity. This is hardly playable, which is a pity, because otherwise it looks like an interesting game.

[pgimeno]

This looks like a mix of Thrust (which uses fuel) and Thrust II (which is about exploring caves, sometimes with narrow paths). I agree with the others that the rotational inertia makes it quite difficult. I wrote a remake of Thrust II (Thrust II Reloaded, see sig) using also Verlet integration, but I the collision I'm using is pixel collision instead of SAT, as the graphics could vary.

[whateverest]

Thank you very much for trying out the game and for the feedback.

With that, I think the slipperiness of the turning controls is a bit too unforgiving, and could use a bit more friction.

Yeah, the controls are difficult. Either disable the engine when using left-right side arrows or lower the angular velocity. This is hardly playable, which is a pity, because otherwise it looks like an interesting game.

I hear you. I quite like the punishing controls, but I may have taken it too far. I want risky moves to be... well risky, and not impossible
Simply adding more friction seems like a great Idea, I will try that out. Thanks!

The main thing I'd like to see this game have is some kind of motivation to progress through levels.

Yeah the first thing hat comes to mind would be some kind of "rougelike" Mode? Levels get progressively harder (longer) and you can upgrade your ship (better handling, more fuel) between levels. At the end you can see your stats and share the seed for the run.
That should be simple enough to implement and I can easily expand on that later.

This looks like a mix of Thrust (which uses fuel) and Thrust II (which is about exploring caves, sometimes with narrow paths). I agree with the others that the rotational inertia makes it quite difficult. I wrote a remake of Thrust II (Thrust II Reloaded, see sig) using also Verlet integration, but I the collision I'm using is pixel collision instead of SAT, as the graphics could vary.

LOL, I actually wasn't aware of Thrust 1&2 or your Remake. Your Remake looks really cool, I'm going to have to try it out!

[whateverest]

I updated the game, here's what's new:

• Big changes to the handling of the ship. The most notable being the addition of friction for angular and linear velocity.
• Improvements to rendering and collision detection allowing for larger levels
• Tweaked the level generation algorithm. I'll still want to switch so something more advanced in the future but it seems okay for now.
• Visual Improvements. Stars in the Background and started using actual sprites (only the ship for now because I'm terrible at art)

The game is still quite hard, but it feels a lot more responsive now it think.

The baseline that's missing before you can call it an "actual game" would be the following. I'll try to work on those next.

• Sprites for the caves
• Progression (Rougelike Mode)

[steVeRoll]

Tried the new version, the friction on the angular velocity is definitely appreciated! However, I did notice that on more levels than usual, the amount of fuel you have sometimes doesn't allow you to reach the goal. Conserving fuel would definitely make for a good challenge, but I think it's a bit too extreme as it is now.

Also, this game actually reminds me of another quite similar game, also made in löve, called Vector Prospector.

[noone]

I get an error on startup.

Code: Select all

Error

stars.lua:9: Cannot create texture: pixel height of 10000 is too large for this system.

Traceback

[love "callbacks.lua"]:228: in function 'handler'
[C]: in function 'newCanvas'
stars.lua:9: in function 'generateCanvas'
main.lua:159: in function 'randomlevel1'
main.lua:80: in function 'keypressed'
input.lua:31: in function <input.lua:22>
[love "callbacks.lua"]:154: in function <[love "callbacks.lua"]:144>
[C]: in function 'xpcall'

I wonder if it's from having multiple monitors? I just took a quick peek as I'm just checking out examples to see what people are doing with the platform. Thanks for sharing your work.

[noone]

I resized the window to something smaller and get the same error. Maybe because I am using 11.4 from the Debian repo (Bookworm).

[whateverest]

I get an error on startup.
...

Thank you very much for the stacktrace! I managed to find the error. At the start of each level I am rendering some "stars" randomly to a canvas which I am using as a background. This works fairly well performance wise. But I hard-coded the canvas to be 10000/10000 pixels in size. Turns out that this is too large for some systems. Luckily one can use love.graphics.getSystemLimits().texturesize to query the max canvas size.

As a quick fix I simply prevent the background canvas size from being larger than the maximum supported value. To make the background not simply drop off I should repeat it for smaller max texturesize values in the future.

I attached a new version in my post. You should be able to check out the project now noone .

...
Also, this game actually reminds me of another quite similar game, also made in löve, called Vector Prospector.

Aww, man... that game looks cool and I did not know this one either. My project does look like a pretty cheap copy of that game though .


I uploaded a new Version, lets call it "0.3" with quite a lot of changes, the most notable ones being:

• A Basic rougelike mode. Endless for now. Levels get progressively longer and thus hopefully harder.
• Stats. At the end of a run you can see a summary how far you have gotten and how long you have taken. You can copy the stats and the seed.
• A basic upgrade system. For now you can upgrade one of two different stats every 3 levels.
• Editable seeds. When starting the game you can edit, copy(ctrl+c) or paste(ctrl+v) the seed for the run.

Now I should finally get to work on the ui and sprites next. Also the game could use some refactoring .