In this devlog we take a look at a few of the basic unit types. The Brave is the base unit that constructs and works every building. They can also be trained into other combat and utility units.
The video below looks at Warriors, Spearmen, Archers, Riflemen and Priests. There are going to be a lot more types of units in the end with the idea being that you don't need more than a few varieties, but each time you play, you get a new combination. I'm going to try my best to make each unit unique and have clear benefits and drawbacks.
Other types of units that are in the game, like beastmasters, are NOT included in this video as the mechanics still needs some work. I also have a slaver, grenadier, axeman, thurible and others in the plans. If you have some unique ideas that match the theme, let me know and I'll add them to the list!
The video also takes a closer look at the Thinker and how the Thinker interacts with the world and generates technology (this is still a work in progress and may be changed quite a bit).
Take a look at the video below and let me know what you think!
Again, if you want to see videos like these a week early, sign up on Patreon!
I have some words to say about how the combat was developed by looking at other games:
Nearly every strategy game is centered around a system of combat. It's easily comprehensible and crystal clear to the player who's winning through combat. There are games that don't use combat in competition (Offworld Trading Company) but most do. I knew how I wanted the combat to feel so I looked at a few examples of other combat systems.
There are a lot of detail oriented decisions to make in a combat system that have massive consequences to gameplay, so things need to be thought through fairly well.
Being a game based in the ancient era, combat has to be centered around a solid melee system with viable ranged as well. Unit numbers are in the dozens rather than hundreds, and the first obvious combat system to look at is Age of Empires.
Age of Empires, Warcraft and the like have a combat system where each unit seeks out and attacks an enemy unit. Each unit can be controlled individually and this can lead to some micro-heavy gameplay. Another notable feature of both of these games is that the units can bump into each other. This seems like a moot point but it actually defines the pace of the combat and how well you can micromanage your units.
Some units in Age of Empires use formations to help keep the units moving briskly, but formations are not a thing in tribal warfare so I thought it best to leave that out entirely.
The whole combat feel of most RTS games didn't fit the theme of Kainga. So instead I took inspiration from a fantastic game I've played too much of, Kenshi:
Groups of units will lock on to each other and fight it out individually while others support. The combat uses a system like this where people group and fight it out, then find a new group to join. It's hectic, fast paced and can't really be micro-managed which is ideal.
Sorry that's a bit of a ramble, but I hope you enjoy!
What would you like me to focus on for my next devlog video? I'm open to ideas!
Welcome to the first installment of my video devlog series!
In the first episode, we talk about the 5 main resources, Food, Mud, Reeds, Logs, and Bamboo. We take a look at how to acquire each one and how each resource is replenished naturally. Of course there are technologies you can get to increase your access to these resources and others.
In addition to using these resources for basic buildings, and making basic units, you can also use these resources in production buildings to generate more complex resources, further unlocking available technology and advancing your culture further.
Enough reading, let's watch!
This videos will be published on Patreon a week or 2 in advance, before being published here, so if you want to take an early look at the videos, check out the action over there!
Let me know what you think of the new format and what I can do to improve!
I'm always open to feedback and criticism and willing to take every comment into consideration.
Have a wonderful day.
While adding natural disasters to my game I hit a problem: all the problems affect the lowlands more than highlands. I removed resources from the highlands to encourage players to risk going to the lower levels. But it wasn't enough. There was no risk involved with building a city on the highlands and wandering below to get resources.
The solution came with fire. Since the highlands were already dry (not many trees) it only makes sense to have fire be an issue in the flat, grassy lands above.
The narrative behind this idea is that in the lower, swampier lands fire spreads slowly whereas in the highlands, fires spreads quickly and dramatically through the grasses, covering the entire area quickly. If your city is unprepared for a wall of fire to potentially sweep through your town, the results could be dramatic loss of population.
The way that fire works is taken from the write-up by Jean-Francois Levesque on the fire propagation system in Farcry 2 . Once a fire is started, it spawns a grid of potential fire-boxes. Each fire-box has a certain health that gets damaged by nearby fires. Once the health reaches 0 it also ignites and begins damaging surrounding fire-boxes. The amount of time a fire-box lives for decreases as the fire spreads to keep the fire from spreading forever.
You can see the fire boxed are extended by 2 squares every time a fire box successfully catches on fire. Fire boxes damage their neighbors, and the speed of the fire's spread is dictated by 3 main factors, what soil is below the fire, the wind's direction, and the weather.
The soil type below the fire dictates how much damage the firebox takes before it ignites itself. You can see in the above gif the fire has a harder time spreading on the green grass.
There is a global wind direction, that dictates the movement of smoke particles. I check to see if the firebox's neighbor is in the same direction as the wind direction, and if it is, add some bonus damage to make that box ignite sooner.
The last check, is to see if it is raining, foggy or somehow wet. I have a simple booleon that dictates if the box "IsDamp" and if it is, then the amount of damage it deals is reduced, slowing the spread of the fire.
Maybe you can see what's happening clearly here when I used my old fire effect:
You can also see, that fireboxes can hit other objects like trees and people which activates a Function on through an Interface that allows a huge variety of actors to be affected by fire.
Here you cans see my OLD and NEW fire effects next to each other.
I still like the old fire effect, so I use it for my campfires now.
So how can you fight such ravaging fires to protect your town?
Units can battle the fire by carrying water to the site of the fire and dousing it. However, you have to have a water source like a watershaft with a winch, stepwell, or the Ceramics Workshop to produce water jugs.
Alternatively, some specific wildlife might help you fight the fires if you learn to coexist with them!
Firstly, I recently changed the name of the game from "Tribal" to "Kainga", here's why:
Let me know your thoughts!
Getting in the Habit of Showing Off
Having worked on this project for over a year, it's difficult to know when it's "ready" to show to the world. Often when I'm about to show something from the game , I stop to reconsider because the game is not yet in it's ideal state. Well that's going to change!
Art is never "finished" so why not show the process and accept imperfection!
I'm quite happy with the trailer above. It captures the emotions and tones that the game is going for: a bit of adventure, feeling small in grand world, overcoming difficulty and a general sense of wonder.
But still when I watch it, I see so many things that still need work!
Dealing With Hesitation
One of the great things about playing games is the immediate feedback of your status. The level-up mechanic plainly expresses to the player that they're now more powerful and better than before. Unfortunately, life doesn't come with a leveling UI so we're left guessing what our current capabilities are on our own.
At some point in a creators process, the thought goes through their mind that their ability and skill is no where near their peers, and at some point, everyone's going to figure out that they've been faking confidence all this time. This is known as "imposer's syndrome" and it's very difficult to realize that everyone is always winging it, and there is no point where you suddenly become an expert.
The best thing to do in my opinion is to ignore it, stay positive, and try to not care.
Best of luck everyone!
Sharing it All
I want to take this opportunity to share the game, the process and all available channels to get information:
The game will be released on Steam and the Epic Store. Wishlist it and you'll get a notification when it's released!
Current plan is to have an Early Access release in the winter of this year.
This is the easiest way to show your support!
If you're the interactive type, or want to join the conversation and bounce ideas around or just chat and have a good-ol' time, Discord is for you. Welcome!
If you're interested in making sure that this project gets off the ground, and are willing to put even a little bit of money behind Kainga, become a Patron!
You'll get bonus content, behind the scenes views of the development, and have a say in the development of the game itself.
To be honest, Twitter is quite new to me but feel free to send me some cool cultural images, games or just chat @game_tribal.
See what's being worked on and what the upcoming plans are. I'm trying to keep this updated as best I can, but often, results may vary!
I compiled this comprehensive presskit to help you help me promote, if that makes any sense!
The presskit above includes, videos, images, descriptions, logos and more.
Feel free to share as much as you want!
Since my last post in September, I have been spending nearly all of my free time (I work 3 part time jobs!) on developing the visuals, the gameplay, balance and feel of Tribal.
As you will see the look is quite different and actually went through quite a bit of iteration.
The game is now set on a few larger islands that give you a bit more room to build while maintaining quite a bit of verticality.
I've added Papyrus and Bamboo as building resources in addition to the Mud, Reeds and Wood already present. I've also added Silk as the first luxury resource to be a part of the trading system not yet implemented. I redid the visuals of all the resources, all structures and working on particle effects now. Roof and wall textures can be changed simply to add a lot of visual complexity.
I've added raids that come from land and sea to keep you on your toes, I've also added a Hunger system which I initially didn't want to do as explained in my Farming post, but it seems like a good way to push the player into activity. I've also added fishing and hunting as a viable source of food with many varieties of techniques still to be added (spit roast?).
I've also completely reworked the thinking system by putting all technologies into different slots so you can choose what is most important to think about. Basically, now each Thinker has a different set of Slots (combat, transport, food, etc.) and each slot can be filled with a technology of that type.
I also added festivals, wild animals, fog, lightning and other weather effects. As well as overhauled the menus and UX design.
I'm working hard to get a video trailer and a demo done in the first month of the new year. I'll have a booth up at Reboot DevelopBlue, the game development conference in Dubrovnik, Croatia on the 23-25 of April, so stop by and try the demo there!
If you're interested in Beta-testing you can add your email below and I'll send you a link for the demo when it's available.
Here is the gif in video format, it may be easier to share like this, I have no idea :D
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.
This managed to be the most complex graph of all my materials but probably because I followed a tutorial that was pretty in-depth. I know you can't read the nodes in that image so feel free to follow Dean Ashford's Tutorial here to get the same result that I did.
The material is added to a Deferred Decal volume instead of a plane, covering the entire underwater architecture. This also renders dynamically which is fantastic for adding anything under the water that will move, as it will still cast this effect on it.
Putting all three effects together results in a decent looking water!
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.
Tribal will host a diversity of units of different types but hopefully each will provide an interesting gameplay use so that each play-through is a bit different than the last.
The catch being that you will never have all the options at your disposal. Your units will be randomized as the idea behind the game is that you must make do with what you're given. You can only ask your Thinker to create a new unit technology, then it's up to the Thinker to choose a unit type. You can request your Thinker to do this multiple times, but at the cost of sacrificing other potential technology.
Lining up in front of a barracks to be trained.
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.
Another option is for each unit to occupy a tile. But I want to keep my tile size rather large for clarity (a basic house is 2x2) while allowing the units to bunch up in large groups.
I took a look at Populous: the Beginning again for formation inspiration. They have a system where most idle units will gather in groups of 6 in small circles on a wide grid system.
I think it looks great and it's clear what's going on and easy to estimate how many units are standing around, so I copied that, but with groups of 4 instead of 6. I like the groups of 4 because the groups themselves can be closer together without being too crowded.
I liked it, but I felt the wide gaps between groups didn't help at all, so I halved the size of the grid from 200 to 100 units to allow the units to group up with each other more closely. This works well because building snapping uses a 100 unit grid as well (Unreal units). With the grid smaller, you lose some clarity but you can fit units more densely while still being able to select a predictable amount of units 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.
I like the way it turned out, it looks like they're hanging out together for the most part, while still looking a little messy and disorganized.
I used the same system for combat situations but it's a bit more tricky. It calculates the teams as well and sets up a majority and minority group. This creates the combat situation where, on one point in the grid, there can be a battle of 3v1 or 2v1 or 1v1, but NOT 2v2. If there are 2v2, one person from each team moves to another spot nearby.
You might ask, why go through this complexity just to separate groups of 2v2? The answer is, without this system, often groups of 4v1 would group up as a team in one spot 4, and the enemy alone and separated in another group of 1. This is not ideal at all and puts the combat on a halt entirely.
It may not be the best way to handle the unit organization, but it works for me so far.
I create, design and develop video games I'm interested in playing.
The Fire System
Melee and Ranged Units
Weather and "Seasons"
Ladders and Elevation
Animating 2D units in a 3D world
Setting the Theme
Setting the Focus