Re:creation - a top down action adventure about undeads [hiatus]

[Nexus]

Not only the ladder's perspective, but especially the cliffs with a "sideward slope" have a strange perspective. Looking at the trees and game characters, the player is looking a bit from the front, I think you should maintain this consistently.

[Elias Daler]

Yeah, I agree. To make the perspective better, I need to draw more tiles, though. This is pretty hard but I'll try
Check out cliff perspective in Mother 3 or in ALttP
Both look kinda weird, but I think I want my cliffs to look more like in Mother 3.

I've made a quick fix to see how cliffs would look, it's a bit better than what I have now:

[SpeCter]

I would make the ladders straight I think. Making it wider at the end looks weird, especially when your character doesn't get bigger climbing it.

[Nexus]

Elias, the cliff already looks much better on the left edge (not on the right though ).

Yes, I'd make ladders straight too. Your graphics follow a parallel projection, so it looks weird when single objects have perspective.

[Tank]

+1 Nexus

[Hapax]

The cliffs look a whole lot better when seen consistently from one angle (the newer version), in my personal opinion.

The ladder is a weird one, though. It looks slightly odd having perspective but maybe it's necessary to suggest its angle. A flat width ladder would look more like a bridge.

You should also note that this "consistent angle from the front" is not a requirement of this particular style. See the inside scenes where you can see the inside of the "closest" wall.

[Elias Daler]

Thanks for the feedback, everyone. I'll try different perspective styles to see what looks the best.

Worked on the tileset today. I think it's a big improvement.

Still unsure about the perspective.
Here's another way to do it:

(Notice the bottom part. I don't like that one because it's not that obvious that there are different heights there)

[shadowmouse]

I think you should always have a small border around cliffs to show that they are cliffs rather than just a different style of grass. I found an image of some cliffs from a Link to the Past to give an example. Note the cliffs south west from Link, you can still see the face in what is the same perspective as in Re:creation.

I do realise that depending on how you look at it, it could look like the rocky ground is below the grass in terms of altitude, but the shadows work well to show that they are cliffs.

[Elias Daler]

@shadowmouse Thanks for your observation. I think not having grass on such cliffs helps to make contrast even more high.

As for the ladder... I've been thinking about perspectives in top-down games. Most games don't use Zelda's perspective (look at the side and bottom walls!)


They use other projection which makes other walls not visible.
Seiken Dentesu 3:

Chrono Trigger:


I like this perspective more and it seems that drawing in that perspective is easier. But I feel that this may limit indoor level design. I want some rooms to be connected with each other, but there isn't a good way to show some doors: all doors must be on the wall which player sees. Zelda's perspective lets you put doors on every wall you like.

Any thoughts on this?

[Tank]

Form follows function; ergo the Zelda one would fit better, clearly.

[Hapax]

A similar discussion about this kind of perspective (it started with this post) came up on the forum for Witch Blast, which - as you can see from that thread - ended with sticking to the original perspective, after trying out the other type and considering doors on the near wall etc., although Cirrus Minor did seem to personally prefer the original perspective so it could just be down to your own personal preference.

[Elias Daler]

@Tank, indeed!

@Hapax, I'll stay with Zelda-ish perspective for now until I see something that fits the game more. I think I'll mix perspective styles as long as it looks good.

[Elias Daler]

Didn't have much time to work on the game in the last few days, but I still managed to do something cool.
Levels now support multiple tilesets. I can easily switch between them in the level editor.

Previously, I only had one tileset per level, because I've thought that having city tileset / forest tileset / dungeon tileset etc. for each level would be okay. But then I've realized that it would be cool to mix tilesets instead of copy/pasting some tiles between tilesets
Another issue I'm thinking about is how to assign unique ids to tiles. I've previously used integer ids which were assigned like this:

This is pretty straightforward approach and it lets me easily get texture coordinates of the tile by its id.
But it leads to some problems:
1) Changing the width of a tileset breaks ids, because they correspond to other tiles.
2) If I change the ordering of tiles, I need to replace their ids with new ones in the level.
So, I need a better approach. I think that generating some tileset file like this:

x=0,y=0,id=G
x=16,y=0,id=G2
...

Then I can freely change width of tileset and swap tiles by changing their ids in a tileset file.

What do you think of that? Maybe there are some cooler methods to store tilesets and levels?

[shadowmouse]

It might well be similar to what you are doing, but you could make an unordered_map which has a key type of either string or int (depending on how you store your level data) and a value type of a user defined struct which stores a reference to an sf::Image (which contains the relevant tile set) and an sf::IntRect for position. This way the code wouldn't be in an easily modifiable file, and you could even store it in a dll so that you can update it easily if you plan on releasing patches rather than entirely new builds of the game.

[Hapax]

What do you think of that? Maybe there are some cooler methods to store tilesets and levels?

I think integer IDs is reasonable for most cases. Changing the width of a tileset is, in effect, inserting new tiles into the set so IDs being reassigned is an expected repercussion. Prepare the width of the tileset in advance, once 

That said, an enum could ease this rearrangement (albeit in a rather verbose way):

(click to show/hide)

Tileset 3x3:
0, 1, 2,
3, 4, 5,
6, 7, 8
enum:
Tile0 = 0;
Tile1; (1)
Tile2; (2)
Tile3; (3)
Tile4; (4)
Tile5; (5)
Tile6; (6)
Tile7; (7)
Tile8; (

Tileset becomes 4x3:
0, 1, 2, 3,
4, 5, 6, 7,
8, 9, 10, 11
enum:
Tile0 = 0; (0)
Tile1; (1)
Tile2; (2)
Tile9; (3)
Tile3; (is now 4)
Tile4; (is now 5)
Tile5; (is now 6)
Tile10; (7)
Tile6; (is now
Tile7; (is now 9)
Tile8; (is now 10)
Tile11; (11)

The fact that I used numbers in the Tile name probably makes it look more confusing. Imagine actually naming them:
enum:
Empty = 0;
Wall;
Grass;
Door;
and so on.
Just going making sure that this list is in the correct order makes it a lot simpler as you would have to do it once