Puppeteer
Emperor
Creating this thread to post a link, will return shortly to start the conversation. In my mind there are two approaches to the discussion: the modder approach and the dev approach.
Animated Terrain Discussion
- Thread starter Puppeteer
- Start date
Is this going to be a separate file? Probably will be easier to work with, that way.
Of course it can also be that "terrain animations" can be part of a larger file, say for "resources", which modders can set to appear at xy tile. I don't know the code, so can't say which of the two ideas is more practical/easy to implement; personally I'd rather have a separate animated gfx file.
Also, imo some animation for cities can be provided as well, even if only animated flags/banners.
Of course it can also be that "terrain animations" can be part of a larger file, say for "resources", which modders can set to appear at xy tile. I don't know the code, so can't say which of the two ideas is more practical/easy to implement; personally I'd rather have a separate animated gfx file.
Also, imo some animation for cities can be provided as well, even if only animated flags/banners.
Puppeteer
Emperor
Some terrain animation would be good to have. Even a few frames can liven things up
As a dev, one of the questions I've had is which format to use for animation (or any media, but let's focus on animation). There are at least two points of possible contention: the modding tools (e.g. Photoshop, GIMP, others, and what they can export to) and C7 capabilities, in the primary case what Godot natively supports. Then we get into questions like are animation frames layers, or are they tiled frames on one layer? Which has implications at the modder end and the dev end.
The easiest point of entry would seem to be using PNG or WebP as Godot supports both natively as a still image format. Each format supports layers by definition, but I don't know if the modder tools support exporting layered images of each type or if Godot natively supports reading layered images of those types. Not that either is a complete blocker, but we kind of have to define a path before we start addressing blockers to that path.
I have some early challenges in mind no matter which direction we go, but I wont toss them all out there right now.
If any of the devs think I'm crazy for considering animated terrain just now: actually I don't think it will be particularly challenging to get done. (To get right is another matter, but I'm always "working first, pretty later".) We're using Sprites. AnimatedSprites are a child of Sprite, so the display code doesn't change, just the preparation of the Sprite.
In the immediate term you have files like Art/Terrain/xpgc.pcx , and I'm thinking we just make an Art/Terrain/xpgc.png or Art/Terrain/xpgc.webp and drop it alongside the pcx in the Civ3 mod, and C7 will just look for the "new" extension before grabbing the pcx. (In the long term things may get rearranged for a native C7 mod that Civ3 wouldn't be able to use at all, but it's way too early to plan for what that's going to look like.) Civ3 will never think to look at or touch that file, so it shouldn't bother Civ3 being there.
When I first read this I thought I identified a near-term blocker, but now I can't think of what that blocker would be. Terrain and cities are "easier" because they don't have civ colors. At least I don't think cities have civ colors; correct me if I'm wrong.
So, if you were to make animated terrain, what are you expecting to do? Are you expecting to work in layers, or are you expecting animation frames to be tiled over one layer? What is "normal"?
I don't mind working with layers. I am not sure if that is really useful in a CivIII-like game, though, for terrain gfx (?).
Only use for layers in this that I see is the civ colors you mentioned. I didn't think of civ-color specific cities/other gfx, and although it would be nice if the option is there, I personally don't mind if it is not.
Besides, it should go without saying that the coders should decide what is practical
By the way: for cities you can take care of "civ-specific" by simply allowing a large number of different "cultures". I doubt many people would opt for the same city set with just different civ colors, if they can use a more culture-specific set
Only use for layers in this that I see is the civ colors you mentioned. I didn't think of civ-color specific cities/other gfx, and although it would be nice if the option is there, I personally don't mind if it is not.
Besides, it should go without saying that the coders should decide what is practical
By the way: for cities you can take care of "civ-specific" by simply allowing a large number of different "cultures". I doubt many people would opt for the same city set with just different civ colors, if they can use a more culture-specific set
Puppeteer
Emperor
For animation frames. I want to know how you're expecting to make animation. I presume you will have a number of images/frames slightly different from each other. Are those frames separate files each? Separate layers in a single file? Laid out side by side in a strip? Something else?
Oh, I can do either way. Usually I save the animation as a strip file. But I suppose it would make sense to have the format be like the one for units?
If not (if the format can be anything), I don't mind.
For my experiments with unit animation I've been using a MeshInstance2D instead of AnimatedSprite because a mesh is a natural vessel for a shader. We could probably attach the shader to an AnimatedSprite instead since shaders in Godot operate through a kind of material, ShaderMaterial, that presumably can be used with any CanvasItem. But if all AnimatedSprite is going to do for us is pick a sprite from a sheet I don't think it's worth using. Also I'd be interested in comparing the performance of the two approaches. That animated warrior sprite took 400 ms to load even after Quintillus worked on optimizing it, which is still unacceptably slow since we should count on loading hundreds of unit types. I suspect the reason it was so slow is that there's a significant fixed cost to creating any texture and that approach was creating one texture per frame (does it have to?). Meanwhile I haven't noticed any increase in loading time when loading one texture per FLC to be drawn with the shader+MeshInstance2D.
I think this could be a cool way to have an early beyond-Civ3-feature, and also one that gives our artists something to add for C7 beyond what's already possible in Civ3. If it does indeed wind up being fairly easy, I see little downside.
Though Flintlock is correct that our animation loading is not super fast right now.
I found the metrics in post #2 of the Performance Improvements Thread.
So, yes, the ImageTexture was a significant part of the cost, and currently stands at almost 50% of the cost, with pixel-setting optimized.
I don't know whether it has to create one texture per frame. But it definitely doesn't have to load all the FLC textures right at the beginning. We could load them incrementally as needed, and drastically cut down on the load time. Which might be a good technique to keep in the back of our pockets in general. I did something of that sort with my editor, where it allows you to start editing the rules before it has finished loading the map. On a fast PC, you'll only notice that as the map tab being grayed out a fraction of a second longer than the other tabs. But if you fire it up on a PC whose clock speed is measured in tens or hundreds of megahertz, that can give you dozens of seconds of rule editing/browsing while it's loading the map in the background. Lazy loading could similarly enable C7 to load games much quicker than Civ3/4/5, even if it's actually still doing work in the background after the UI appears and is responsive.
(I also like working on that sort of problem. My editor still loads more slowly than I'd like on a 166 MHz Pentium MMX. But it loads more quickly on one than it used to!)
Though Flintlock is correct that our animation loading is not super fast right now.
I found the metrics in post #2 of the Performance Improvements Thread.
Pre Optimizations said:
Post Optimizations said:
So, yes, the ImageTexture was a significant part of the cost, and currently stands at almost 50% of the cost, with pixel-setting optimized.
I don't know whether it has to create one texture per frame. But it definitely doesn't have to load all the FLC textures right at the beginning. We could load them incrementally as needed, and drastically cut down on the load time. Which might be a good technique to keep in the back of our pockets in general. I did something of that sort with my editor, where it allows you to start editing the rules before it has finished loading the map. On a fast PC, you'll only notice that as the map tab being grayed out a fraction of a second longer than the other tabs. But if you fire it up on a PC whose clock speed is measured in tens or hundreds of megahertz, that can give you dozens of seconds of rule editing/browsing while it's loading the map in the background. Lazy loading could similarly enable C7 to load games much quicker than Civ3/4/5, even if it's actually still doing work in the background after the UI appears and is responsive.
(I also like working on that sort of problem. My editor still loads more slowly than I'd like on a 166 MHz Pentium MMX. But it loads more quickly on one than it used to!)
I was checking The Battle for Wesnoth for animated terrain features and noticed that the most obvious one in my current campaign is smoke coming out of volcanic terrain.
And then I remembered that volcanos start smoking in Conquests before they erupt. Does anybody know how that works?
Puppeteer
Emperor
I'm not very sure, but I think volcanoes were mostly hard-coded. In that I think no matter how much you play with save and mod files can you make e.g. a plains tile smoke. There does seem to be a resource (if memory serves) associated with a volcano.
I kind-of expect us to enable multi-layered image formats or some other way to make any given tile type animated, for like a waterfall. A volcano erupting or smoking would be event-triggered, so I expect we'll have a moddable trigger, but we're further from the latter consideration than the former I think.
I kind-of expect us to enable multi-layered image formats or some other way to make any given tile type animated, for like a waterfall. A volcano erupting or smoking would be event-triggered, so I expect we'll have a moddable trigger, but we're further from the latter consideration than the former I think.
There are a couple such "terrain" animations in civ3. Another one is the plague animation. I suspect they aren't tied to terrain files at all - only tied to coordinates as an overlay. Too bad they didn't include event files using the same mechanic.
But obviously in a community-made civ game we will need a dedicated terrain animation group
I am not sure which way to code it would be more economical. Certainly the basic way would be to have the actual terrain file be an animation, that can simply be set to 1 frame for non-animated features. But I can't say if this will make the game slower (difference of file or file size; single frame "animated" terrain to just a pcx/png etc).
But obviously in a community-made civ game we will need a dedicated terrain animation group
I am not sure which way to code it would be more economical. Certainly the basic way would be to have the actual terrain file be an animation, that can simply be set to 1 frame for non-animated features. But I can't say if this will make the game slower (difference of file or file size; single frame "animated" terrain to just a pcx/png etc).
Puppeteer, I don't know about the hard-coding of volcanoes because I'm not a coder. But I do know that it proves that the game engine does allow a fully-functional display of animated terrain graphics.
So I draw two lessons from this:
-first, that adding them fully to the new-and-improved™ civ wouldn't depart from the spirit of the game;
-second, that maybe, since people cracked the editor for Charm attacks and such then a similar cracking might be possible?
In any case, animated terrain could be done as simply as with a small .gif file.
So I draw two lessons from this:
-first, that adding them fully to the new-and-improved™ civ wouldn't depart from the spirit of the game;
-second, that maybe, since people cracked the editor for Charm attacks and such then a similar cracking might be possible?
In any case, animated terrain could be done as simply as with a small .gif file.
unartis
King
Hi evryone,
I'm not a coder, but I have some old ideas that I missed from civ III. The weather as an animation could be included in this project, e.g. clouds could form around mountains which would generate rain, tundra regions could sometimes turn marshy green, then it could be a frozen winter landscape again, but in the same way floodplains could turn green and then be flooded.
The wind could also be present, or the sea ice, the edge of which could break and move a few blocks away from the polar poles, then disappear. The wind could also be a storm, which would only damage the units of the sea squares to varying degrees.
I'm not a coder, but I have some old ideas that I missed from civ III. The weather as an animation could be included in this project, e.g. clouds could form around mountains which would generate rain, tundra regions could sometimes turn marshy green, then it could be a frozen winter landscape again, but in the same way floodplains could turn green and then be flooded.
The wind could also be present, or the sea ice, the edge of which could break and move a few blocks away from the polar poles, then disappear. The wind could also be a storm, which would only damage the units of the sea squares to varying degrees.
unartis
King
In Civilization III, part of the terrain animation is the terrain generated after global warming, which could also be used in this project if possible.
As the plausibility and details are worked out concerning Animated Terrain for C7, I think it is important to provide Modders the ability to create and add Terrain Animations themselves... This addition would enhance the creative aspect of Modding a Game.
That said, I think adding some basic Terrain Animations in C7 would enhance the Game for everyone, including those who do not Mod at all.
What would "Basic Terrain Animations" be? ... A Poll for Ideas and then a Poll for decisions could be made.
Terrain Animations are "Eye Candy" that enhance a little more realism and enjoyment in a Game. They appear special but keep in mind that if there are too many, each Terrain Animation loses more of its "specialness".
Animated Terrain Graphics that have a universal appeal and acceptance would be best in C7... not over done and coupled with the ability for Modders to create and add more as desired.
That said, I think adding some basic Terrain Animations in C7 would enhance the Game for everyone, including those who do not Mod at all.
What would "Basic Terrain Animations" be? ... A Poll for Ideas and then a Poll for decisions could be made.
Terrain Animations are "Eye Candy" that enhance a little more realism and enjoyment in a Game. They appear special but keep in mind that if there are too many, each Terrain Animation loses more of its "specialness".
Animated Terrain Graphics that have a universal appeal and acceptance would be best in C7... not over done and coupled with the ability for Modders to create and add more as desired.
Not just animation, I'd suggest (as exemplified by IIRC the waterfall spot in the EFZI scenario) but also the capacity to make terrain change graphics depending on seasons or depending on events or eras. Or even on geographic regions, e.g. what if we had a world map for a tidally locked planet?
