Whew! I've been getting into the rhythm of this project and making quick progress. I added more monster sprites, decorations and some floor types you cannot see here. I also tweaked some tiles and reduced the character size from 64x64 to 32x64. I had to redraw my dragon, but now objects/characters are the same size and the sprite sheet is twice as efficient.



@Quirby64 Is this better? I brought the dragon's legs farther apart and centaur's legs closer together.

@DarkGrievous7145 Thanks! I'll add more tile variations to my to-do list. I tried fixing the doors, but they look too small when they're in the same perspective as the walls. This will have to do for now. Also, the grid layer has been disabled for your viewing pleasure. 

Definitely an improvement

I was a little concerned that might not work with those doors.

oh well

Ok, I await to see what else has been added, or will be!

More progress on my tileset! Taking a break from the monsters, I added a few more dungeon features and about 150 items you can't see here. The old mockup started feeling cramped, so I expanded it a bit. I'm really happy with the results so far and I have almost enough graphics for a Rogue-sized game.



I also made some minor tweaks to my dungeon palette and improved the posing of some monsters. I couldn't find a solution for the door tiles so these are pretty much final.

I think the walls are rather bland. It's understandable if you want to cut down on orientation programming for the tiles, but you could give these a little more detail.

Good point. How's this?

I can't see the difference other than the tiles added to the bottom for depth. (which strangely are lacking in the new mock-up)

Perhaps a side-by-side compare with clearer explanation what exactly has changed?

Other than that, the new stuff is looking pretty good.

Sides of the walls were added on the outside instead of the walls abruptly cutting off.

the previous mock-up did that, tho... which is why that didn't seem like the big difference...

it didn't make sense to me that for optimization's sake, he'd remove those extensions.
feels to me the lack of them was an error, and not intentional.

but they are the only noticeable change...so maybe that was it.

I agree with Gors. Your tiles could do with more variation at this size and with the style you're going.
I've done a quick airbrush edit: the moss is an extra touch I'm not so sure about. I've circled tiles that have an obvious seam, which you may want to address.

Cool stuff anyway, keep it up

You're programming this right, DDP? In you're having trouble with figuring out how to render the sprites correctly, along with collision handling, I recommend taking the 3D route. Here are my resources:

http://www.gamedev.net/topic/629496-dyna...lgorythms/
http://www.gamedev.net/topic/470599-isom...h-sorting/

The idea is to use 3D rendering to take advantage of the depth buffer so that objects will clip correctly. Also, you get to use 3D collision detection and normal 3D positions. If you use Unity, then, you pretty get isometric pixel rendering while making use of Unity's 3D editor, collision system, and lighting system.

It does require that you make approximate 3D representations of each tile, however, it's not difficult. Objects that should have considerable depth should be modeled approximately. However, characters and enemies can be represented by a billboard or quad (these are rectangles in 3D space).

Nah, this is just a creative commons tileset I'm making for roguelike developers. Once I have enough graphics together I'll be releasing them on OpenGameArt. And don't worry about the perspective...It's actually a lot simpler than it looks.



The grid size is 32x32 and the tiles are 32x64. Floors/pits are drawn on the lower layer and everything else goes on the upper layer. There's also an optional shadow/grid layer. My mockup was made in Tiled.

Oh creative commons?- awesome!

I know that just plain rendering the sprites is simple. But, once you try to code the game and systems like collision detection or physics, it's not that simple unless you go 3D. The traditional coding method leads to overlapping, collision, and other visual issues that's actually common in pixel topdown/iso games.

Well, these graphics are intended for roguelikes so things like collision detection and physics are nonexistent. Think of something like Crypt of the Necrodancer where movement is locked to a grid and every tile only needs a single bit to determine whether it's solid or not.

Thanks for the advice, though. If I ever make a more robust top-down game like Link to the Past I'll definitely keep that in mind.

Ohhh I understand now. Yeah, that does make things a lot simpler.

Pretty sure using the 3d rendering (especially since the GPU tends to be involved) also comes with a risk.
It sounds all well and good, but there's still a lot of people with older computers.

When an older computer comes into play, a common result is that the game is completely un-playable.
This also isn't helpful to the developer, since this upsets would-be players.

Usually it's best to default to 3D or GPU-accelerated rendering, and fallback to software rendering.
At least until everyone actually has the capability to upgrade to computers that supports that, which contrary to popular belief, is not always that simple.

I don't have any particular problems with the newer / experimental / next-gen technologies, but it is important to balance things out and work around the obstacles they present wisely. Personally, if using 3d-rendering made the difference between a player actually even PLAYING my game, or not, I'd say the z-sorting issue is a bit negligible. (Not to say it doesn't kinda annoy me, cuz I've seen games do this...)

@ddp:
hmm, so tiles twice as high as wide? interesting... normally everyone uses square tiles (not that i have ANYTHING against normal rectangles) What drove this decision? And yes, I hear tiled is pretty powerful/useful. I personally probably won't use it in my games for now tho since I'm not used to parsing XML files. (I also need to learn how to use it sometime.) It does explain how you manage to make new mock-ups so quickly, though.

And another note, although I didn't thank his post before for some reason, chris definitely has the right idea with maybe trying some mossy variants or something.