Planned Features, Limitations

[CJC]

when I first read it, my thought was that you may want to have "tile properties" be stackable and have 16 for that purpose. For instance, event triggers could be a "layer" (transparent but still a layer), warps could be a layer, etc.

I love this idea!

[Gleeok]

@franpa suggested this: http://armageddongames.net/showthrea...l=1#post892301 which I thought was pretty good. :)

So if I got this right so far -- we have an event, warp, object, collision, tile properties layer..? ...this seems like a lot though - how about making 'warp' an 'event'..

Are you doing any optimization with your layers similar to what 3D engines do, where only what is visible to the player actually gets sent to be rendered?
.

I don't think depth testing is useful for 2D, but yes and no, obviously things off the screen will not be rendered though there it's not feesible to check every tile for "what it will look like after it is rendered". This would result in much worse performance.

[CJC]

@franpa suggested this: http://armageddongames.net/showthrea...l=1#post892301 which I thought was pretty good. :)

So if I got this right so far -- we have an event, warp, object, collision, tile properties layer..? ...this seems like a lot though - how about making 'warp' an 'event'..

Well... the layer wouldn't necessarily be set aside for these purposes. If the tile properties where assigned to the TILE and not the layer (Ala Comboing, though probably with the ability to attach a script to a tile, for the case of event triggers), and if all layers stacked their properties to that position on the map, then we could use some layers for visual purposes, some for solidity, and some hidden for events (though using more than one of these might prove dangerous).

[Imzogelmo]

A tile with a warp event probably wouldn't have any other kind of event, so they wouldn't necessarily need to stack... but then again, that's delving into the design of an actual quest a bit too far-- there's bound to be some quest designer that would have a perfectly valid reason to do that.

The reason I mentioned them separately is because I'm used to FF6's warps--which come in two flavors: long and short. Short ones are a single tile, and long ones are one tile wide by N tiles long (N being a datum in the struct, with the high bit standing in for a horizontal/vertical flag. Thus, you place it at the upper-left of whichever run you need and give it a width and destination. Those are useful for having a side warp on a map, rather than having 60 little ones.

But, mentioning the event engine, how would events be built up? Would it be a series of scripts that could be called as functions one from another?
I am imagining some essential event commands, such as 'show message x' and 'invoke battle y' and 'move actor A left N spaces'...along with the some flow control to allow conditional execution (really essential for an event engine) and even a call stack for re-use of redundant code in multiple events... Just a few ideas off the top of my head.