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.
Using this functionality, I also allowed units to pick up canoes that have been beached so they can throw them in the water to be used. It really worked out nicely!
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.
All of these issues only have preventative solutions. Meaning that if you're not prepared before the flood hits, its too late and drowned units cannot be brought back. I also didn't want to do regular seasons. I'm not sure why that is, and it may change in the future, but I kind of like the idea of weather being unpredictable. These two factors, random seasons and the need to be prepared encouraged me to add a weather ticker. I took inspiration from Northgard, a viking themed village building game that has this:
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.
I knew from the start I would have elevation be a big part of this game. I knew slopes would be tricky so I decided early on that there would be sharp elevation increases and decreases.
But how would units traverse these cliffs and get to higher ground if necessary? I started out with the simple solution, that you could build stairs. But the result was both inelegant and didn't fit the theme. The next natural choice was ladders. I created a simple ladder model and got to work on the functionality.
I wanted ladder climbing to not be a task. The easiest way to create ladder functionality is, with a unit selected, you click on a ladder, he goes and climbs it. But I didn't want that. The functionality I'm looking for is, with a unit selected, you click on a higher elevation, he finds a ladder on his own, climbs it, and carries on.
This is what I came up with:
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.
It works well enough for me now, but there are a few downsides I've found. First, this only works for one level of elevation change. If there are two ladders in a row to get to a destination, it won't work, yet... Second, the "Climb Ladder" function is called inside each individual unit, so more than one unit can climb up and down the ladder at the same time. I feel like I'm clogging the units up with functionality. Third, the entire function has to run any time a unit is told to move anywhere, which may be a problem down the line. And yes, I know the characters "run" up and down the ladder, but I kinda like it, and I'm keeping it that way.
Hopefully I can use this same system to get units to traverse small bodies of water using available boats. All in all, I'm pretty happy with how it turned out!
This is still very much a work in progress...but today I'm going to talk about my Landmass system.
I wanted to make a randomly generated map, that was different every time you played, but I didn't want to create an algorithm to generate elevation in a believable way. Some people spend years on those types of algorithms, and I was not prepared to spend that kind of time.
Instead, I came up with a different system, one that I haven't seen implemented in a strategy game so far.
I actually got the idea from Diablo 3. Their procedurally generated dungeons are split into giant chunks, and each chunk has a specific entrance shape that lines up with other chunks in that tile set.
I decided to take this mechanism and implement it in an outdoor setting. But how would I make different tiles fit along the edges? It's easy to do in a dungeon with narrow hallways, but how could I do it with an open air environment?
I realized that the edges were the most important part of all of this. So I decided to make the edges of each tile a combination of elevations. Then tiles with a similar elevation combination can line up with that edge. I limited the elevations to 3 types: Low (L), High (H) and Water (W), but that alone wouldn't work. I decided to have each edge split half-and-half between two elevations. Half one elevation and half another elevation on each tile edge.
Each chunk edge can have one of the combinations above.
Then we can create tiles that look something like these above, with each edge a combination of 2 elevations.
I realized, that as long as the edges remain clean, the middle of the tile can run with creativity.
As there are 9 edge combinations, and although each tile has 4 edges, the actual total number of tile chunks I created is just 18. There are 4 combinations I omitted because they're strangely arranged (I may add them at a later date).
So basically that's it! The map ends up looking something like the sketch above. I created an algorithm that generates tiles, one at a time, by reading the edges of the tile right before it and the one above it, then choosing a random tile that fits.
You can see that this system allows for quite a bit of flexibility while remaining relatively simple. The texturing and colors are not final but I'm really happy with how it turned out!
From the beginning I wanted structures to be varied and interesting. I also wanted structure construction to be more than it is in most RTS games. Watching someone hammer the corner of a house as it "inflates" into full form is not satisfying to see. Again I looked to Populous: The Beginning as an example.
The structures I created are built up in segments, with half the workers hammering and the other half periodically going out to find more resources. Each added resource increases the buildings' model by one. The advantage to this system is I can easily make different buildings require more resources by just adding more segments thus making it slightly more difficult to build.
Also, as a building gets destroyed, it can be broken down by these segments as well.
I ran into the problem that I didn't want to be creating hundreds of unique building types and all their respective construction stages. So I came up with a modular system.
At the moment my game has only two resource types: wood and adobe. So I started with these two material type wall models, making them the same size. Then I created a variety of roof types that fit on either wall model which makes a diversity of structure appearances with just a little work.
The next step is to make a different shapes and sizes for each roof and wall type, so I can mix and match them freely, allowing me to make a huge variety of structures using combinations of these different models.
This is all still very much a work in progress but I feel it's coming along nicely. I hope you can see the idea here, and the flexibility this will hopefully allow for in the future.
If you have any questions or comments, please let me know!
I like the look of 2D sprite based units running around a 3D world. I knew this was going to be a part of my game from the very beginning. It has a goofy nostalgic look and it's really enjoyable, at least for me.
Using Unreal Engine 4 for this is very counterproductive. 3D characters are easier and more streamlined but I stubbornly stuck with my plan and I like how it turned out.
First I drew every animation frame on a piece of paper, scanned them and recently re-drew them digitally.
Here is the difference.
These are just 4 frames, so it looks clunky but you get the idea.
Then you have to draw the same 4 animations for all 8 angles of the sprite. I named my angles off of directions so below we have North-West, West, South-West, South, South-East, East, North-East and North, in that order.
Turns out animation is a lot more tedious work than I thought!
Since these are animated, you cannot use a Billboard component on your Character class as far as I know, so I used the Flipbook component and angled the flipbook to face the camera on tick.
I simply find the angle between the character and the camera and then set that as the flipbook's rotation (-90 degrees).
After doing this you will find that the flipbook behaves now like a billboard, always facing the camera but the animation will not change based on what angle the character itself is facing.
To do this we need a bit more calculation.
I have 8 sprites each at their own increment of 45° so I take the character's rotation ÷ by 45 to get our angle between 0 and 7 (Unreal Engine is 0 based so we begin at 0 instead of 1).
That is subtracted by the camera's angle to get the angle the character is facing in relation to the angle the camera is facing. I did a quick check to make sure the number is between 0 and 7. I saved that number as a variable "angling" and used it later to choose the correct flipbook.
The Switch on Int is using our "angling" to set the flipbook to the right angle. It took a bit of tinkering to get this right but it's pretty straight forward. Through testing I've found 0 = West, 1 = NorthWest, 2 = North, etc. Then you just place the correct flipbook and set it to our character's flipbook component.
I made a call to a struct that has all 8 angles of each specific flipbook type so the flipbook can be changed easily for different units.
You can see above that the units face the same direction as the camera rotates around them. This is a small but necessary detail. One of those things you only notice when it's missing.
It doesn't look particularly impressive but it does the job and I like the look.
And that's how I've made 2D characters able to run around in a 3D world and face the right way!
I want this game to be set in both an ancient and timeless world. In some kind of lost age with tribal communities all unique and different. Unit differences (as in model types) seemed to me like tedious work at the moment so I'm focusing on buildings, their architecture and how they're built.
This was probably the first color drawing I did with this idea in mind. Three different cultures, placed in the exact same spot, and how they would differ from one another. This was a good start, but I quickly expanded to thinking why different cultural architecture is the way it is. Building materials are usually those that are available, of course. Building shapes and height relate to environmental impacts or lack there of. Finally, cultural flairs are also a part of ancient architecture. These three elements combined are what is known as Vernacular Architecture and it explains why different cultures build buildings the way they do.
I wanted to implement this into my game. Building with materials available to create the basic structure, then altering the roof type to adjust to the current climate and weather, then additional structural improvements (stilts, etc.) as needed. I plan to have very extreme weather patters (floods, snow storms, forest fires) and you as a city planner must mitigate these problems as best you can. I suppose the point of the game is to create a culture which is perfectly adjusted to the local resources, region and weather patterns, all while defending from attackers. The difficulty will slowly ramp up until one day you're overrun with problems. Fun right?
The above pictures are an example of three different cultures handling both a flood and a snow storm differently. They all manage (although arguably the adobe houses struggle with the flood) while using completely different strategies.
This is basically the goal of the final product. I don't believe a village building game has been created yet that focuses on developing around your available resources and local environment, so I'm excited to see how it plays out.
One of my favorite video games as a child was Populous: The Beginning. It was a mystical RTS set in a solar system of village combat where each map was a spherical planet. The terrain was dynamic, the combat was hectic, there was an element of discovery and wonder to the whole thing. Unfortunately the camera controls are archaic as it was created before these things became commonplace. The Shaman was overpowered and reduced even large armies to dust in seconds, as someone who always liked the unit combat, this bothered me.
One of the best mechanics I liked was that you needed a unit to train another type of unit. You couldn't just throw 100 wood at a barracks and get an archer. Also, besides a few specific maps, building resources came relatively easy. I set out to create a village builder that uses this major mechanic:
"Units are your main resource"
It's important in video game design that the main focus guides all major design decisions. In order to hammer this in, I cut the idea of resource stockpiles because I believe stockpiles unintentionally make a city-building game into a stockpile-managing game.
The second mechanic I wanted was to have your architecture and building style change based on your environmental conditions. So that every play-through would be new and interesting. I didn't think having ridged "cultures" with their own appearance was the right way to go. I wanted something more dynamic, something that changed based on your needs.
I have always been fascinated with ancient architecture variety and I knew I wanted to make it a part of this game. This is an early sketch and the building system works differently now but the idea of variety based on resources remains the same.
This picture has different combinations of three resources: mud (circles), wood (lines) and stone (squares) and all the possible combinations. Currently stone is cut from the game to simplify the process.
So now the backbone of the game is: people are your main resource, and your environment affects your technology. Every decision has to be put through those lenses.
A few other design decisions have been made early on. First, there will be no game saving and loading. I find this rogue-like influence will have a positive effect to gameplay making each session feel a bit more intense as you know you may lose it all. Second, the world will be procedurally generated to increase replay-ability and add some spice into each play-through. That's it really!
I'll try to keep these posts short and specific, so that's basically where I started!
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