Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - eishiya
Pages: 1 ... 26 27 [28] 29 30 ... 127

271
Devlogs & Projects / Re: Small Living World - Colors Feedback
« on: October 24, 2018, 05:33:13 pm »
Hue-shifting might make more sense if you understand the three components of a colour:
Value is how dark or light a colour is. A lower value means a darker colour, while a higher value means a lighter colour.
Saturation is how intense a colour is. Low saturation means the colour is grey-ish (0 saturation = grey), high saturation means it's intense. Neon colours have high saturation, earthy ones have low saturation.
Hue is the "colour" identity. Red, yellow, violet, blue, cyan, etc, these are hues. Combined with saturation and value, you get specific colours.


When I speak of "ramps", I am referring to the colour "gradients" that your objects use, typically these cover a range of values, so you might have a ramp of dark, midtone, and light greens for a tree, so that you can have both shaded and lit areas.
Hue-shifting means making the hue vary between different parts of the ramps instead of keeping the hue the same throughout.



Gradients are just a matter of choosing your colours, and the number of steps the gradients will have, aren't they? So, to avoid a "pixelated" look you just need more steps.
To help the gradients look better, choose start and end colours of different hues (i.e. hue-shifting). If possible, consider passing through a third colour in the middle, to add more variety/"life" to the gradient.
Another factor is your actual math for calculating the in-between colours. Some formulas give nicer results than others. Calculating RGB values directly tends to make the middle colours look greyish and dull, working with HSV or Lab numbers tends to give better results that naturally pass through other hues in the middle, rather than going through grey.

For your clouds, maybe consider generating them more like how you generate those narrow trees - out of a bunch of solid-coloured circles. That'll give you a fluffy cloud look. Have the darkest circles at the bottom, and draw the lighter circles above and in front of the darker ones. If you give each circle a random offset when it's generated, you can get some pretty nice results:

This example uses circles of all the same sizes, but you can also vary the circle sizes. It also only needs a few different colours to be generated to look nice. I don't know how dynamic the clouds are in your game, but this style of generating them can be moved, it can fade out, and can even change over time (the circle offsets can change, and the colours assigned to each circle can change), it works pretty well with procedural generation and procedural animation.
The same method could work for the larger round trees, too.

272
Devlogs & Projects / Re: Small Living World - Colors Feedback
« on: October 24, 2018, 01:48:36 pm »
It feels a little dull. None of your colour ramps seem to employ hue-shifting, that is, making the highlights and shadows different hues in addition to giving them different values. Adding hue-shifting can bring a lot of life into your work, I recommend adding some! For example, you could make all the highlights a little yellower/warmer (since the sun is lighting them) and all the shadows a little cooler/bluer, since they're getting the ambient light from the sky.
On a related note, pure greys tend to look rather boring. Clouds, especially on sunny days, are usually not grey, they usually have blue shadows (because the ambient light diffused by the sky fills in the shadows).

Some of the trees don't contrast well from the sky, because they're nearly the same value. Try using a lighter sky and some darker, less saturated greens for the trees. The narrow green trees also look neon and almost radioactive because they're so saturated and because they're lighter than the sky in places, I think slightly less saturation and darker values would really help.

The interior of the bedrock(?), which is presumably the least important thing to look at, is currently hogging all the attention because it has large, clear shapes with relatively high contrast compared to everything else. I think a solid colour with just occasional touches of detail would help keep the focus on the surface and in the dirt with the roots, which I'm guessing is where the player is meant to look. Also, if it is bedrock, it shouldn't be a loose pile of rocks, but rather something solid and possibly layered; the loose piles only happen where the bedrock is exposed to weathering, not where it's covered up.

The gradients on the trees (leaves and trunks) and clouds feel very "programmer art"-ey, and don't match the more interesting textures you're using elsewhere. I think those could really use some additional work. Even if they're procedurally generated, you could use more interesting base sprites/shapes as building blocks, they don't have to be solid/gradient shapes.

Here's a quick edit (mostly using some blending layers rather than manually-editing colours, I'm lazy and your palette is very large xP) that makes the dark colours bluer, the light colours yellower, and desaturates the neon greens:

I also replaced the grey rocks with some dark bedrock, as I think it creates a nicer visual hierarchy, letting the important stuff (the dirt and the stuff directly above it) be framed between two relatively flat expanses of colour (the sky and the bedrock). I doodled in some slanting strata freehand, but the same effect can be achieved with tiles like you're using, and can look much nicer and more rock-like than my doodles.

273
Pixel Art / Re: [WIP] Need guidance with cave/mine tileset
« on: October 23, 2018, 12:44:59 pm »
The ratio as I describe it is the width:height of a square on a horizontal surface. So, 1:1 means a square on the floor will actually look square. 2:1 means it'll be squished to half its height.

Height is a whole different beast and there are multiple ways to calculate it, depending on the look you want.

274
Pixel Art / Re: [WIP]First Tileset attempt
« on: October 22, 2018, 07:37:23 pm »
Please don't use the "width" parameter when posting images, just use plain [img]. The fixed width prevents zooming, which makes it harder to look at your image and give you more detailed feedback. The "img width" feature is meant for clickable banners and such, not for sharing art for critique.

MysteryMeat is right, avoid having highlights everywhere. Use them to draw the viewer's attention to important things, such as the parts of the environment that the player can interact with directly (e.g. the tops of platforms).

The edges of your tiles are perfectly smooth, which makes all your hard work on the textures in the interiors of the tiles feel a bit wasted. The edges should be as textured as the interior, since they're the same material.

The edge tiles are distinct from the interior tiles, which means they're an opportunity to create variation and a more natural look. By copy+pasting substantial portions of different tiles, you're squandering that opportunity and making things look more copy+pasted than they need to. That's fine for tilesets that have cartoony textures or that are meant to depict repeating textures, but you seem to be going for something more natural-looking, something that should have its repetition minimised.

275
General Discussion / Re: A Few Starting Out Questions
« on: October 22, 2018, 07:18:00 pm »
As much as I like Aseprite, I actually prefer PS to Aseprite for environment work, because I prefer the way it does grids and because it's easier to move stuff around xP Aseprite's strengths lie in sprite work and animation, imho.

Having a tile grid and blocking in larger shapes and then refining from there with the tile grid in mind is basically how I make my tilesets, so yeah, I'd say it's a decent way of working.

Chopping up the image: you shouldn't need to, since tiles are usually used from a tilesheet rather than as separate files. If you create your tileset with the grid, then all your tiles will already be placed according to the grid, so the most you should need to do is rearrange them to avoid repetition and empty space. Both PS and Aseprite make it easy to snap selections to the grid, so you can easily move tiles around.
For example, here's a screenshot of one of my work-files and the relevant part of the tileset once it's been arranged. (Also, here's another screenie from the blocking-in phase, just to make sure we're on the same page regarding that.)

If for some reason you do need every tile as a separate file, both PS and Aseprite have slice support, and both allow snapping to the grid while creating slices.

Mixing tile sizes: That depends on your engine and your tools. There's nothing inherently wrong with having different tile sizes per layer, but you may run into problems using them. For example, Tiled Editor has a fixed tile size for the entire map, so you can't mix tiles of different sizes. If your tile sizes are multiples of each other (e.g. 64 is exactly twice 32), then you can use the larger tiles as meta-tiles composed of several real tiles, though this does also mean you won't get to make full use of the editor's auto-tiling tools.
If you know your engine and your level editor support tiles of variable sizes, then by all means, make them! Otherwise, stick to a consistent tile size to be safe.

276
Pixel Art / Re: [WIP] Need guidance with cave/mine tileset
« on: October 22, 2018, 01:26:49 pm »
The diagonal boards have banding, that probably makes the jaggedness more apparent. Reduce the banding and they'll probably look better. 2:1 and 1:2 slope steps usually look fine without banding, but if you feel the contrast it too high even without banding, perhaps adding AA could help. Also, remember you can add some dips and "overlapping" dirt on them, hiding the jagginess.
To get rid of the banding with minimal work, you could make the sleepers (including the horizontal and vertical ones) mostly be that shadow colour, with smaller/fewer highlights. That would also help the sleepers look like they're in the ground rather than lying on top of it.

Your terrain isn't really 1:1, the rock shapes on the ground being wider than they are tall suggest a lower camera, something closer to 2:1. The fact that we can see so much of the vertical walls without them being squished vertically also suggests a lower camera. The character movement might be 1:1 (but that could be changed if you wanted to), but it's not likely to be noticeable as a problem.
You're right that most players won't think about it. Sword of Mana mixes 2:1 and 1:1 and even lower, almost side-view cameras and no one bats an eye xP

277
Pixel Art / Re: [WIP] Need guidance with cave/mine tileset
« on: October 18, 2018, 07:04:47 pm »
That's not much of a difference. In isometric perspective (which some non-iso RPGs use as well), it's a 1:2 ratio of height:width. In a typical RPG view with a slightly higher camera, it's usually 2:3 or 3:4. 1:2 makes for the easiest tiling, but may be too extreme depending on the style of other assets.

278
Pixel Art / Re: [WIP] Need guidance with cave/mine tileset
« on: October 17, 2018, 02:13:17 pm »
I think a big part of the problem is the outlines. Outlines look like shadows. If something's meant to be flush with the ground, it wouldn't be casting a visible shadow underneath itself. Removing the outlines around the sleepers helps a lot, it makes them look buried in the ground and almost flush with it. The rails can keep their outlines, since they're lying on top of the sleepers and are elevated slightly above the ground.

Here's a pair of edits.
The top edit removes the outlines from the sleepers, and makes the sleepers a little darker (fewer highlights), which makes them look a little dirtier and lower in the ground.
The bottom edit adds some piles of dirt around the rails (achieved simply by erasing parts of the rails, so the tiles can work on any terrain). Note the lack of outlines around these piles - the dirt is flush with the wood, so there's no separating shadow.


If you want to get very specific with the tiles, you could adjust the colour of the wood to be a little closer to the colour of the ground, to make it look like the dust has permeated or covered the wood.

279
Pixel Art / Re: [WIP] Need guidance with cave/mine tileset
« on: October 16, 2018, 03:01:03 pm »
The perspectives don't really feel like they match. The rails are seen from directly above, while the ground and walls appear to be seen from a 45 degree angle or lower, perhaps as low as 30 degrees. The horizontal rails would appear narrower than the vertical ones at these angles, and we would see the vertical sides of rails in additional to the tops. Even if you keep the widths uniform, we should still see the sides.

The sleepers (boards underneath the rails) are meant to distribute their weight so that they don't get pushed into the ground. This is relevant for a few reasons:
  • there should be sleepers all along the length of the track, including in the corners. At the very least, there should be some supports underneath those long stretches of rail. Ideally though, corners should not be so tight (what minecart could turn those?), and there may be ways to make gentler turns without too many tiles.
  • unless the track is freshly laid, the sleepers should be partly or almost entirely buried in the dirt. If any mining has gone on, they'd at least be covered in dust the colour of the local dirt, and not stand out so much. This fact could help you hide the difficult corner sleepers ;D
  • unless the sleepers were laid already broken, they're not likely to break in half in the middle of the track, as there's nothing there that would apply that kind of pressure. Consider converting that "snap" into a spot where the sleeper is buried instead - same efficacy for making the tracks look more interesting, but more natural, and fits with what I said above. A sleeper laid already broken also suggests that whoever built the track didn't care about it - sleepers do more than just distribute weight, they also keep the rails spaced evenly, and a broken sleeper can't do that.


Lastly, consider your worldbuilding. What you've made is a very "default" railway. It works and looks nice, but what does it say about the setting of this game? If your goal is to make something that almost any game can use, then this is great, since most players won't pay attention to something that's default. But, if your goal is to create a location for a specific game with a specific world, you should consider that world's history when designing this stuff. Some thoughts in case you're interested in the latter:
Metal rails are reliable and long-lasting but expensive, and require the technology to cast long, smooth rods of metal. Before that became available/affordable, many mines used wooden rails, with different kinds of wheels on them. Some of them weren't even rails, but flat wooden tracks that kept the cart on-track in some other way.

Even with metal rails, there are many possibilities, and the smooth shape common now wasn't always the norm. For example, some older metal rails were L-shaped and the carts had regular wheels, so it was the track that clamped onto the wheels rather than the other way around. You can read about older kinds of railways on Wikipedia.

In addition, some cultures had mining but not wheels (for example, the Incas), they likely had entirely different ways to transport materials out of the mine, such as using pack animals making frequent trips with smaller loads than a minecart.

280
The mouse rounding might be a screen scaling issue. Aseprite has separate screen scaling and UI scaling, make sure screen scaling is at 100% (and set to UI scaling to 200% or whatever you like). The default settings have it backwards for some reason.

I've seen a few people who dislike Aseprite's pixel art UI, so you're definitely not alone in that. I'm no fan either, but it's not a bother to me since it's just a visual skin on an otherwise convenient UI (at least with 100% screen scaling xP).

UI and workflow count for a lot, so I don't think it's petty or stubborn to want to make your own thing if using/extending existing software isn't a good option.

Pages: 1 ... 26 27 [28] 29 30 ... 127