Your thoughts? Alien Landscapes

This is getting critique ready, i think. As usual, there's too much happening on the same single screen.
I did a short writeup here on the process.

What's your thoughts?

Looks really cool. Sorry that I can't provide any constructive critique.

Very nice!! That seems a little "organic" and futuristic.
Reminds me some MegaMan stages, a bit of Street Fighter 2010 and Journey to Silius.
I'm looking forward to see this game finished!!

It will be awhile. I'm pretty slow as a programmer. My previous games took 1-3 years :-/ But working with Frankengraphics will inspire me to keep moving.

Reminds me of Super Metroid, slightly. Secondary colors +gray looks very alien.

Yeah, I was going to say the same! Looks really good!

Having played sf2010 yesterday, it reminded me of it too, which is great. There's one thought on my mind looking at that screenshot: "I want to play this". That's also great.
Now for critique, what would I change? Maybe add some details on the sky like horizontal black lines. Otherwise it looks pretty tight, congrats.

I like the use of colors a lot, gets around the usually very apparent palette limit in a better way than most other NES games.

Still trying to make that Metroid clone, I see.

Jokes aside, your creative use of the attribute grid and hinting at details hidden by the black amoeba are impressive as always. The only critique I have is that the sky seems to clash with the foreground. There doesn't seem to be any other source of light, so it feels like the foreground should be warmer and darker to go with the sunset look. Just a thought.

Please. Take your time and do the best you can.
I don't mind waiting for 5 or even 10 years to play a great game!!

Thanks, all! Detailing the sky is something i've attempted more than once and didn't feel satisfied with, so i simply removed those elements. I should give it at least another go and see if something good comes out of it. Assuming the skyline is two screens high, something should come above.

Oh. I was hoping the cold colouring would convey a sense of flourescence emanating from the amoebeous ground. Here's a snapshot from a previous stage. I believe what maybe got lost in the process is the sense of where the sunset is reaching and where there's shadow. But, it's also possible with the current tileset to get darker patches of ground like in the snapshot, aswell as areas where the light should touch. Maybe the flourescent effect shouldn't be all over the intended final level design. Colours might change, too.

Very useful critique, both! And the other nice comments are also very encouraging.

re: metroid - guilty as charged! Though gauauu proposed that it should be a vehicular platformer, so i think the connection to blaster master will become more evident, eventually. I also took inspiration from moon patrol which i view as an early precursor to blaster master (it has a very distinct aesthetic) but maybe that doesn't show under all the h.r.gigerism

I've always dreamed of doing a sort of metroid/blaster master mashup. I'm excited to see where we'll go with it.

I noticed this on your blog and the write-up makes some very good and useful reading on setting design.

Absolutely gorgeous. I especially dig the hue ramps in each sub-palette, and the red-highlighted sub-palettes used for ground and wall tiles that appear above the horizon, eliminating what would otherwise be a black, squared borders.

My only nitpick might be that the attribute borders are sometimes too noticeable (although other times well-hidden like for the bulbous stalks), giving it a bit of a ZX Spectrum feel. However, I don't know if it would be beneficial or a drawback to the overall palette to reduce the total color count to make those borders less noticeable, so take that with a grain of salt.

Also, since sprite contrast and scale are important, it'd be helpful to see these with some intended sprites on them.

Can't wait to see more.

Thanks! I thought it was helpful to me to try to think in terms of materials and history rather than just narrative function, so i wrote it down as a reminder. I'm glad you found it useful too, m-tee!

These drafts haven't passed consensus, but since you asked, here's a first go at it. Whether they'll be used or not, it might make for a good discussion and help me spot problems in an early stage.

The premise is that the player character builds a vehicle out of the scraps of a landing/escape pod and whatever tech that can be found near the landing site. It's very uncertain how big of a role this possible feature will have. I wanted the world to feel large and imposing vs the player, so that's added into the soup (technically, it helps keep the spritecount down). Moreover, i think i'd want players to see their avatar at any point in the game. It makes for a slightly more vulnerable impression. If hit boxes are kept separate, the vehicle would provide some partial shielding for the player character. It might also be useful for quick mario-abandons-yoshi jump combos. The hover bike is meant have good horizontal speed but not quite the vertical reach of a simple jump/jetpack boost. Jumping off a moving bike would retain the horizontal momentum.

The 'red' colour on the vehicle can be changed or animated to reflect active properties or states. Active function, weaponry, or the status of some energy reserve, for example. Likewise, the colour of the suit can be changed to mark some change.

So far, I'm getting a Blaster Master vibe.


...aaaaand there's the big difference.

Two different idle animations for the player character prototype. The goal of the former is to text to the player that the surroundings are new and unknown to the player character. The latter is for conveying some sort of threat level in a subtle way (perhaps enemies/dangers nearby or hurt/low health).

I was going to do a quicker, more dramatic turn (player is pressing l/r, or something scripted happens while idle) but then the media encoder crapped out, so this will do for tonight.



Any thoughts?

Former feels more like idle; latter with the foot motion feels more like "crap, I'm surrounded". ed: the second sentence says exactly that. :blush: Good job, me! (Means they successfully convey them!)

I like how the torso L/R tiles change at different frames granting more animation without adding more tiles.

Visor reminds me of Samus a bit.

The torso cascade seen in surveying.gif actually adds two tiles, because i was being nitpicky with details at the border doubling/disappearing. They could be cut out in a pinch when the time comes to prioritize, and/or i could leave out those details altogether.

The samus likeness of the helmet was unintentional. I wanted to keep the PC at a 2 tile height when hunched over the hover-bike, which resulted in a squat helmet design. But if it's too samus like, i might want to reconsider. For instance:

Don't think about it. It looks like a stereotypical "space helmet", which I think it needs to convey that idea in low resolution graphics.

Samus' helmet is also a stereotypical space helmet - you can only do so much with that concept.

As generic as it gets, i had lego's "classic space" suite from 1979 in mind to represent human technology. Even if those wings etc don't make sense in space.

I think the 1st one is nicer.
The guy seems to be given a quick look around so he/she can think about what to do next.
In the second just seems like the guy got surrounded and needs to quickly find a way out.

By the way, the character remembers me a bit of the robot from movie The Day the Earth Stood Still.

I don't see a Samus likeness at all. The slighlty footballish helmet shape is unique enough to give a strong silhouette, and I prefer it to the post-Samus-comparison alternative that you posted more recently.

For the idle stances, I like the idea of two sets of animation, but they are too similar to pull off the "in danger" and "not in danger". Perhaps for the in-danger: legs wider apart, arms out, looking more ready for danger. I think somewhat stronger, exaggerated gesture and body language would be vital for conveying information at that size.

Only console maker politics keeps Samus from thinking Master Chief is a pretty cool guy.

If it looks as much like a SPACE MARINE® from Warhammer 40,000 or a Spartan in Mjolnir Powered Assault Armor from Halo as it does Samus, you might be safe.

Thanks for your comments. They're very helpful, as always. I think we need to sort out a few specifications before i continue animations.

I've repurposed this mockup by replacing humanoid elements with something that'll work for the mythos of project, since the styles were close. I also felt that some of the more symbolic representations of gauges and controls didn't work seamlessly for this sort of style.

Measures have been taken to introduce depth, among them reducing the overall contrast in rearmost objects.

Here's two alternatives. One is using 3 subpalettes, the other 4. Pro's and cons: The former is naturally more flexible, we could for example use the fourh subpalette to make tile based enemies stand out. The latter brings out the vivid colours better by being somber as a contrast on the saturation plane. It is perhaps even more "16 bit like". Other than that, i'm eager to see what you have to say.


(edit: the second one also got just a little more detail work done, don't let that get in the way)

Of the two, I'd say the additional green highlights aren't adding enough visual interest to sacrifice a full subpalette for, especially if said subpalette could be used for something else such as, like you said, BG-based enemies or even a new element for the background or for other sections of an area.

That's reassuring to hear. I can manage to emulate the grey fadeout on the wire decor with the 3rd palette only (in this case, green fadeout). This snapshot is back at 3 subpalettes only. Added shadows for a bit more depth.

Another template, using 74 tiles. A few of them are a bit redundant.

Very nice !

Ok, so this is a VERY rough level concept. It is there to help us discern what sort of extra tiles we need to add in, what tiles should be reworked, and so on. One thing we've established is that all solids should have a stronger/brighter emphasis, since there's so much background stuff using the same subpalettes.

We have all-directional scrolling, so that should help levels convey things like smaller structures within the cave system (like in the lower half).

Let us know what you think.

I'm really impressed with how well you've worked a richly textured background in.

I think you're inspiring me to work faster. I want to test this level.

If it's not too big a hurdle to throw in a concept like this (with the help of a rough/automatic metatile converter?), it'd be exciting to see how it fares in your engine at this point.

Some changes for tonight:
-Rock colouring is now regional, rather than random. A "green" area is hinted at the bottom right, and there's a single green "milestone" in the bottom left quarter. My hopes is that things like that will help orientation in a larger, sprawling cave system.

-Made rocks have quite a brighter outline.

-More distinctly diagonal shadows on the pillars in the bottom right quarter seems to help my depth perception.

-various details and decorations added.

-still plenty of room: about half of the bg-chr is unused.

I think (hope) the engine should handle it just fine, but getting it into the engine will take some work. While I have a tool to manually edit metailes, creating them is slow work. I think you're right, I need some tool to automagically generate at least a rough start of them, from whatever format you're working with (what format/tool ARE you working with?)

Dayuuuum, you're on fire! I feel bad for dragging the chain on your other project.

I might be able to adapt my automatic metatile builder for this one instead, if that would be any help. What do you need? How soon do you need it?

That might be awesome. We're using 32x32 pixel metatiles, so just computing the different metatiles (ie which tiles make up each one) needed to make the map would be a huge start, in whatever format.

I also store collision and palette information (per 16x16 block) with the metatile definitions, but that's easier to add manually.

It's NESST:s .map format; in other words raw nametables but with arbitrary x & y dimensions. This one equals four full nametables. palette and chr data stored in separate binaries (.pal & .chr)

All can of course be converted to any reasonable bitmap/indexed format, bur i believe that's for the worse (palette entries might be mangled/misinterpreted).

Also.. damn, i didn't remember if we said 1 air/solid entry per 16x16px, and how that entry would be set up. This mockup contains quite a few solid/air mixes in some 2x2t cells. It's easy enough to correct if this doesn't work, but i was kind of hoping for mixed properties

rahsennor: Nah, it's all good!

My tilecoords tool can do part of that: given an image and a tileset, it will print the number of each tile. Processing that to 4x4 metatiles should be easily scriptable.

https://github.com/clbr/nes/tree/master/tools

Yeah, right now the engine only supports collision at the 16x16 granularity. (1 byte of collision information per metatile, which allows 2 bits per "block", allowing for 4 different collision levels, most likely "open", "blocked", "lava/water" and "destructable"). It wouldn't be terribly hard to switch to 2 bytes of collision information per metatile, allowing for a lot more flexibility.

The important factor is how the 8x8-level collision tiles are arranged. Right now for something like this,
, I'd have to do more collision checks for each actor, to make sure they don't straddle it (I'd have to do a check every 8 pixels along the width of the actor) and I'm afraid I'd be spending too much of my cpu budget on collision checks. If we don't allow this sort of configuration, it will be a lot cheaper.

I'd say send me the screen tool data, and I'll play with it

i'll send it right away!

Right, because y collisions doesn't need to happen as much as x ones.

Here's a basis for further discussion on collision granularity.

The example you posted is something i'd avoid regardless. A bump like that would be there to either:
- incentivize a jump over it
- provide partial cover
- stop/turn around walking NPC:s

All of which could be done with a 2 wide platform just as well. A 2 wide, 2 high platform would be more radically different, though.

The rest of the picture tries to demonstrate how various wide gaps (rather than bumps) could interact with our player controlled objects.

A two-wide gap looks a bit awkward for the vehicle (better just avoid it?) A one-wide and it'll pass over smoothly. A three or four gap would stop it dead in its tracks and risks being a nuisance. Except if...

We had a tilted climbing animation for the vehicle (that's the thing with caterpillar treads, innit?) and made it auto-climb one-step-ups. The hover-bike would naturally hover, so no problem there (i imagine it has a slew rate when falling and would anticipate/adjust to slight rises).

Maybe 2-wide gaps wouldn't look so bad either with the tilted tread cel.

Speaking of auto-climb, the "squat over bike" pose just happened to be a pretty close match to a first cel in a potential (auto?)climbing move for the player character. This would have a precursor in later 2d metroid games.

For the player character, two-wide gaps are perfectly sound to stand in. One-wide gaps looks a bit squeezed as the PC is at least 10px wide at the base when standing.

I figured one benefit would have been that the PC could fall in narrow gaps where the vehicle can't, but it'll still look squeezey. Also, we could achieve the same with some sort of ladder mechanism if we wanted to (as does BM, for comparison).

Pushing blocks/puzzle mechanisms isn't anything we have in our design notes so far. I added that implication in just for fun scavenging tiles from the squat pose and shooting pose.

If 8x, 8y is a guarantee for cycles down the drain in a very general sense, I think these factors makes me lean towards a 16x, 8y granularity. Does that make sense?

Absolutely beautiful work; I am very impressed! It can be difficult with limited colors to create enough contrast between the foreground and background, and you've done an amazing job at that.

I'm unsure if you've made any changes to the original image you posted in this thread, but I did have one thought. First, the foreground looks amazing, so great job on that. The dithering on the mountains (mountains, right?) in the background seems a little busy. It might be beneficial to shorten the dithered lines, maybe to half length. Not sure what your thoughts are on that...

I saw this on your blog and was impressed, the glowing part is really nice.

It would probably look quite nice on a CRT with the colours mashing into one another. (I can take a shot if you make a rom)

During extra-vehicular exploration, the player will see the character running a lot. I think it's important to make this animation last long. Let me know if anything stands out the wrong way.

Here's what i have at this point:


The vehicle is being redesigned.

Very smooth, I like it! One thing that bothers me though is that the head bob seems a little abrupt, and not exactly in sync with the movement of the body. I don't know what the problem could be, it just feels a little off to me.

Awesome work! As for the head bob, I'd delay it even more (i.e. it bounces down a couple of frames after each foot lands). It should give it more weight as reflected by higher inertia.

There's a hitch in frames 15 and 16. The left leg does not move between these frames. To compensate, the leg moves way too far in between frames 16 and 1.

It may be a stylistic choice, but heads don't turn that much while running.

Good catches!

-toned down the head turning. saved a tile to boot.
-spent it on adding another leg tile to smooth out a transition
-helmet now bobs in reaction to touching ground, rather than in reaction to the force of leaps. Definitely changes its weight.

There may be some pixling left to do but i think the tile references are alright by now? Thanks for your suggestions, everybody!