Imagine your game like this (very simplified):
Assets + Graphics → Binary (Anno1800.exe) → What you can do and see on screen
You cannot modify the Binary. What you can do, is feeding it new or changed assets and graphics that the game can interpret. That means, you have to stick to the rules, only if you write Code that can be parsed by the game, it will do what you want it to do.

What skills are needed to get started?

First, no, you do not need to be a programmer, although this is always a plus.
If you aren‘t a programmer, it is strongly recommended you familiarize yourself with the concepts of data types, variables, arrays, inheritance as well as (generic) dictionaries and vectors/lists. You don‘t need to write actual code with it, but understanding those is quite valuable.
Most of the game files are using the XML scripting language. I won‘t explain any XML syntax and going to assume basic XML knowledge, if you don‘t know any of this, you should read into that topic first. You should also be or get familiar with Xpath, since this is needed for the modloader later on.

So, this should be the first in some kind of tutorial series about asset modding. First, I want to apologize (no, not canadian) – the start is gonna be more dry and theoretical stuff, but you‘ll need it in order to get to the interesting parts, especially if you like to inject new functionality.
For Assets, Anno uses a few basic concepts all over again:

• Assets are actual ingame objects (like a building, a ship, or a construction menu) that are built from a template.
• Templates are Blueprints for Assets that configure defaults for values in each asset using this template, and say which properties it has.
• Properties are Containers that are directly contained by an Asset. Properties can contain Containers, but Containers cannot contain a property.
• Containers are collections of Values, vectors or other containers.
• Vectors are lists of variables or containers
• Dictionaries are like vectors, but each element gets a unique name that needs to match a hardcode the game is looking for. Because of this, the size is limited to the amount of available hardcodes.
• Values are simple variables or arrays

Note: To differentiate between the name of a value and the value itself, I will call the name „variable“ from now on.

This is the hardest to understand, but once you get it, you will have no problems understanding any templates and assets the game offers.
Properties.xml essentially consists of two parts: DefaultContainerValues and DefaultValues. Those are grouped for better overview in the dev tools, but in general you could narrow it down to those two.
DefaultContainerValues defines which Containers a property uses, define Variables inside those containers, in case the container contains a vector or dictionary, the content type of this data structure is given.
DefaultValues defines the variables that are contained directly inside the property and inherit the Containers from DefaultContainerValues.
As the names might suggest, setting the a value for a variable inside the properties.xml sets this value as default for this variable in every asset using this property.

You can change the values for variables, but you cannot tell the game to load other containers or variables, since this is a direct export of what the game expects!
Note that on rare occasions, some of the export is incomplete, in that case every variable is given inside assets.xml.

If you need any information on what you can do with each property, this is where you should look. The following is a shortened version of the „IrrigationConfig“ property, along with some comments.

In case a container A contains another container B, B is defined in ContainerValues and then inherited by A. If B contains Variables, those are defined in the same spot.
The following example shows the DefaultContainerValues for the IrrigationConfig property:

The full definition of our IrrigationConfig should look something like this:

The following Data Types are used for variables:

• int → mostly signed 16 or 32 bit integers
• float → american style 0.1305
• boolean → noted as 0 or 1
• String → without quotation marks
• Hardcode → used like a String, however only predefined names are accepted.

You need to figure out the data type of a Variable by yourself by taking a look at how it‘s used inside all three files. Also, there is no full list of hard codes that can be used. Previous games like 2205 had a datasets.xml which contained this information, however this is not the case with 1800, and it would be a great thing if something like this could be published in the future by Ubisoft.

A template consists of a unique name as well as a collection of properties that objects using this template have.
The same as properties, Groups are only there for overview in Dev Tools and essentially are irrelevant

i.e. take a look at the Template „UnlockableAsset“

This one only has the Standard and the Locked Property.
Templates can define default values for any variable inside a property, which is then applied for all assets using this template, and that‘s essentially it.

At this point we should take a quick look at inheritance in general.

This is our custom template „CustomIrrigationConfig“.

As you might recall from earlier, the Property has a default Value of 2 for StaticIrrigationRandomizerFrequency. We now want to change that to 5, but keep the rest.
For this, we do not have to copy+paste everything, we just have to change that variable and leave the rest out.
In templates and assets, containers are automatically inherited, however properties are not (keep this in mind!). We could also manually inherit containers, but we do not have to.

Now, we also want to change the FadingSpeed inside VisualsAndEffects. For that, we have to first manually inherit VisualsAndEffects, inside that manually inherit Vegetation, and inside that override the FadingSpeed.

For dictionaries, the unique names are treated like containers, for vectors, inheritance has to be made manually. For this, see here (Only german).

Now let‘s get to creating actual ingame objects. Each Asset has the Standard property, which defines the GUID of an object.

An Asset consists of a Template and Values. To create our asset, we start of by specifing the template. In our case we will create a simple building from the template FactoryBuilding7. For Values, we will note down the exact properties that this Template has, without any Variables or Containers.

Then we‘ll do the Values.
I have decided to allocate the GUID 1337733142 for my building. This is now added in the Standard property as a Variable. For better overview, we can set a Name inside Standard too, though this is only for us. More about GUIDs you can find here.

Theoretically, we now have a fully functional factory. Except it produces nothing from nothing, does not cost any workforce or credits and does not have construction cost.
So let‘s assign those things to our factory.
We will make a factory that produces canned food from zinc and potatoes, and just because we can, we will do it in the new world with Obreros.

One thing is missing now – the visuals. Anno more or less seperates graphics from logic. Everything graphics-related is stored in other files, we simply reference their path, starting from the game‘s „data“ folder.

Take a look at the example again. You should pay close attention to Building, Maintenance, Object and FactoryBase Containers, you will most likely encounter them many times.
We now have a fully functional asset that we could add ingame, that Anno will interpret correctly.