Isometric Design Thought

ID:151616
 
Dec 25 2009, 10:10 pm
So I just finished reading Lummox JR's "Your First Isometric World" Article, and it got me thinking about mapping design.

I like the fact that isometric design takes into account the user's prospective, automatically allowing tiles "closer" to the viewer to appear in front of tiles farther away. It is more convenient than laying out your map then going in and changing the layer of each item that you may want to appear in front of a character when one moves into the same tile as the item in question.

However, I'm not 100% sold on the whole diagonal view of the world that using an isometric map forces onto the designer. Maybe I just need to play with it more, but I am curious if it is possible at all to force a classical direction to the tiles, or apply the "closer"-to-the-viewer tile display to a standard map.
Dec 25 2009, 11:02 pm
ATM no it isn't possible.

You could emulate this behavior by turning all of your icons by 45 degrees to counteract the isometric change, then override the movement to go north/east/south/west instead of northeast?/etc/etc/etc.

Not sure what repercussions this would have on rotating your view though, so you may be stuck from one perspective.


EDIT: Side note, it'd be handy to allow a frontal perspective. :)
Dec 26 2009, 12:26 am
In response to AJX
I would love to have a head-on view, just my preferance really. I know some great games that use this, (FFT comes to mind first), but there are so many things that I don't have a clue how to do in the iso approach. I wouldn't even know how to do a large icon, since the way to do it on the standard map doesn't work in iso. I wish the Guide was up to date, but it's still on v2.0.


edit: not to mention, is it even possible to rotate? it's not true 3d, i think it only looks like it is.
Dec 26 2009, 3:15 am
In response to Cuddlebear
client.dir allows view rotation in 4 directions.
Dec 26 2009, 5:37 pm
In response to Kaiochao
Is there anything to read on this outside of Lummox JR's demo? I'm running into some things that are probably very simple to fix, and I want to read more about this. The more I mess with it in DM, the more I want to build.
Apr 10 2010, 8:03 pm
In response to Cuddlebear
you could make a normal word and what you do is have it set so that when the turf is generated with new() it's layer becomes that of the Y location, inverted of course, aka the layer would me your maxy of the map +1 - the y of the turf.
aka, turf with Y=1 will have a layer of 100 if the map is 100x100. This makes "vertically large" turfs appear to be in front of the character.

But what about the mob? Well, the mob can update it's layer the same way with the movement proc. adjusting it's layer dynamically so that it always appears behind objects that are in front.

I assume this is how the isometric map is set up, but it has the addition of the angled map and the modified movement.

basically, this is the code you're looking at...

WORKAROUND CREDIT GOES TO ME IF IT WORKS, Please o.o (this is a rough draft)

turf
    New()
        ..()
        src.layer=world.maxy+1-src.y //layer is now set for turf


mob
    New()
        ..()
        src.layer=world.maxy+1-src.y //set for mobs upon creation so when a player loads a save it is layered correctly
    Move()
        ..()
        src.layer=world.maxy+1-src.y //adjust the layer as the player moves so they appear in front when moving in front and behind when moving behind, and so on.


Apr 10 2010, 10:06 pm (Edited on Apr 10 2010, 10:15 pm)
In response to Bravo1
That will break all mob movement, because you're overriding Move() without returning anything.

EDIT: If you want to know how isometric works behind-the-scenes, here's a library/demo I wrote a while ago to do isometric maps, before BYOND officially supported it: http://www.byond.com/developer/Jp/IsoEngine
Apr 11 2010, 4:39 am
In response to Jp
Well, that's great, but mob movement wouldn't be broken, since I'm allowing it's normal functions to be applied first with ..() then it applies the layer change. I use that process all the time and it works fine for me o.o
But yeah, thanks for posting the source, I've been wanting to pick the iso source for a loooong time.
Apr 11 2010, 4:53 am
In response to Bravo1
Wouldn't it be interesting if you could have your world be isometric "outside" and say when you entered a house, controls and graphic mode would switch to 2d. I am going to attempt fooling around with this. I wonder if you could actually implement 2 different maps, 1 that is isometric and one that isnt.
Apr 11 2010, 8:34 am
In response to Darkjohn66
Darkjohn66 wrote:
Wouldn't it be interesting if you could have your world be isometric "outside" and say when you entered a house, controls and graphic mode would switch to 2d. I am going to attempt fooling around with this. I wonder if you could actually implement 2 different maps, 1 that is isometric and one that isnt.

Using TOPDOWN_LAYER you can definitely do this.

Lummox JR
Apr 11 2010, 10:01 pm
In response to Bravo1
I wasn't thinking when I posted - your code /is/ wrong, but in a slightly different, subtler, less outright-destructive way.

atom/movable/Move() is supposed to return a value indicating whether the movement succeeded or not. Your code does not do this. This will have a number of very subtle effects.

The simple solution is to write .=..(), not just ..(). When you call ..(), you get the return value for the procedure, and '.' is a special variable all procedures have that is the value to be returned - so effectively you're returning what Move() would have returned.

EDIT: Also, the code I linked to isn't 'the iso code'. I have no idea how DreamSeeker handles isometricity in the backend - it's just one implementation of the idea, with, likely, a number of issues. It's just some old code I wrote a while ago as a proof of concept.