Animated tiles support

[i]

Do we plan to add animated tiles support to TMW?

Since we got particle engine [PE] (god! thank you for Crush :)) we are able to make some animated effects. But what about huge areas of water, animated grass, lava, etc. Many RPG's have animated tiles. In my opinion we also should. PE is good to make custom effects, like flames, waterfalls, explosions, and spell effects, but we cannot use PE on huge areas because of CPU consumption. Don't forget we aim to make TMW playable on almost every not-exacly-up-to-date machine. Starting from ~500MHz and 128MB of Random Access Memory.

Any ideas how he could place animated tiles on our maps?

/edit

Sample reference image

[Crush]

Animated tiles are something we should definitely do, but unfortunately Tiled doesn't support animated tiles. I got no idea how to integrate it into the map format and the mapping process.

[i]

Unfortunately I don't have any clear vision either.

I was thinking about improvement of our mapping system/editor. And that's all I figure out:

1. Vector based colision layer - instead of tile based
We could use vector shapes to describe walkable and unwalkable terrains.
but this topic isn't rather place for discussing this idea.

2. Tilesets should have own XML files with description of contained tiles.
- instead of using x3, x5 tilesets, we could determine groups of tiles
- we could add animated tiles - just marking them as animation sequence
- we could add client sided events releated to tiles - like PE effects triggering, or placing PE based flame on the top of torch tile.

I know that is HUGE amount of work. But since we haven't released 0.1.x we have a testing site for doing all the things which are necessary.

[zick]

I was thinking of something the other day where tilesets have a specific structure (which was something that they did on the FreeCraft project). Like tile 1 is your first frame of a grass tile followed by 3 frames of animation (next three tiles), if a tile doesn't animate those next 3 frames are the same image. And the client knows that if a tiles index is below a certain value, it is animated; so solid tiles like walls appear further down the tileset than animated ones. Also lets say you lay tile 1 down and next to it lay down tile 3; because the client knows that tiles 1 through 4 are part of a loop it knows that the first tile will start at 1, go to 2, to 3, to 4 and back to 1 and the second tile will start on 3, go to 4, to 1, to 2, and start over on 3 again. This will provide a variation in tiles without needing a lot of extra tiles.

This concept could be expanded also to allow tiles to have other attributes like a stepped on look (maybe a stepped on right and stepped on left since a sprite is 64 px wide and a tile is 32 px wide), a night variation, a dusk/dawn variation, as well as seasonal/weather variations. As long as there is specific structure that is adhered to, no special mapping has to be done, the client knows whether a tile is animated or not, whether it has a stepped on look, etc, etc.

[Jaxad0127]

Animated tiles could be put in separate files like the tall ones. Each row in the files could be a different animation, keeping the system simple. Or use an offset that could be specified as a property in Tiled.

This concept could be expanded also to allow tiles to have other attributes like a stepped on look (maybe a stepped on right and stepped on left since a sprite is 64 px wide and a tile is 32 px wide)

That stuff would probably be better to do with the particle engine.

, a night variation, a dusk/dawn variation, as well as seasonal/weather variations.

Time variations could use the image dying system. Weather is already being planned and will probably also use the particle engine.

[leeor_net]

I think I like jaxad's thoughts best. I was actually thinking of defining animated tiles using basic XML scripts and modifying the engine to use these. Unfortunatly, what I had in mind would force myself (and other users) to manually edit their map files outside of Tiled.

What I had in mind for the XML is this:

Code: Select all

<tileset name="Water - Animated" firstgid="1" animated="true" tilewidth="32" tileheight="32">
  <image source="../graphics/tiles/water.xml"/>
</tileset>

Code: Select all

<tileset>
  <animation>
    <sequence start="1" end="6" delay="75" />
  </animation>
</tileset>

Ultimately, the animation definitions would be very similar (if not exactly the same) as the animated sprites currently implemented. It would require modification to the map readers and perhaps the inclusion of an 'animated_tile' based on the ImageSet class -- but all of this is speculation right off the top of my head.

[Othello]

I see Tiled has not been developed for almost 2 years. I'm a java developer, I might be able to add animation to it.

[edit]Nevermind, I see its still being developed, I'll have to see how I can commit.[/edit]

[zick]

Let me play devil's advocate for a sec (I'm not being mean, I'm just showing a side that hasn't been thought of yet) ...

Everybody keeps talking about using dying for day/night cycles (or seasons, or weather, etc.). While that can be a viable solution, I'd like to see separate tiles for this sort of thing for one reason: variation not limited to just color. Let's take our standard grass tile and lets say during the daylight said tile will have flowers on it. What if at night those flowers don't bloom (a natural phenomenon that takes place in some flowers on our planet)? While you can dye the grass, you probably can't dye the flowers (you can but the flowers may still be visible albeit that they would be darker, they wouldn't actually disappear). What about if something glows in the dark, like mushrooms? Another solution to solve these would be to use context-sensitive objects placed on a tile that responds to the time of day, and while that is a viable solution it means more stuff on the map that client has to load/change which may cause lag.

My idea would allow you to use animation sets of a specified number of frames to change a daylight tile to a night time tile, by way of a dusk animation set (like the flowers closing up for the night and disappearing or the mushrooms start pulsating while the grass darkens) and a dawn animation set (when the flowers bloom and the mushrooms stop glowing).

Also, you say that you can cause a stepped on look via the particle system and while this may work for footsteps in snow or sand, i don't think it would work for making tall grass bend as you step on it.

Weather was also mentioned. It was said that it could be done with the particle engine. Raindrops/snowflakes could be done with the particle engine but what about the result of those drops/flakes, like puddles or snowdrifts?

Finally, by defining animated tiles via XML scripts will work, why go to all that trouble when (if the client is written to automatically do it), animation just happens. With my original idea if the client knows that a tile with a certain index in the tileset is animated, and it knows that the animation sets are always a certain number of frames (like 4 or 6 frames), it should just animate it (or play the loop, the first frame being the tile placed).

The same goes for NPC's, why go to the trouble of "scripting" an NPC, when if you create a variety of NPC primitives (like a talker, a bank, a shop, a healer, a quest giver) and just specify an NPC as one of those types, plus maybe a couple of attributes used by that type (like for a quest giver, what item will he give for completion of quest and how long do you have to complete the quest, etc.) you simplify the NPC creation process as well as eliminate the need for interpretive scripting ... but that another topic for another time. Forgive me for going off topic.

[Othello]

Zick, I think you have a point. I don't however like the idea of specific places in tile-sets ala RPGMaker. However, Tiled has the option of adding properties to your tiles. So you could do something for each tile which has special properties like:

== tile nr 2 (flow open) ==
valid-on: day
next-tile: 3

== tile nr 3 (flow closing) ==
valid-on: dusk
next-tile: 4

etc... Then when a tile is supposed to be rendered, but its not valid for that time it will go to the next-tile until it finds one which is correct. Though it will not render a closing-of-flower animation it can show closed flowers when its night and half-closed flowers when its dusk (or dawn).

Could even be used for animation:

== tile nr 10 ==
next-tile: 11
delay: 5

== tile nr 11 ==
next-tile: 10
delay: 5

Its a bit verbose, but it might work.

Other than that I have seen that there is actually animation support in the source-code of tiled 0.6.1, however, it doesn't seem to be used. I'll see if I can figure how what needs to be done to get that to work. It would suffice for our basic needs of just animating and such.

[Crush]

When you want to assist in the development of Tiled you should work with the latest version from SVN.

[Bjørn]

As already noted, animating tiles is not a limitation of Tiled (it's just that it can't show them). All you need is some properties on the tiles and support for TMW client to do tile animation. As Othello said, the following properties would suffice (I've changed it from tile to frame to make it more obvious that it's about animation):

next-frame: the next frame to display
delay: the time to wait before displaying the next frame

Since this is indeed verbose, I would propose some shortcuts:

* Not specifying the delay makes it take the delay of the previous tile in the animation.
* Have an additional property called frames: the amount of frames in the animation. For consecutive tiles in a tileset, this means you don't have to specify the next-frame all the time.
* Have a sane default for the delay property.

Of course, the most difficult part here is adding support for these attributes to the client. Any voluteers?

[Crush]

I believe I am up to this challenge.

[Crush]

After letting this feature slack for a few month I decided to finally come back to this. The concept Bjørn suggested turns out to be not that practicable because it creates a horrible spaghetti code in the tilesets xml code. Here is an example of a tileset definition with just a single three-frame animation:

Code: Select all

 <tileset name="woodland_ground" firstgid="3" tilewidth="32" tileheight="32">
  <image source="../graphics/tiles/Woodland_ground.png"/>
  <tile id="0">
   <properties>
    <property name="delay" value="100"/>
    <property name="next-frame" value="16"/>
   </properties>
  </tile>
  <tile id="16">
   <properties>
    <property name="delay" value="100"/>
    <property name="next-frame" value="48"/>
   </properties>
  </tile>
  <tile id="48">
   <properties>
    <property name="delay" value="100"/>
    <property name="next-frame" value="0"/>
   </properties>
  </tile>
 </tileset>

Just imagine how it would look with more animations with more frames.

First it is very hard to trace animation loops after they are created (the tileset property editor of tiled doesn't make it a lot easier).

Second it does not allow to use the same frame in multiple animations.

As a counter-proposal I would suggest to put the whole animation loop of a tile in the properties of the first tile of the loop. This allows to use the other tiles of the animation loop unanimated or as parts of other animations. Example with the same animation:

Code: Select all

 <tileset name="woodland_ground" firstgid="3" tilewidth="32" tileheight="32">
  <image source="../graphics/tiles/Woodland_ground.png"/>
  <tile id="0">
   <properties>
    <property name="animation-frame0" value="0"/>
    <property name="animation-delay0" value="100"/>
    <property name="animation-frame1" value="16"/>
    <property name="animation-delay1" value="100"/>
    <property name="animation-frame2" value="48"/>
    <property name="animation-delay2" value="100"/>
   </properties>
  </tile>
 </tileset>

Much shorter, much easier to read (especially in Tileds tile property editor) and much less error-prone. The only aspect where this notation for animations is less powerful that the other is that it does not allow non-infinite loops. But these don't make much sense for map files in my opinion.

You will maybe note that the definition of the first frame (frame0) seems to be redundant. This is intentional. The tile should be represented with the normal id in tiled and with frame0 - frame2 by the engine. The idea is that you have a tileset for an animated tile consisting of the frames of the animation and one frame which is a duplicate of another frame with a big, red "A" for animated on it. You assign the animation loop to the "A" tile and use this for mapping in tiled. That way it is hard to confuse the animated tile with its subframes while editing a map.

[Jaxad0127]

The only problem with that is that it makes it difficult to start tiles on different frames of the animation. You'd need to specify the whole animation each time.

[Crush]

I implemented it with the syntax I suggested. Animations with different offsets can be created by adding different animation loops to individual tiles.