This week I tried to make a stylized water that looks decent, and matches the character's cartoony style. 

I think, overall, it looks alright! for being the hacky mess that it is...
So how is it done?
Basically there are three layers, a surface layer (which still needs some work) a "Deep" layer, and a decal for the Caustics on the ocean floor.

Let's start top down. The top layer is the water's surface and there's not much to it really, but it's still probably the most important of the three.

This layer is just a plane with a material on it. Its main component is  just two colors blended on a  depth fade. So the further away from something the material is  the bluer the tint becomes. 

 The depth fade is pretty common for water material tutorials  and if you have beaches, you should probably fade out the opacity on the edges as well. 
I opted not to and instead make the edges even MORE noticeable with a white border.

This white edge is probably why you've read this far as it's a pretty sought after  look for cell-shaded and stylized games.
It's pretty easy to do, and is just the second two boxes in the image above. It took me FOREVER to figure out, but alas it's as simple as a "Distance to Nearest Surface" node. My scalar parameter "FoamSpread" determines how wide the foam edge will be from another surface.

The result is fantastic, and it works dynamically, creating foam around the boats as they travel through the water!

The next step is a deep water coloration, because even in the image above, you can see my skybox where there is no sand below, so it needed to be fixed. 

My solution was to add another plane 100 units below and add a depth fade similar to the previous material.

The only difference here is that there  is a depth fade added to the opacity as well, so that at a certain depth, the ocean becomes 100% opaque. 

The two effects  end up looking good together and the illusion that the water fades into the depths seems to work. If you're doing this yourself, you might as well put the two effects in the same material. I might too in the future. 

The only reason why I did it in 2 layers was because I have a separate Nav-Mesh under the surface of the water that the boats can "walk" on while overlapping the water's surface.

The last part to make the water look like water are the caustics. What does that mean? I didn't know either but now I do. It's the light refractions on the bottom of the sea or a pool that have a  moving pattern. 

Colors may be a bit strong, and it's not perfect, but it's good enough for a first pass. 

Now to figure out how to make things sink slowly...

I love the idea of having cliffside villages and towns crammed in the top of mountain peaks so I created the landscape of Tribal to be a bit more dramatic (it is still placeholder at the moment). With higher cliffs, my ladder system seemed out of date and less useful as the need to cross larger gaps and higher cliffs became more necessary. As a result, I decided to create a dynamic bridge and stair creation system.  We'll talk about the stairs today.

The idea is you can build stairs built into cliff walls to get to higher or lower locations.

So how did I accomplish this? I'll go over the basic idea and you can create your own version. First of all, as I have a building placement system already functional, when you place the first half of the bridge, it creates the second half to be placed. 

Each half  uses the same code to set its location to the mouse courser on tick below:

The first commented section traces from the mouse to the ground and breaks the hit. 
The second commented section adjusts the hit to snap to a grid I have setup for my game.
The last little section adjusts the pad's rotation based on the impact normal. What this means is that the rotation automatically adjusts to face away from the cliffside. This took me a long while to figure out how to do and I went through a few iterations but this an is exceedingly simple way to accomplish that.

I also have a code for when you click, it places the pad permanently. So that's it for pad placement!

Then a spline is created between the two.  

​This spline is the steps themselves between two pads. There's quite a bit of code running on tick including quite a few "ForEachLoop" nodes which I know is bad. I'm not sure a good way around this, but it seems to work fine as there's only one of these running at any given time.

Put in basic terms, what this does is check if there are as many spline segments as the distance between the two pads multiplied by the size of the spline segments. If it's wrong, all the spline segments get deleted, and re-generated based on that distance. Then regardless of whether the spline's length is correct or not, each segment's starting AND ending location AND tangent is adjusted  to face the right way and connect to one another to match the movement of the mouse on tick. I know it's a lot! but take things step by step and you can  figure out a system for you.

With just this, you can create a bridge that grows dynamically from a starting location to the mouse's location!

Next step is to create a slight offset so the spline doesn't start and end at the CENTER of the pads but at the edge of them. This is of course depends on what you are actually trying to accomplish.

On tick (again!) I add a simple 50 units  to the location of the spline start AND end in the direction of each pad facing each other.

It seems like a slight adjustment but it really helps with believably. (And also helps with nav-mesh creation later). I also ignored the Z direction because these steps are meant to be built only on the XY planes.

This is the result:

You can see the edges of the steps spline always seems to snap to the correct edge of the pad.  I really like the way that worked out.

Finally, I created a check to see if  there is a cliff at every step along the path of the spline. This is so you can't build the steps in thin air. Of course this only applies to this specific inrastructure type, but I thought I'd add the code here anyways.

Again this uses forward vector and runs a simple line trace to see if it hits anything visible along each point in the spline. 
And that's it!

I had a bit of trouble getting my stairs to go around edges and around corners of the tall mountains and I thought it would be really cool to have the stairs wrap tall pillars in the landscape so I added some more code to place a middle pad and stretch stairs between the two. It was exceedingly complicated to figure out but I finally cracked it for quite a cool effect.

If you have any questions or comments please leave them below and I'd be happy to answer them.
​
Also a quick note that took me a while to figure out. To add a material to a spline, you have to check a box in the material that says "used with spline meshes" otherwise it uses the default material.

Defense in a strategy game is always a topic of discussion. There is a  always one camp that argues that playing offensively is the most fun and how the game is "meant to be played" while another that enjoys "turtling" or building defensively. Watching your defensive strategy succeed in holding back an army can be satisfying (that's why tower defense games exist) but this game is not about building defensive structures, but surviving whatever comes your way.
​
With that in mind, I still wanted to add defensive options. I started with walls, but quickly realized that that's not in game's guidelines. Walls encourage an isolationist attitude and I wanted vulnerability to be a major feeling throughout the experience.

Walls may be added back in at a later date (especially if I can update my water system so walls can hold back flood waters).

So I wanted to go with  a different defensive  approach. I first started with the Watchtower: a simple tower that can hold 1-3 people.

I like the watchtower for a few reasons:
1.) It's simple and easy to understand
2.) It can give the units in it small benefits (increased range)
3.) It could alert the player of intruders approaching with a non-intrusive notification.
4.) It can introduce the Minimap naturally, adding a minimap and revealing the view distance of your watchtowers on the map as well as enemy blips.

They way I've done this is not final, but basically it works like this:

I've created a camera high above the watchtower itself that is pointed downward (red arrow is forward).

When the building is completed, and someone is in the watchtower, the camera's viewpoint is overlayed on to a Render Target, making it a material and then cut into a circle (because I felt a circle was the best way to express the view from the Watchtower).

Then I create a square in the corner of the HUD and add this material.

I also have functionality that allows the camera to pan to where you click on the mini-map. It's great! Here's the result in game:

I plan to run a filter over it so it looks more like a drawn map than literally a camera shot of the surrounding area.

Hopefully, with the Render Target, I should be able to add multiple watchtower view circles, that can all be on the same mini-map, changing as you build more watchtowers. But I haven't yet figured out how to add multiple cameras to the same Render Target. I know it's possible, I'll bring my focus back here later on in development.

The three main categories I have basic units in are Melee, Ranged, and Converters at the moment. This doesn't include animals, boats or other forms of transportation. Nothing groundbreaking yet, I know.

​All the units (so far) cost the same to build. One Barracks, and one Worker unit.  This may change in the future as complexity demands, but I like the simplicity.  A barracks trains its unique unit type only and cannot change unit type. In order to build multiple unit types, you have to build another barracks and dedicate it to that unit type, and send workers into it to be trained.

Here is the current roster, from left to right: Brave (Worker), Warrior, Spearman, Archer, and finally Rifleman. I wanted to make 2 of each a melee and ranged unit type to see how the slight variety plays out. 

The worker can be talked about in depth in another post as they're by far the most complex of all 5 of these. Also, no converters are included in this line-up. I'll post about them later as well.

The way units stand around in strategy games goes overlooked quite easily. When it comes to movement, unit organization is often taken into consideration when groups of larger units get in a formation. Formations look great but that's not something that a Tribal game should include. 

However, if not in a specific formation, most games don't take unit organization into consideration at all, and allow units to group up however they please. I think it looks too messy and unorganized, and it's hard to pick out units and get the general army strength at a glance. ​​

To get this outcome, when 2 units meet at a location, they spawn a "meetup" actor. This meetup counts the number of units in the small area and sends them to a location based on the RotateVectorAroundAxis node. If there are more than 4 people, it sends the extras to another location nearby and repeats the process. 

Farming was originally NOT going to be included in the game. I'm trying my best to keep the game from becoming another resource management game. Don't get me wrong, I enjoy those games, Banished and Rimworld are some of my inspirations, but I wanted to keep the focus "Your units are your main resource" true. I've played a lot of city-builder games and every time a game has a granary as a core building, I sigh, thinking "It's another one of THOSE games..."

Regardless, I decided to add food as another resource in the game.
Here's why: simply put, there needed to be a limitation on how quickly you can acquire new people. Additionally, it  visualizes the current state of your village's success. It's  blatantly clear why your city isn't growing in winter when your crops are covered in snow.

To keep the crops interesting I set them up with a few specific visions in mind.
First of all, crops are a researchable technology. Although this might change, the idea behind it is to legitimize the viability of nomadic cities later on rather than make crops a requirement. We'll see.

Second, crop fields have unique requirements such as they must be placed on mud tiles close to water, which are the only source of adobe, which is used to build structures. The player must make the conscience decision to cover up access of another resource to grow food.

Third, crops are built in 2x2 squares or 4-in-a-row instead of one block tiles in order to encourage a bit of awkwardness.

Fourth, there will NOT be a resource stockpile at any time so the crops you have are all your available resources. There will not be much micromanaging needed to 

Finally, Crops are planted by harvesting a fully grown crop,  creating a chicken-egg situation which could be fun if you run out and are forced to steal some from a neighbor.

As for functionality, It's pretty straight forward.  There's a crop paddy "structure" that you build, then use a crop resource to sow it. The paddy grows to full strength and is ready for harvest. At the same time, a house with its progress bar 80% full will send out an inhabitant to get a piece of food and bring it back. If the house has a 100% bar AND food, a new person is spawned. Its is a bit unrealistic, but this is a video game. Not a simulation.

The farms  added a surprising amount of needed complexity as well. Having a finite resource that takes time to grow, that can be stolen or destroyed by enemies, and that is affected by the drastic weather patterns really went well with the current gameplay narrative.

Now, I know what you're thinking. "But Erik, my people are vegetarian boat people who live on stilt villages and never set foot on land. What can I do about food?"
And  the answer is, I got you:

These are floating aquaponics built of reeds  and wood based off of the real life floating village in Inle lake, Myanmar.

Pretty simple, but I like the look of it. 
And yes, I am still using  a water texture from Wind Waker...

If you have any questions or comments, please feel free to ask!

Also, I'm looking for testers, so I can send you a (really rough) version of the game for feedback purposes.  However, I cannot stress enough that    the game is NOT complete.

Ladders have been added to the game to elevate units up to higher levels and build buildings on stilts. My previous ladder system was a hacky mess which required quite a lot of calculations on the part of each unit while moving anywhere, even when no ladders were relevant. Thanks to a tip from Cpt_Trippz I changed the ladder system to include  a "Smart Nav Link" which automatically calculates a connection between two separated navigation mesh pieces once the ladder has been built.

The result is a lot more simple and it works quite well. You can see the green arrows connecting the green nav mesh planes. The unit understands that there is a way to go back and fourth between the elevations and approaches the ladder. Upon reaching the ladder, the unit will ascend or descend manually using the same functionality described before.
Unfortunately, it only allows one unit to climb at a time, so a workaround will have to be added.

I also added some new functionality to the ladders. If they are not up against a structure or cliff, the ladder will fall to the ground with physics. 

But after the ladder has fallen it is not useless as it can be picked back up and placed at a new location! Here is what it looks like when it's being carried. Pretty goofy but it matches the game's look so far.

The ladder can be carried by one or two units (it's much slower with just 1) and placed wherever  you like. I'm excited to see how this plays out in combat situations and I'm considering allowing the placement of units on flat roofs of structures like the Native American pueblos.

Let me know what you think, any tips you may have or ideas. Thanks!

As a tribal village, the main problem apart form combat that the player will have to deal with is the environment. I wanted weather effects to be clear and drastic, but also fair and survivable for the well prepared. There are three main disasters that can occur so far: floods, snow and fire. Massive rains cause floods, snowfall causes the water to freeze and weak roofs to collapse and fire burns through wood villages and grasslands quickly. I wanted the weather changes to feel sudden and powerful. 

I looked at other village builder games to see how they handled weather effects to some disappointment. Age of Empires and O A.D. snow is more of a change of scenery than something that must be planned for. Games like Banished and Rimworld treat winter as gradual threat that slowly grinds away your resources until suddenly people start dying of starvation or the cold. I wanted to go a different direction, making the seasons less predictable, more dramatic and more of a quick, punishing event than a slog.

Fire can be combated by building your structures out of rarer but stronger materials like adobe or stone, or by staying in wetter areas instead of the grassy highlands where fire spreads rapidly.  Settling in the swampy lowlands leaves you susceptible to  floods that can drown your people and sink your houses. Drowning can be avoided by building your houses on stilts and keeping your people in boats but snows will freeze the waters breaking stilts and making boats useless.

It shows you exactly when the snows will hit and when the worst of those snows will occur.  I believe this shows the weather for the 12 months of the year, three of which are snow in this example. I took this idea and modified it, so that you can see your current weather, and what weather is coming up in the next season. 

I added a UI element at the top of the screen, a 16 point wheel that rotates around clockwise. The arrow in the middle expresses which season you're currently in, so you can see which season is coming up in the next few months. At the moment, the art is non-existent, so red represents rain, green represents snow, and blue repeats the previous season so that seasons last longer.  At the moment it runs a bit randomly, but the idea is solid and it seems to work well. Next disasters will be added and have a chance of occurring depending on what the current season is.  Then throw up some nice UI art and boom!

Down the line I plan to add more season types such as droughts where fires are more prevalent and a darkness "season" where different enemies spawn, the dead may rise, cities need lights and units can disappear in the jungles without a torch.

​What do you think about random weather patterns, and darkness as a "season"? Let me know!

Advancement in technology is an already established system in strategy games. There are a few systems which are pretty commonly implemented throughout. Usually there is a technology tree, and research points are allocated into an available tech. Once that tech research completes, you are now able to build some new buildings or units another or a few more technologies open up to be researched.  This is the way it works in the Civilization games  and most other turn-based strategy games.

The downside to this is that nearly every civilization has the same linear progression and technological advances. It makes perfect sense from a game balancing perspective, but I don't like how your path is already laid out in front of you. I wanted to create something more fluid.

RTS games like Starcraft and Command and Conquer have a different system where by building a specific structure, you now have access to new units, technology and other structures. In Starcraft, these structures, units and tech trees are unique to each race which brings a great deal of diversity and different play styles, but again I wanted something less rigid. Even with multiple races, each with their own unique tech trees, you still know what your end game units will be every time.   I wanted to create a system that would allow a variety of outcomes from a single beginning.

Most strategy games use some combination of the two systems above, and I wanted to branch out from this in a unique way.

First I decided to look at what I wanted to accomplish in this project. I want to have a game where you learn new technological advances based on your specific problems, and multiple solutions work for each problem. Different problems can include environmental disasters, lack or surpluss of a resource, wild animals, other tribes and so on. Does your town keep getting flooded? Build your houses on stilts or build boats to keep your people out of the water. Nearby crocodiles keep eating your villagers? Build a wall to keep them out or train beastmasters to tame them. It also quickly became clear that you don't need all the technology, only what's relevant to your play-through. You don't need boats in the desert or snow-sturdy roofs in the jungle.

So I began looking at other games and what works with their systems. Skyrim has a system where you get better at what you use, and therefor advance in what suits you, which works well. Minecraft has an interesting system where building items allows access to more items, but it's up to you if you want to pursue them or not. I also liked the sense of discovery that came with messing around with the crafting grid and finding a new recipe.

I toyed with a LOT of ideas including finding technology in statues scattered around the map, doing mini quests for different gods that would reward you with specific technology, crafting your technology from combinations of available resources, and many others. But they all seemed too forced and too temporary. You can't be running around doing quests for gods, asking for boats when your people are wandering in knee-high flood waters already.

Then I realized, I needed to look back at the focus of the game, and draw a solution from that. Suddenly it all became clear. In my first post I established that the game would fully explore the idea that units are your main resource, so in technological advancement this should be no exception.

I created the idea of a "Thinker". A main unit that you could use to think  about different problems and he would come up with solutions. The thinker would engineer some technology based on the problem you have chosen and by reading the surrounding area and objects for inspiration. For example, you need to cross a body of water so you get the thinker and choose to think about the water. He may find you have quite a bit of trees around so he comes up with a boat blueprint, or perhaps he notices you have some elevation nearby so decides a rope bridge would work.

I really like this solution for a few reasons. First, it fits a design pillar of the game. Second, it creates a bit of "guided randomness" as you can only point to problems and you'll have to adjust to the solutions he comes up with. Third, there is quite a bit of discovery to be had from this. You might select the same object to be thought about multiple times and the thinker may come up with different solutions every time. 

Also, there are a few unrelated gameplay hurdles this character solves. It adds a good losing scenario and purpose to the game as well. If you lose your thinker, you lose the game. So you must take care of this slow, weak or defenseless unit. Much like the king in Chess. Also, it can introduce unlockables to be used in future playthroughs. I like the unlockable system in FTL because you play the same basic game but with different ships slightly geared for one strategy or another. This system can work in a similar fashion, where different thinkers lean towards different playstyles. One can be heavily militaristic, another a fan of naval transports or something like that.

Finally, I like this system because, as far as I know, nothing like this has been done before.
The problem with this will be getting new players to understand the system in a clear way.

Basically what's going on is: there's a check to see if the desired destination (the yellow vector) is not reachable from the unit's current location. If it is, go ahead and walk to the destination. Otherwise, do the "Get Ladder" function. In that function, it searches to see if there are any ladders that are reachable from  the destination, if so, get the nearest one, and move to it. Once at the ladder, the "Climb Ladder" function gets called and the unit floats to the top (or bottom) of the ladder, a delay is placed for the time that it takes the unit to climb the ladder (1.3 seconds) then the unit carries on to the desired destination. 

I hope that makes sense. Otherwise, don't worry about it! It works great. I even have it working for houses with ladders at their entrance. ​