next »

[Pixel Noise]

Those indicators are a great addition. Also, nice write-up on the pathfinding! Will have to bookmark that article, and keep that (and this post) in mind for future

[StormsInJuly]

Thanks

I went a bit further and added a visible building progress indicator and building queue, to make it a bit clearer what your city is building.



Also, I've fired up a discord server to make it easier to collect feedback and suggestions. If you want, come say hi!

[StormsInJuly]

I had been thinking a lot about how to implement weapons in the game.
Initially, I prototyped a system similar to what you see in most RTSes, where different arrangements of weapons means a different unit type - for example, an archer is built as an archer and remains so forever, if you want him to put down the bow and grab a sword, tough luck!

I knew fairly early on I wanted something with more depth and choice than this, so I've been expanding this system a bit while trying to fit it into existing mechanics.

Eventually, I settled on allowing the player to produce weapons, similarly to how reources are produced. A bow, for example, requires wood and rope.
Weapons can be equipped by any villager, but an armed villager can not perform duties such as producing goods or harvesting resources.


Here's a proof of concept of an armory, which now has 2 functions: Putting a villager in the slot on the left will produce bows, putting a villager in the slot on the right will arm that villager, effectively turning that villager into an archer.

Currently, the player can manage these weapons pretty freely, unequipping them and passing them on to a different villager, and so forth. I'll experiment with this a bit more to get a feel for it. If this feels like too much micromanagement, the weapon management process can be streamlined and simplified. On the other hand, if it's fun and feels rewarding to use, it can be taken a bit further with equippable armor in addition to weapons. Who knows?

[Pixel Noise]

That sounds very promising to me - I like the idea of being able to switch between villager/soldier as needed. Maybe, to avoid players abusing this too much - you might want to implement some sort of "cooldown" on changing "jobs". Or, if there are going to be levels/ranks for combat units, maybe switching an experienced unit back to a villager reduces their exp/rank, etc.

[StormsInJuly]

That sounds very promising to me - I like the idea of being able to switch between villager/soldier as needed. Maybe, to avoid players abusing this too much - you might want to implement some sort of "cooldown" on changing "jobs". Or, if there are going to be levels/ranks for combat units, maybe switching an experienced unit back to a villager reduces their exp/rank, etc.

I'm liking these ideas A variant on the cooldown suggestion could work too, where dropping & picking up things works as a "channeling" ability, e.g. it immobilizes the villager for 3 seconds, or something like that.
I mostly want to discourage (or atleast, not actively encourage) mechanically intense micromanagement, like swapping out a weapon right before a villager dies.

[StormsInJuly]

A while ago, I decided to redesign roads based on player feedback - previously, they were simply a requirement for most buildings, the game wouldn't let you place a building if you hadn't already built a road connection.

The primary reason for this is that villagers need to be able to walk around the town, and without roads guaranteeing a walkable route, it was too easy to accidentally build a town so tight that your villagers couldn't get to where they needed to go, causing your whole supply chain to break down, leading to great frustration.

The downside is that placing buildings turned into a tedious 2-part affair, and the road mechanics felt dated (while common in city-builders, the mechanic hasn't been seen much in RTS games since like.. Warcraft 1?) so I experimented a bit with the game automatically building roads, but eventually decided to simply do away with them as a building requirement, instead the game requires some empty space around each building, which makes cities easy to navigate for villagers and actually makes the villages look a bit better.


Here's what a roadless tier 1 town looks like. Note that only "buildings" have the empty space rule, while things like farms don't. Farms are traversable and don't get in the way, this also allows for some city planning to optimize available space.

Roads are now an optional tier 2 building, and when the player connects 2 buildings by road, villagers can transport goods more effectively, using a cart:

I'm pretty satisfied with this so far, as it feels a lot more rewarding to be placing roads when they actually give you tangible productivity benefits, rather than being a banal requirement that don't actually contribute anything by themselves.

[StormsInJuly]

Alright, so the sun’s been shining on my part of the world, and my productivity is inversely correlated with weather - still, I’ve gotten a lot done on the saving & loading mechanisms - the world you load now very closely resembles the one you saved, with a few puzzling inconsistencies.
I’ve also been churning out some content, and working on the map generation script.
One of the new encounters you can expect to find in the world is the raider camp, at its simplest form it looks like this:

They can be a bit of a thorn in the side, as they generate raiders that love to attack nearby trade routes - but clearing the camp out is rewarding in itself, when you control the campfire it will heal nearby units and grant vision in a pretty large part of the forest.
If you don’t have any units nearby, the fire goes out, but the embers continue to glow... which might reveal your location to enemies!

[StormsInJuly]

Dev update: I've been tying together loose ends, collecting yarn, leaving a trail of breadcrumbs, and avoiding minotaurs.



The tier 3 art style is finally coming together, and it informs the tier 1 and tier 2 styles in a way that makes me want to go back and re-visit them, but I know my project timeplan is stretched thin enough as it is.


Here's the tier 3 town hall. You will need to collect a variety of resources from across the map to gain access to the highest tech buildings.

I'm going to spend this week polishing the current features as best I can, then release a new alpha build unto my testers to hopefully get some feedback on the latest direction.

Also, I generally tweet more images than I share in blogs and posts, so that could be worth checking out

[sbeast]

Hey, I'm a big fan of RTS games (Age of Empires and Command and Conquer being my favourites), so I'm looking forward to see how this progresses!
Also, have you made any considerations about the music yet?

[Zireael]

I like the way you're thinking when it comes to the roads.

[StormsInJuly]

An issue that has come up repeatedly during Trollskog’s playtests is the question of settling multiple smaller cities versus growing one massive city (a megalopolis). I'd like to talk a bit about the problem, and my solution to it.

I should explain what I mean when I say city, first - In Trollskog, most buildings can only be placed inside a city’s borders, and built using the resources available in the town hall structure. Each city can support a population of inhabitants depending on its food supply and housing infrastructure.

As players explore the world they’ll find resource nodes to claim and defend, and a lot of the mid- and endgame content revolves around managing multiple specialist cities, and the choices the player makes to balance each city’s strength and weaknesses.

When testers discovered a new resource node in the world, however, they would oftentimes begin harvesting this resource in the simplest way: sending workers from their capital city to trek all the way to some distant corner of the world where they might have discovered a new silver mine or rock deposit, have the worker harvest as much as it could carry, then walk all the way back home.


Gold- and silver mines are an example of a resource node that players can find while exploring the world.

Initially, I didn’t think much of this: surely players wouldn’t continue “long-distance mining”¹ resource nodes in this way once they became more comfortable with settling new cities?
After playing around with it myself, though, I was vexed by how this simple move allowed the player to grow their capital city to an enormous size while not having to make any of the interesting choices² involved in managing multiple cities, essentially skipping a lot of gameplay content.
Worse, many new players fell into this behavior by default, finding it simpler to just wait for their harvesters to complete their distant journeys rather than settling a new city.

I tried a few different mechanics to mitigate this. Initially, I experimented with giving each city a limited inventory. If each city could store at most 4 different resource types, progressing past a certain point in the tech tree becomes impossible without founding new towns.


The town hall command card in the lower right shows the city’s 4 inventory slots (2 occupied by wheat and wood, the other 2 empty)

This gave me some variables to tweak: the number of slots and how many resources each slot could hold. However, setting these variables in such a way that prevented a megalopolis made this mechanic extremely punishing for new players, who often take a very exploratory approach to resources and tech, while being trivially avoidable by players more familiar with the tech tree. Since I did like the decisions that came from having to manage a city’s limited inventory size, a nicer variant of this remains in the game, but a limited inventory was not a powerful enough tool to prohibit megalopolis formation.

So I looked to other strategy games for inspiration, trying to remember what’s worked well and what hasn’t. Now, most RTS games don’t actually have cities - In games like StarCraft, Age of Empires and Command & Conquer there’s really just different types of buildings - a player can consider a collection of buildings of cities if they want, but the game itself has no such concept. Certain buildings function as resource drop-off points, and this drives the player to expand out into the map.

Of the games I could remember having a well-established city concept, Anno 1404 impressed me the most with its solution. The game allows the player to settle new islands, which function similarly to cities in Trollskog, each having its own collection of resources. Each island having limited fertilities forces the player to settle colonies in order to advance their capital. The game holds the player’s hand through this process the first time around, encouraging the player to settle an oriental island to secure spice production, required to progress to the next tier.

In the end, I decided to utilize both these mechanics to a varying degrees. Resource nodes that are too far away from a drop-off point simply cannot be harvested. The player can decide whether to build a full city near the resource node, or to build a resource outpost and transfer the raw materials to a nearby city for further processing.


The inner border represents the city limits, the outer (dotted) border represents the city's harvesting range. Full cities have both these borders, while resource outposts only emit a harvesting range.
The inner border can be expanded by purchasing more tiles with gold, the outer border remains more or less static. The tradeoff: Resources will not replenish inside the inner border - harvesting a tree there means it stays harvested.

With these mechanics in place, I hope the issue is resolved. Players should still be able to build large cities, but doing so shouldn’t be something players blindly stumble into, it should be an interesting challenge that requires tradeoffs and support infrastructure in the form of smaller villages surrounding the capital.

I’m testing these changes internally first, and unleashing it on my alpha testers sometime next week.
¹ “Long-distance mining” being the Starcraft (and perhaps general RTS) term for harvesting resources far away from your cities.
² Thank you Sid Meier for not patenting this phrase

[StormsInJuly]

Generating the maps of Trollskog
Generating terrain for a strategy game is a fascinating topic to me, because it challenges the developer to describe the ideal map in mathematical terms. The ideal map naturally depends on the mechanics and design of the game, which should be done before we can ask the question: what properties are we looking for in a good map?Randomness doesn't get us very far by itself, but it can be a great starting point if we add certain constraints and parameters, such as:

• The player always starts near a river
• The area immediately adjacent to the player's start location is free of enemies.

Not too complicated, yet. These requirements could be met with some simple math and distance checks.
But what if we want to spawn quest providers - entities in the game world that issue quests to the player - and place them in such a way that the player should encounter the quest provider before finding the quest objective?

For example, a troll tribe might recruit the player's help in finding a magical artifact somewhere in the forest: This quest would suffer if the world is generated in such a way that the player stumbles upon the artifact before finding the troll tribe, or worse; if the artifact spawns in some inaccessible location that can't be reached from the quest provider's location.
It becomes clear that we need a smarter way to plan the world and the placement of things within it.

The new terrain engine in Trollskog generates 64 by 64 tiles of terrain at a time (lovingly referred to as a chunk), by performing these steps:
Start with the rivers...

... because these are tricky to generate using noise functions. Instead, we start off with spline interpolation using two edge points with the lowest elevation as control points.
The image shows the chunk we've started generating. Since this is the first chunk and has no neighbors to worry about, we can freely place the river anywhere. Future chunks will be more limited in their river placement options.
Within the chunk, all subsequently generated entities must interact with the river: Villages should be placed near rivers, and bridges should be placed in logical locations. Therefore, rivers are placed early on in the generation process.

Generate the encounter graph

It's time to place the player's starting units. We observe a few simple rules when choosing a suitable location: The image above is shaded accordingly - the image is darker further away from rivers and edges. Picking the best spot for a town is as simple as selecting the darkest pixel in the image above. The same placement rules apply, except now we also wish to avoid already placed nodes.
When we reach the edge of this chunk, store the state of the edge nodes, we will be needing them when we generate this neighbor.

Ensure connectivity



First, create a voronoi diagram by iteratively growing each point that we have placed so far.
 This helps us plan discrete areas of the map to place enemies, and makes it easy to see which parts of the map should be connected.



Connections are generated between neighboring regions. There are a lot of clever ways to go about this, depending on your needs.
 The visualization on the left attempts to ensure all regions are connected as a spanning tree - after all, content that can't be reached is wasted content.

Bridges are useful for gating content and need to be carefully placed. For example, it might be a good idea to close off a difficult part of the map by blocking off a bridge until the player has the tools they need to deal with the enemies in that area.

Vegetation and forest

Using our favorite continuous noise function, generate some organic-looking data which we will use for a range of terrain features. There's a lot of great material written on the topic of noise, so if you don't yet know about the usefulness of this tool in procedural generation, check out some awesome posts on the subject.



Here, we can combine the voronoi region data with our noise output to create nice-looking forested with clearings around paths and spawn nodes.

And repeat...



Each chunk propagates its boundary conditions to its immediate neighbors, which in turn use this data to plan their large-scale features.

In general, as long as the rivers and roads line up right, some tricks can be employed to cover up potential seams resulting from generating these chunks one at a time.

The result

Here is what a generated map with 3x3 chunks, containing 3 towns, with highlighted connections typically looks like:


This algorithm makes it easier to plan and structure procedural content. In particular, structuring the terrain as a graph helps the AI navigate the world and understand tactical concepts like chokepoints.

The quest engine (which will no doubt be the subject of a future post) can request terrain features to ensure that quest providers and their objectives are arranged in a way that makes sense for the flow of the game.

Perhaps most importantly, we get to use smart-sounding terms like "arborescence" and "spanning forests" to describe and reason about the terrain generation algorithm... Seriously though, there's a vast amount of articles, libraries and tools on the topic of graph theory that are invaluable resources for a programmer.

The next steps to improve this algorithm would be generating mountains by individually elevating specific voronoi regions to make cities on hills, or elevating the edges between regions to mountains dividing the map.
 Spots where multiple rivers meet would be good spots to place lakes, and why not islands?
 There's a lot of room for improvement and creativity, and the terrain generator is a feature I hope to be able to revisit in a future update.

[StormsInJuly]

I haven’t posted any updates here for a while,
Long story short: I got fed up with repeatedly running into technical limitations of the XNA framework and decided it was finally time to make the switch to monogame.
So I dedicated some time to engine work and decided to de-prioritize my web presence until I got that sorted and could get back to producing content rather than tech.
So here I am, finally at that point now, with a massive performance boost (That delicious 60fps at 4k) and a cleaner graphical look.

(click for full res)
In that screenshot you can see the new walls and towers that are coming in an update soon, and did you notice those walls are walkable? Yes, indeed.. That pathfinding logic isn’t entirely without kinks yet, but it really helps keep those forward settlements safe.

[Zireael]

Looks amazing!

[StoneTide]

I love RTS, this looks interesting!

[StormsInJuly]

Houses and farms have been a design-wise thorn in my side for a while now, which I finally got some time to address this sprint 
The role of the house in the RTS has been that of a speed-bump: Something the player needs to build in regular intervals to support their growing population, but not really performing some active tasks when built. Houses (and their equivalents in whatever game, be it supply depots, power plants, etc) are built in some remote corner of the player’s base and quickly forgotten about.

Farms didn't really offer the player many interesting choices on their own either, and I couldn't figure out what they should cost: in the latest alpha builds, farms have simply been free, which sort of worked but didn't feel right. Both of these buildings are a bit too boring for the game I’m trying to make, so I got the idea to try and combine these into one, by giving each house a set amount of farm tiles the player can build near it.



So far I'm really happy with how this is turning out, and this opens up a few opportunities for player choice.. I have some ideas regarding this I wanna test this week, in particular why you’d choose NOT to build farm tiles on your house. More on that soon

[Josh Bossie]

Man there's a tremendous amount of love and care in all your animations. It's so good!

I work with Monogame for a bit and liked it a lot. Are you full time or part time on this?

[StormsInJuly]

Oh thank you
I'm loving Monogame and I can't see myself going back to a closed-source engine/framework ever again (and I hope they merge my pull requests some day). 
I work as much as I can while paying the bills and avoiding burnout which usually amounts to full-time at minimum, with some mental health breaks every now and then, but you know, indie gamedev!

[StormsInJuly]

I've allowed myself one more sprint to work on graphics (I want everything to look good for my release trailer!) and I might just be starting to get the hang of it.

My posts in this thread are usually quite image-heavy, but I think I'm about to set a record as I'm going to write up a rough outline of how a frame in Trollskog is rendered. If you opened this thread on mobile data.. I'm sorry.

In the beginning, there is geometry.

I’ve gone back and forth on how best to render terrain, but ultimately keep returning to the tried and true method of simply rendering a grid of vertices, laden with UV and normal data. There’s certainly faster and greedier ways to render this geometry, but this is probably the simplest.
Enter the entities:

Entities with similar texture, meshes and effects are drawn in one call. One day I will figure out how to draw all entities of all shapes and sizes with a single draw call. Until then, this step accounts for roughly 20% of the time the GPU spends on generating this frame.


Some buildings have a foundation, and cities have borders - these are both rendered as decals on top of the terrain. Subdividing each tile means we need fewer assets for most shapes - similar to marching squares.

Also, we got normals and depth...

I didn’t mention this, but in true deferred fashion, everything has been drawn simultaneously to three render targets, to collect the normal and depth data. Personally I think the normal map looks cool, so here it is. If you’d like to read more about deferred rendering, I wrote a  post about it a while back.

In order for entities  to cast shadows, we need to draw the whole scene again, but this time from the perspective of the sun. Luckily, we only need the depth buffer this time around, so we can save some time. Here, darker colors means closer to the light source.

Now, we can start calculating the lights for the scene. Note the shadows! This is a simple blinn-phong shader for directional and point lights.
Why so gray, though? It’s because this step is drawn in 64-bit colors, instead of the typical 32-bit. This means we get way more color space to work with than most screens can display. In other words, this is what you’d call a high dynamic range.

Multiplying the colors by the lighting gives us this. You’ll notice the light emanating from the fireplace and the speculars on the goldmine aren’t quite.. Correct. I added some Cook-Torrance specular techniques earlier this morning, I suspect there’s a bug there. (If you know otherwise, my DMs are open)
Aside from that, this frame is really coming together, but it’s not there yet. For one, it’s still in 64 bit linear color space, and there’s no postprocessing applied.
To get this frame down to the more manageable 32 bit color space, we gotta get the luminance data:

Repeatedly downsample the image until we are left with a single pixel. The resulting RGB values are the minimum, average and maximum luminance values in this frame, respectively. Using this information, we can apply a variety of tonemapping techniques.

Knowing the average luminance in the scene, we can determine a good bloom cutoff to make those bright spots shine.
That brings us to...

You either love it or you hate it, but personally I think SSAO can add a lot of weight to a scene, anchoring objects to the world. This is a variant called Scalable Ambient Obscurance (pdf) that has worked well for me.

The final scene

Finally, the color range is compressed using the reinhard operator, the gamma is corrected (hopefully not too much?). The SSAO and bloom textures are blurred, and applied to the final target.
There’s also some FXAA applied here (an anti-aliasing technique done fully in post) to smooth out some of the jaggies.

So this is where things are now, aside from some parameter tweaking and bugfixing I'm pretty sure this is the final pipeline, and won't be undergoing any major architectural revisions.

[StormsInJuly]

With those graphical tweaks, I went ahead and put up the Steam store page.

I'm thinking about moving the next round of testing onto steam, to get a better feel for how the Steamworks/steampipe API should fit into my working process.