Mars Lander. Any collaborators? Noobs welcome.

[togFox]

Yep cool. I'll just plod on and not let the field distract me and deal with conflicts if they happen. So far we have been deligent and it hasn't been an issue.

I'm going to add a 'damage' tracker so the lander can be damaged.

[togFox]

v0.09
https://github.com/togfoxy/MarsLander/releases

I think we can collectively produce something really neat.

[Philbywhizz]

Yes, it is starting to look cool now.

I've just submitted a PR that adds a player name label to your lander (and also displays any network ones).

[togFox]

Heh. Cute.

Untitled.png (19.34 KiB) Viewed 9123 times

[togFox]

Mars is red so I changed the surface colour. Better or worse? Too much? Perhaps a different shade?

Untitled.png (245.08 KiB) Viewed 9113 times

[Gunroar:Cannon()]

Looks pretty okay, though a little bit too pink. Ehmm...I use a limited palette called Metal Mix. Try {183/255, 90/255,45/255}. I made that colour from the palette choices, but it still may not work. I dunno.

[MadByte]

Here a video roughly showing how I'll try to generate the terrain. I'll try to allow limited terrain overhang to both sides to get more diverse terrain.
Basically the idea is to let the algorithm step from left to right (or back to left based on the overhang limits), selecting tiles by matching the previous one while filling tiles underneath until hitting another tile (to account for overhang, not fill spaces the player could fly to) or the bottom of the screen.

edit. I just realized that one tile overhangs like the one in the video wouldn't work with filling tiles underneath until hitting another tile. So overhangs would need to be at least two tiles in height I guess.



not sure how collsions will be handled yet. Maybe checking tile vs object bounding boxes and if there's a bounding box collision, check if pixels of the sprites overlap to get a per-pixel collision? Only the top layer of tiles will have bounding boxes of course.

If this is a stupid idea feel free to let me know

[togFox]

I like the way it looks and I can see this is a demo.

The game will hopefully be co-op/multiplayer so I was hoping the terrain is deterministic. That means an algorithm will determine the same terrain for every client. The current code currently does this.

It will also need to be procedural meaning extend forever - or at least for a very long time. The current code also does this (until it runs out of memory).

I like the look and feel. I'm not sure how collisions can be managed.

What if we turned this around and used the current drawing and collision detection but swapped out the simplex/perlin noise algorithm (or adjusted it) to determine that first stage canvass thing you did? Hard to explain.

1) use an algorithm on every client to determine the 'cells' that will make up the terrain.

2) use the current drawing and collision system to draw those triangles, slopes and angles within those cells.

This would have the same look and feel with collision detection.

edit: on another subject, I've made the window fullscreen by default. I've tested on two different monitors and three different resolutions. Please let me know if I somehow stuffed that up. It's commited to main branch but not yet 'released'.

[Philbywhizz]

I don't like that it is full screen by default.

Full screen looks great though! (I have a repurposed 27" iMac running linux), but its a bit cumbersome switching back and forwards between full screen and window mode when developing (having a large screen means I have multiple windows and tabs open, and I lose all my debug monitoring and variable watch screens.

Maybe I need to work on that settings screen and full screen mode toggle can be one of the options

[togFox]

Yeah - I hear you. I'll add a debug option that sets it to window mode for us devs.