[Art] Art Discussion Thread

[Quintillus]

Spinning off from another discussion, a thread for discussion artwork in general. Format, goals, assembling a minimal viable collection, etc. I expect once we have some artists on board, we'll have more specific threads.

I was a bit surprised and disappointed that SVG isn't supported by Godot, but after thinking about it, it makes sense. A 2d vector format doesn't really work well with a 2D raster engine. Maybe if the SVG were externally converted to a flat 3D mesh it could be used in that format, but that doesn't seem like I road I want to tread down anytime soon.

Bummer. I like SVG's git-ability and scalability. And I was going to actually use my svg-based stuff from my older c3sat maps as a stand-in for C7 art, but if I do I'll have to convert them to raster formats first. Oddly, ImageSharp doesn't handle them, either. I guess vector and raster graphics don't mix well.

I might be missing something here, but the S in SVG stands for scalability, a trait which you mentioned. I am also a little surprised it isn't supported natively, but since it's scalable, in theory shouldn't there be a library out there that scales SVGs to various size bitmaps, which can then be turned in to whatever format you want?

 

[Puppeteer]

I'm sure it's possible to go from SVG to raster, else we couldn't display them without a vector monitor. I was just surprised that neither handy graphic tool I could think of would do it. And unlike PCX & FLC I fully expect an acceptable C# library is available.

I guess we should include an SVG to Image function like we have with PCX and FLC frames. Just by finding a library, though.

Media Format

My epiphany today is that the native C7 format is...Godot Node2D scenes.

It's so obvious. Every pixel we put on screen is part of a CanvasItem. (Parent of Control and Node2D.) I think each of us has added something by code so far: you instantiate an object that is a descendant of CanvasItem, pull its levers, attach other things to it, then add it to the current node.

All a scene is, is just a visual and text-file-based way to describe the same process. Notice every Godot-created script starts with a class inheriting the type of your scene root node. That's because the root scene IS the class object you're scripting.

That said, I'm not saying we go "ok, modders, go learn Godot!" If I can stop switching shiny things I want to chase every few minutes I might have enough time to start coding, and I'd like to start working on what I have in mind. Which is a scene structure something like this:

• Map viewer (to be attached to C7Game scene which still keeps UI elements) (possibly pluggable, will have to think on that)
  • Tile scene (pluggable, or maybe its children are pluggable)
    • Terrain layers scenes (including improvements, fixed structures, pollution...)
  • Unit scene (pluggable, possibly includes anything that can move between tiles)

But we'd have some default non-CIv3-property scenes, some scenes that read straight from Civ3 graphics, and some that will read a folder with some media files and a config JSON file so modders can zip up a folder of files and distribute just that.


Plus it means we can mock up a unit with a solid-color sprite for now and fully hook up the animated FLCs later.

 

[Quintillus]

Hmm, I may or may not have lost you at the scene structure. Is that bullet-point list hierarchical? And if so, isn't it sort of the direction we're already going? I think @Flintlock mentioned starting to add some terrain layer scenes, or maybe it was you. We hadn't really talked about the units in detail yet, but those do make sense as a layer on the map.

The pluggable aspect - do you mean pluggable based on the type of asset? I'd been thinking that we'd do the conversion at the point of reading the scenario graphics. E.g. maybe one mod has terrain graphics in PCX format, another does in a more modern format. We'd figure that out somewhere in the asset loading stage, and they'd all get converted like PCX does today, and passed in to the rendering area.

Or do you mean pluggable based on the fact that we may want to support e.g. the original graphics but also higher-res graphics, which may require some logic changes (e.g. tiles won't be 64 pixels wide but two or three times that)?

My thoughts at this point are a merger of two aspects:
- We definitely should support more modern formats, although early on PCX is adequate. We have community PCX graphics for most likely everything, and can likely convert to PCX in the early days if need be. *expects shudders at the thought of more PCX*
- We should not paint ourselves into a corner where adding support for more modern options is hard, but we also shouldn't make it theoretically possible to support All The Awesome Things when we still lack support for an awful lot required for feature parity (game mechanics most obviously, but while we have some proof of concepts for animation that look cool, there's still a good amount of map parity to go as well).

The hierarchy looks sensible to me if I'm understanding it correctly, but I'll admit I'm thinking a little bit, "let's not get too far ahead of ourselves" on flexibility.

 

[Puppeteer]

I think we're on the same page. And I tend to think out loud a lot.

The pluggable aspect - do you mean pluggable based on the type of asset? I'd been thinking that we'd do the conversion at the point of reading the scenario graphics. E.g. maybe one mod has terrain graphics in PCX format, another does in a more modern format. We'd figure that out somewhere in the asset loading stage, and they'd all get converted like PCX does today, and passed in to the rendering area.

I'm thinking our BIC analog will have optional overrides something like this:

{
  "otherConfigStuff": { "foo": true; },
  "customTileFormat": "referenceToAlternateTileScene",
  "customUnitFormat": "yada yada yada"
}

Something like that, but you'd be able to have e.g. 32-bit WebP tile graphics alongside PCX tiles (which probably would look weird), and also able to mix unit formats which makes a little more sense.

I'm thinking the map viewer loads tiles as interfaces, so it can say "draw at these coordinates" and the pluggable scene does its thing.

As far as "asset loading stage", the current code dynamically reads the PCX when it tries to display it. It says "is this tile reference in memory?" And if not, then it goes and slurps up the right file and puts the tile texture in memory. The way Godot does resources and nodes, I think that should be possible for any media format. Of course I could be wrong.

I really should stop explaining and start coding, but I rarely optimize my own self.

Or do you mean pluggable based on the fact that we may want to support e.g. the original graphics but also higher-res graphics, which may require some logic changes (e.g. tiles won't be 64 pixels wide but two or three times that)?

That's the thing, though: Size doesn't matter! We can scale any Node2D. The current zoom code doesn't scale all the tile Sprites; it scales the Node2D they're all children of. I'm already having an internal debate if we should stick with 128x64 or make the terrain size one unit and call it 1x2.

One unit texture may be 128x64, and another might be 800x600. The pluggable unit scene just needs to be sure it's scaled at that level to whatever standard size we decide. Then if someone with an 8k monitor zooms as far in as they can, the full resolution of of that 800x600 unit will be there. Otherwise it will be mipmapped by Godot.


As a side note, I may add media files to the .gitignore at some point soonish. I don't want them in git, but we're going to want some 'native' graphic resources soon. I need to play around with where we can put them and how we can add them. I don't have solid ideas for that yet.

 

[Quintillus]

Hmm... I think I see what you're saying about resolutions. The aspect ratio might matter if we don't want things to look squished, but 256x128 tile graphics might just look higher-res? Half of me wants to say, don't all of our assets have to agree on a resolution? E.g. if the forest graphics think a tile is 128x64, the base terrain thinks it's 256x128, wouldn't that throw it off? We're scaling the parent of them all, so they have to agree? But the other half is thinking, hmm... if we had a PCX that had twice the res for forests, and our code still chopped it up based on percentages of width, and we tossed it in the same place, could we get twice the resolution when we zoomed in on forests without needing all the other things to also have twice the source resolution?

It's that "can they be up-resed piecemeal?" that's confounding me; it makes sense that if there was only one graphic, it'd be straightforward. If it isn't straightforward, it still might be worth writing some code to allow piecemeal resolution upgrades at some point, since that would allow incremental new art.

Hmm, I was thinking more that the unit itself would say "I'm in this format", and as long as it was one we supported, it would work. For graphics, I was slightly more fuzzy but was thinking that we could look for e.g. EUROWALL.webp, then EUROWALL.png, then EUROWALL.pcx, if our preferred format order were webp, then png, then pcx. Though you may well be right that at some point we might need some metadata associated with a scenario. It just seems elegant to auto-detect as much as we reasonably can to make it convention over configuration for the modder.

If I think more outside the box, I can see more cases where configuration may be necessary, e.g. if we add support for Civ5-style animated resources in addition to Civ3-like static images. But one of the relevant points from JimmyH's threads that I read tonight was this post, where ZergMaster agrees with some bloke named WildWeazel that a clone should be the initial goal of any community Civ project; JimmyH posted in that thread that too much ambition and too broad of an idea from too many people was part of the reason momentum stalled out, along with the fact that no one was playing IndieCiv because it was at too early of a stage, so he was getting no feedback and no users, which didn't help with motivation. Which meshes with why I think I'm often the one saying, "that could be cool, but not now" to a lot of ideas.

I should probably also write more code and less on the forum, but as long as I'm adding new features, I'm not going to be too particular on that.

 

[Flintlock]

I'm thinking our BIC analog will have optional overrides something like this:

So the scenes will be like config files? What's the advantage of using Godot scenes over something like JSON or XML? Besides that being forced to use XML is a form of torture.

I'm already working on adding a basic unit layer to the map viewer. There's a roadblock though in that previously I'd been applying the transforms that made scrolling and zooming possible to the MapView node itself instead of to the terrain layer. I was thinking that would be convenient because then the same transforms could apply to multiple layers at once, except they won't work for layers of loose sprites so I'll have to change how that's done. Technically they could be made to work by applying a transform to the loose layers that partially undoes the parent transform, but that would be a mess. My plan for the map layers is that they'll all be Node2D children of MapView and possibly a mixture of tiled layers and loose layers in any order. Probably there'll be TiledMapLayer and LooseMapLayer classes that modders can subclass to implement their own layers. Maybe they can be made generic so that modders can create their own layers without coding anything, but I doubt it.

 

[Puppeteer]

@Quintillus the resolutions don't need to match. It might look odd to have a pixellated grassland next to a Retina-quality plains tile, but it's doable. Every Node2D instance has its own scale property. And every Node2D is like a window into its children.

We can zoom by scaling the map viewer and it scales its view of everything under it. But that doesn't preclude having a 128x64 tile at a 1:1 scale next to a 256x128 at half scale. Node2Ds have no size.

Images have size, but they aren't directly displayed; they are turned into ImageTextures and then assigned to a Sprite or TileMap or something, and those can be scaled individually.

@Flintlock

Sorry, I'm not getting the ideas in my head out very well. @WildWeazel wants a human-readable C7 save file format, and JSON seems to be the go-to choice for that. So I tend to imagine an analog of the BIC and SAV data, but in JSON format. So I'm imagining a C7 save file to be JSON with a bunch of optional fields for custom rules and such.

Unit files in Civ3 have metadata, too: the unit .ini files. So the JSON is more about metadata for our game and separate from a Godot scene. I figure if a modder doesn't want to use Godot themselves, they can zip up their media files with a JSON file declaring the coordinates relative to center image (or other predefined anchor point) and the scaling of the image. And the equivalent of what's in the unit.ini.

A Godot scene is just just a CanvasItem object. Instead of instantiating by code, the Godot UI is the GUI interface to configuring each node, but it is just a different path to the same destination. We can have our own scenes for using OG Civ3 graphics, scenes that can just read newer media and a JSON metadata file, and optionally someone can make their own scene for graphics and have all the abilities of Godot at hand.

What abilities? Shaders, sprite animation, physics...whatever.

---

To be clear, I absolutely want C7 to be able to run completely with original Civ3 graphics, but I think we can pretty easily allow tons of flexibility because we don't need to enforce pixel counts; we just need to specify scaling guides.

We're all doing fine, though. Don't stop or slow down anything because of my babbling...if you want to do something, do it. If things change before I start writing code, I can mock it up in a different repo.

 

[Vuldacon]

Puppeteer... What will be the differences for making Graphics for the Game. Differences in required Procedures and or Software?
I am talking about All Graphics, Terrain, Animated Units, Resources, "Civilopedia", etc...

 

[Puppeteer]

@Vuldacon First of all, any existing Civ3 mod would be openable and playable by C7. I think everyone is agreed on that. So the same tools would work there.

Beyond that, features are probably going to be emergent rather than rigidly designed from day 1. What we're doing now is familiarizing ourselves with what works and what can work at our level. And we'll need to start figuring out what will work for a typical modder.

I'm not familiar with the tools that existing Civ3 modders use and what they would prefer to use if it would work. I know they're constrained to a small set of tools that have to support PCX and FLC, or at the very least palette indexed graphics. I'm hoping to learn soon what tools they'd *like* to use. That knowledge combined with how we can implement the graphics in code will help us start connecting the dots and see if we'll need any built-in converters. Which, since we have have all the code and it's open source, and be easily either bolted on to C7 or released separately as an editor.

More directly, my current vision–which means little and less for the final design of the project–is that modders will be creating 32-bit RGBA art with their choice of software and saving it, hopefully in PNG or WebP format, but we'll see what's available, and maybe it will be possible to use just PSDs and XCFs, but we really haven't even glanced in that direction yet.

(This next part I don't seem to be on the same page as the other coders right now.) The art size won't be pixel-size-constrained. If you want to make a higher-resolution art, make it, and you'll have to put a scaling factor in a metadata file so the game knows what scale to draw it at to match the rest of the art.

The metadata...think of it as the BIQ and/or the unit .INI file. (Both of which C7 can use, but whose formats are unreasonable to extend as they are.) We want to have it in a human-readable format, and JSON seems to be the lowest common denominator there. (Or possibly YAML of which JSON is actually a subset of, but I don't think we've tossed that around much yet. There are several other human-readable open formats, but I won't introduce them if nobody else does.)

That said, modders won't need to know how to make JSON (or whatever). I'm sure we'll have something analogous to the Civ3 editor or Quintillus' editor that could build the BIC-analog and any per-media metadata (analogous to unit .INI).

For scripting, obviously Civ3 doesn't have that, so we'll be making it up. Maybe it's a folder full of .lua (or maybe .py) files, maybe it's one big lua file with handler functions defined, or maybe it's lua snippets stored as strings in the metadata.

For animation...that's still a bit fuzzy. PNG and WebP have animation formats, but last I looked, the animated PNG variant wasn't widely supported, and I really haven't poked WebP at all so far, so I don't know its level of support in creation tools. If nothing else maybe it will just be a static file with a bunch of layers which is how Godot stores an animated sprite in-memory, anyway. Alternately, having all the frames in one image is probably doable, but I haven't messed with Godot sprite animation beyond yanking all the FLC frames out and assigning them to an animated sprite object.

I have further pie-in-the-sky ideas involving optionally allowing modders to use Godot's features to make art, but that would be advanced and optional.

I haven't really considered sound much yet, but I really don't expect problems...I presume any sound can be converted with tools into mp3 or ogg format, or whatever. For composting sound clips I'm imagining more metadata, but maybe there's an audio format that can do that already...don't know yet. A lot of unknown, but I'm not predicting any hard challenges there. Well, aside from figuring out how to read Civ3's .amb files. I briefly poked at that and came up with very little, but I kind of think we can figure it out.

Actually, since @Flintlock is in there with a disassembler, if you happen at some point to learn anything about how Civ3 uses .amb files, let us know. It is NOT a priority at all. I (and others) think the that it is an orchestrator format to play different external audio files over a period of time, like play "steps" at 0s, "grunt" at 0.5s, and "stick clatter" at 0.75s maybe.

UI graphics...unclear as of yet. We devs seem to favor a responsive/scalable interface. Simply scaling a 1024x768 screen, for example, isn't really going to cut it I think. Most UI screens are borders around rigidly defined boxes. And now that I say that out loud, the obvious direction to go is a tilemap where the modder would design an image with border edges in a tile pattern, and Godot would fill the appropriately-sized area with the tile of a correct orientation.

This is a long video, and I doubt I've seen the whole thing before, but just look at a couple of bits of it. At 19 seconds he drags his mouse to place two blocks of grass tiles. (Imagine instead that the grass is the box background and the surrounding gray is the border you design.) At 7 seconds the tilemap image is briefly shown, and at 2:04 you see the middle of a much larger span featuring the tilemap image with purple gridlines shown. Our UI tile image might look something like the top-left, top-right, and bottom-right square patterns of the attached screenshot, where the borders of grass-to-blank and blank-to-grass are defined. Only it will be defining the UI border pattern and the UI box background pattern.

Ignore the rest of the video if you like. It is aimed at people using tilemaps to design 2d game levels manually. We'd just use the tile feature to make window-scaled UI boxes where appropriate. And the modder would just be making a 32-bit RGBA that looks somewhat like this.

 

[Vuldacon]

Puppeteer... Very Thorough Post.

Yes, The existing CIV 3/Conquests Games should be playable with C7. It would be such a waste if the existing Games could not play in C7.

Yes, the Graphics Modding Tools used are basically simple although vary between different individuals. I do not believe there will be any big problems there depending of the formats used.

Just a brief List include: Flicster, Civ3FlcEdit, Gimp, (I use Paint Shop Pro 9 and have other much more expensive programs that I do not need but Any good Graphics Editor can be used). Note that Civ3FlcEdit Removes the first Frame of an Animation and duplicates the 2nd Frame on the First Frame. There a "work arounds" for that problem but the basic thing I like about the program is the ability to make Offsets used for the Default Animation that allows the Unit Image to be seen in the "Right Unit Window Box" in Game as wanted rather than too High, Low. Left or Right.
Flicster will causes Streaking if the Unit Images are not kept 2 pixels away from the Right Frame Border. Both Programs are used and again despite the problems, Both can be used and work well.
There are many programs that can and are used for various Graphics adjustments such as FastStone that allows making Images Larger without causing pixelation where Blocks of pixels are added together to make the image Larger. FastStone does not do that, each pixel is different for enlarged images... No Blocky appearance.

.pcx is is the main format Modders are accustomed to using with the CIV Game.

I would really like Units to use all 8 Animated directions. All 8 Directions are animated, however the Game does Not show them all for Bombarding/Shooting and that appears way off the direction being Shot or Bombarded.

I have seen other Games use 16 directions for each Unit... using Mirror images of some of the created directions but that is not as important as just being able to use the 8 Directions that are made.

Sounds have ALWAYS been problematic with the Civ Game. Especially for Units where sounds play again after the Unit stops Running or Shooting. My thoughts concerning the problem are that I believe sound playback was created to have variety for ambient sounds and also used or affects Unit sounds. Sometimes the ambient sounds play loud and fast, sometimes they play soft and slow, just for variety using only a few ambient sounds.

Straight forward sound playback that absolutely matches the timing of the Animation would work far better than .amb files and be much easier and faster to make. .amb files also do not work as they should in game and yes, .amb files are small "programs" that play the sound bytes for a Unit at particular times and sequences within the over all Sound Playback. Sounds for Units could be made Better and Faster if the Sound Playback for them matched the Animation time. Adding the different sound bytes within the over all Sound would be a matter of math to know where to place the Hit or Shoot or Hit the Ground, etc...sound bytes.
...I have lost a Great Deal of Time over the years "Messing" with making Sounds for Units that will work as wanted in Game. Units Run and Attack sounds will also play differently between the center of the Game Map and the Coasts... Never have gained any insight about that other than having to do with the "Random Playback" feature that I believe interferes with Units. Perhaps with the Civ Game was made, they were trying to limit the Size of the Game and that caused them to implement the way sounds work.

Glad You and the other Programmers are seriously working on this Meritorious Endeavor

 

[Puppeteer]

Thanks! Oh, yeah, I have no ambition to *make* .amb files or make them a go-to for C7, but we're going to want to be able to read them.

Are you saying the format is known? Can you make .amb files? (Oh, I vaguely remember maybe someone hex-editing existing .ambs to play different sounds...can't recall that they could change the ordering/timing, though.) Also I had no idea the playback time varies. I can't imagine why that would be the case.

Side note: Epiphany moment: the concept around .amb files and what I've refered to as "composting" is non-linear editing. Which makes an .amb file a likely edit decision list. That may help us decode it better, and it gives me something to Google to see if there is an open-source format for NLE audio. (Well, that sent me down a rabbit hole, but given that we're using Godot I'm guessing we'll just have our on JSON-based list of what sounds to play, when, and at what speed. We can set timeouts for each audio cue. Unless Godot has sprite animation hooks for audio cues, too, in which case we use that. For more rabbit hole, start reading and clicking on links in AAF.)

The FLC copy frame is needed (if I recall correctly) for the animation to loop efficiently on ancient hardware, but we won't have that issue with sprites and modern hardware. FLC was already a dinosaur when Civ3 came out which is partly why hardly anything supports its editing, and why I had to code my own FLC and PCX readers because none were freely available for C#.

I didn't know not everything is animated in all directions. Interesting. Yeah, it should be trivial to be able to animate in as many directions as we want, as long as the art exists. I should really stop tossing all the ideas that pop into my brain onto the forum, but here we go again: I think it may be possible to put a 3D model, animate the skeleton, and animate it on the 2D map properly at any angle, with shadows. Forget you read that. I never said it.

As far as PCX...yeah, they use it because the kind-of have to. If they had a choice between having to get the palette right and just using the alpha slider/channel in their editor instead, which would they want to use? (Still figuring out how to handle civ colors, but I think we'll have something that doesn't occupy otherwise available colors in the main image.)

 

[Vuldacon]

Puppeteer... I looked into .amb files quite a while back as I wanted to make them. I discovered that if an existing .amb file is altered that can work but it applies the change to the existing .amb file too. Other than C7 being able to Read/use them for existing Games or if Users add them from past MODs, I do not believe they are needed.

Just basic info for .amb files: https://www.reviversoft.com/en/file-extensions/amb

Regarding the existing Animations for Units... the eight directions are used for all Animations except Bombardment at a distance. An Example is Bombarding NE shows the animations for Bombarding N.

If they had a choice between having to get the palette right and just using the alpha slider/channel in their editor instead, which would they want to use?

Not sure I am understanding what you are asking here.

My basic thoughts are because we want the past existing Games to work with C7, much if not most of the formats will probably need to remain. Understandably, it makes more work to allow C7 to read .amb files for the Units that use them when otherwise they are not needed or even desired.

The basic ease of MODDING and making Images and Animations for the CIV3/Conquests game are what appeals to MODDERS. No expensive software or extreme procedures are needed to make changes and additions.
Over All, the main desire is to have more ability to change the "Hard Coded" programming. People are accustomed to using the various programs and the procedures needed to create the Graphics they want.

Given a choice, I would try to keep the Graphics and simple programs and procedures to accomplish them the same. There is an appeal to how the Graphics look and feel in many of the MODDED Games. This quality allows the Player to be more involved in every aspect of the Game and utilizes the power of ones mind that cannot be duplicated... "Just One More Move" The main things that have been wanted and needed have more to do with programming than anything else... and THAT will be an extreme Chore indeed. Hat's off to the Hard Working Programmers

 

[Quintillus]

Spurred by the recent discussion by Puppeteer about how we should probably catch more errors, I was thinking about art again, and what's necessary for a "minimal viable artset". This got me headed to the Downloads Database, and 20 or 30 minutes later, I have C7 running with mostly community graphics:

The components are:

- Art Nouveau Interface by Balthasar, complemented by
- Completely New Interface by georgestow and HenryStow, which fills in most of the interface art that the above doesn't contain
- Snow Terrain by Balthasar
- Any of many title screens (I copied over the one I made around 2009)

Remaining Firaxis components are:
- Unit art (we have plenty of units, so proving that could be replaced without too much work didn't seem necessary)
- The End Turn LED indicators

It's also worth noting that there are likely other areas lurking around that are missing; opening the Domestic Advisor blows up due to a missing popheads file, for example. I also patched around a known-before issue where the menu buttons required the art to be in "Conquests" rather than just plain "Art".

Sounds are also missing currently, and we haven't patched all the places where missing sounds can cause a crash.

The main point of the exercise was to see if I could piece together community art to get C7 working in a reasonably quick time, and the answer is "yes".

It also got me thinking that it would be cool to have some sort of an easy "change your interface" function. Balthasar included a Nouveau.biq file with his art set for that purpose, but with C7 we could go a step or two farther, potentially having something like OpenTTD does to change your interface, independently from other mods, while making the interface options discoverable in-game as well.

 

[Puppeteer]

Cool!

Yeah, for Civ3 graphics we could just insert our own player-defined art path in the media search function (
Civ3MediaPath()), perhaps just behind the mod path, or optionally in front of it.

As far as distribution, of course we don't want much if any art (beyond the icon) in the repo, but we can probably have the GitHub CI automation bundle the program with media downloaded from somewhere on the Internet.

Oh, and I just realized we can and should also have our own 'native' media set in the search path, probably last after vanilla Civ3. Or maybe we need to allow runtime reordering of media source preferences...just a thought, not a near-term goal.