Lunar Lander

[erico]

From your first post...

Yeah, I also get the feeling ship movement+scroll would be too weird to handle a small unprecise few pixels ship.
I thought maybe the scroll could happen on the borders but it would still be a mess to handle in flight on a tough area.

There was a win 95 lander long ago that would scroll the screen when landed to present the next challenge, could this work?
It would be troublesome when newer paths appears, maybe we could freeze game and scroll when player reaches a specific border?
That is a tough part to think about, I think it would be nice to have a scroll so in mind the player can picture the whole area he is traversing.
But if it is better to keep it out, I´m fine. You are coding, your call, it is better that I adapt my part to what you think is a better way to go.

[erico]

No problem with sprites, although for terrain I'd probably prefer to keep it free-form. It means people can just use PAINT.NET or whatever for level design without being constrained to a fixed set of terrain tiles.

Super! I´d prefer it that way too, so we could go wild on the scenery.

Awesome, thanks! Grey-scale is fine, just post them here as PNG or something.

Nice, I´ve done some simple PB stuff and grey, will post what I have for testing, but I will sure then use grey everywhere on final art.

One last thing....I'm going to create a GIT repository for this project, what do you want to call it?

Hmmm, hard call, if we are going to shot for an original game, then an original name is a must.
But I guess for the hub it could be anything (for production´s sake) if we can change it later.

Here is a sprite sheet of the player and a couple 9 screen levels, one organized as 3x3 screen and another as a snake form.
Are those ok for testing? I colored green the start, red the inbetweens and blue the end.
It may not fit our changes (no scroll), but you can use them as you must.
I guess getting a proper feeling of the ship is the more important part gameplay wise.

Like I said before, we could also have a hud with a 5 pixels line cross depicting the finetune approach velocities, like 0 or 1 pixel away from center is fine, 2 or above is a crash(or damage). Or something like this if it becomes too hard to sense a small pixel ship landing.

I thought the ship could also have a hull, so you could crash a few times before exploding, single life game, exploding means the end.
On the players sprite, the main fire could animatedly alternate between the fires of the side versions, keeping the white point central.

Other thoughts were about the environment, we could have winds too.
I´m just pushing some ideas, fell free to dismiss them as needed in code.

EDIT: While the sprites fully rotate, I guess the lower part is fine if we can rotate and flip. Also, in the middle you have a landing gear animation, and an animation of the weak thrust.

[Myndale]

but I will sure then use grey everywhere on final art.

Are you planning on using it for the terrain as well? It's not a huge problem if you are, but it will increase memory requirements obviously and we might have issues with flicker if you're using it in large areas. With flames and sprites etc it doesn't matter of course, and actually looks quite good.

Are those ok for testing?

Perfect, thanks! One thing I might do if it's ok with you is have the script elevate the platforms by 1 pixel and place them on top of two other pixels, like you did in your original image, just to make it really clear that it's a landing pad. Can always change/tweak it later.

Memory-wise these images aren't compressing as well as my large test image, but these have more detail so it's expected. Mission1 is 1524 bytes and mission 2 is 1776...still too large for RAM so we'll have to restrict the number of missions at first and then I'll add flash-loading support later so they can be loaded into Flash memory from the SD card.

I have plenty to get started with now, will post an update here when I have something running...

[erico]

Are you planning on using it for the terrain as well? It's not a huge problem if you are, but it will increase memory requirements obviously and we might have issues with flicker if you're using it in large areas. With flames and sprites etc it doesn't matter of course, and actually looks quite good.

I did, and also thought about grey background parallax scrolling half speed
Just joking, I will consider sprites only then.

Perfect, thanks! One thing I might do if it's ok with you is have the script elevate the platforms by 1 pixel and place them on top of two other pixels, like you did in your original image, just to make it really clear that it's a landing pad. Can always change/tweak it later.

All fine, don´t bother, let me know if I have to change the test images to work with it.

Memory-wise these images aren't compressing as well as my large test image, but these have more detail so it's expected. Mission1 is 1524 bytes and mission 2 is 1776...still too large for RAM so we'll have to restrict the number of missions at first and then I'll add flash-loading support later so they can be loaded into Flash memory from the SD card.

Heck that is not bad, I first thought to have only a single mission to boot...

I have plenty to get started with now, will post an update here when I have something running...

Nice, I will be thinking and drawing some extensions of what we have set so far and I will wait for the test.
If there is anything you may need while doing so, let me know.

Thanks Myndale, it is a great opportunity for me to be able to work with you.

[yodasvideoarcade]

I think this thread should be moved over to Game Development, since it's discussion about a work-in-progress.

[Myndale]

I think this thread should be moved over to Game Development, since it's discussion about a work-in-progress.

Done!

[Myndale]

I did, and also thought about grey background parallax scrolling half speed

Actually parallax scrolling shouldn't be a problem at all as far as performance goes, the problem is that we're not doing foreground scrolling to begin with so it's a bit difficult seeing how we'd incorporate it in.

Heck that is not bad, I first thought to have only a single mission to boot...

I like your idea of different missions on the same map, means we can add a lot more game play from whatever maps we do add.

Thanks Myndale, it is a great opportunity for me to be able to work with you.

Likewise! Yoda's beaten us to the punch with a playable Lunar Lander game, I'm gonna go check it out now. Still battling the end-effects of the flu here but I should have something playable using your maps in another day or two.

[erico]

Take your time and get well, the later is more important.

If we are going to go for a no scroll (or just when landed), then each screen must be designed to fit the next one, so they kind of share points.
I think the parallax won´t do much for us, so it may be scrapped.

Maybe scroll to present the new area should happen if player decides to go one way or the other.
I would make it harder for an editor me guesses as one will have to design a level with that in mind considering screen sharing.

But that is just me thinking, maybe the ability to chose is not that good at all.

Again, get well first and we proceed later.

edit: flu...cachaça+lemon+honey

[yodasvideoarcade]

Haha! flu...cachaça+lemon+honey - I'd call that a Honeypirinha or something, not a medicine. But maybe for Brazilians it works ...

I think the most important thing you should think about is how to store landscapes, especially if they're larger than one screen, and not use too much memory for it.

[Myndale]

Haha! flu...cachaça+lemon+honey - I'd call that a Honeypirinha or something, not a medicine. But maybe for Brazilians it works ...

I'm happy to take advice from any country that has a decent football team! I've been taking Lemsip (paracetamol) with brandy and lemon and honey. Never tried Cachaça but I have a strong sweet tooth and I know a place sells it a few blocks down the road so I think I might have to try it out!

I think the most important thing you should think about is how to store landscapes, especially if they're larger than one screen, and not use too much memory for it.

Agreed! I did have a peek at your source code to see how you were doing it, 38 bytes per level is fantastic but I think erico and I are aiming for something with a bit more flexibility than a tile-based solution. I'm currently at about 170 bytes per screen, hopefully I can drive that a lot harder in the days to come.