The Hog News 19

In the last 2 weeks i’ve been pushing for big optimizations.

PATHFINDING
First of all, i spent about a week on pathfinding ( pathfinding is the system used to allow things like units to move in a map and find their ways ).
The previous system was too slow to find paths on complex region grids.
I’ve first learned about an algorithm called ” Jump search algorithm ” that is incredibly faster than the basic one is was using, especially to find paths on grids with lots of open spaces.
Considering there was little complete doc or tutorials about this except the actual original academic paper , it took me a while to really understand it as it was written in a quite opaque way ( at least to me ).
But there was a downside, as this algorithm only works for grids that have 2 values: empty tiles and blocked tiles.
This is not the case in Ymir where i need each tile to have different costs. As an exemple, roads are tiles that “cost” less than regular terrain so that if there is a road available, the units will tend to walk through these instead of regular terrain, as a unit will always try to find the path with lowest cost.
So i then had to actually modify this JPS algorithm to work with this type of grids and values. Its not perfect but its now incredibly more fast than my previous system and it should now be enough for the release standard i’m aiming, andenough to allow the more complex battles with walls.

This is to give you an idea ( and as its pretty much the only visual thing i have to show ).
Below is one of the exercises i made to test the pathfinding.
The left one is the pathfinding result and the right one represents the terrain where lowest costs are light green and highest one is purple.
Starting from left blue point, the objective is to reach the other blue point on the right.

The light green line would be a road. In the middle you have a vertical river with shallows in dark green in the north and a bridge in the south. On the left is a vertical cliff that the road crosses where its less sharp, and some buildings. On the right, there’s a ‘fort’ with walls in purple and a few buildings in it. The road goes through gates that are weaker than the plain walls. There’s a second wall south, and it has a weak point in green.

On the left you have the resulting path : the troop would reach the road going left, then follow it, cross the river south , follow the road to the gate and then go to the wall’s weak point. They then breach it and attack the left gate to enter the fort and reach the objective.
If there was no weak point , the would choose to cross the river north through the shallows and attack the northern gate. If there was no bridge and no shallows, they would have to cross the river itself.
No matter what , the path cannot fail and will always find a solution that will define the best available strategy, even if it means crossing river with small rafts, climbing cliffs with ladders or breaching walls.
However it can still be improved as its doing mistakes here : its doing 2 weird diagonal movements instead of going straight after the wall weak point, and it should stop following the road and go directly to that weak point instead of going up to the gate on the right and then back.

REGION GENERATION
The time to generate a procedural region has been divided by 2 ( From about 8 sec to 4 sec ).
Its still not enough though for the release standard : because this has to be done by the server during the game whenever a player goes to a new region for the first time, it has to be really efficient so it doesnt make the server “hang” as it’s constantly busy doing all the other things of the game. So it has to happen while allowing the server to keep doing all its other tasks. The problem is not really the total amount of time it takes to make the region, but how its splitted : the server does it little by little so it can keep doing other things instead of just doing only this for seconds. So each little step has to be really short in itself, and that can be quite complicated to do. This is what’s been improved as well , though it might not be enough and will require more work.

FPS OPTIMIZATIONS WITH SHADERS
Using shaders i’ve made 2 big optimizations to  improve framerate in regions. Animated grass and trees is now done by shaders, and the static grass drawn on top of the terrain cubes as well. Bottom line, the result is that regions have had their FPS greatly increased and also their loading time reduced. Its now satisfying enough for the release standard  ( at least empty regions ).

The -not so weekly- Hog news 18

Hi everyone!

It’s been a while since the last news 🙂

SHADERS

I’ve completed my learning of shader basics. After doing basic post processing ones applied to the screen, i’ve now reorganised the way the game itself is rendered so that i can apply shaders to game objects themselves and create shader materials.
Firstly this means that now i’ll be able to have different material behavior depending on the tiles : exemple a wet clay ground tile can look wet by reflecting the sky, ground with a soft specular reflection, water tiles with animated waves and reflection ect…
Then it unlocks lots of potential optimizations in the future, because i can do things through using shaders instead of “regular code” and its usually way faster ( and it has the other advantage of using the graphic card processor instead of the main CPU, balancing the computer resources usage ).  First one i plan is to use shaders to deal with some expensive animated sprites ( all animated vegetations ), which will improve framerate. In the end i can potentially use shaders to  make the procedural generation of regions faster, but it will be a big work so its on hold for now. Anyway having learned this new skill took a while but it will be worth it in the long run.

Here is its first visual result. I heard as general feedback in the greenlight that the worldmap was now really below the level of the rest, so i’ve been working into making it better and doing my first complex shader : a sea shader for the worldmap.
I learned how to actually use a normalmap and render it. It creates an animated waves normal map out of 2 textures , reflects the sky and blurrs with distance, and also has a colour gradient from the coast tiles to keep this 2D style. There’s also a foam effect that looks quite nice from a distance, creating lots of small flicking white points on the blue sea. The shores are also animated.
Its a first step to improve that world map and make it look less static. Next step is to animate trees and grass through shaders. The normal map probably still needs some tweaking as i think its too strong on closup.

 

GAME LOBBY

It is now possible to launch the actual game again from the front end, at last.
Whether you start a game from the UI i showed the other time or load an existing game, or in the end join an existing multiplayer game, you’ll arrive to this server lobby screen.
This where you’ll see your characters on this particular game, and create new ones. In the screen below, there is no existing character and the only option is to create a new one.
Factions now have their own name generator so you dont have to spend hours wondering how to call it if you don’t care, and can start right away.
On the right side you have the spawning options. Depending on your choice and current availability, you can see how many starting points match your settings. Obviously you won’t be able to start if there’s none.
You can choose a general climat type, and the 3 starting types : primitive tribes is the default start where you start from nothing, colonies are regions created by players themselves, and anarchic regions are regions that don’t have any owner ( the original player lost or quit the game ). At game start only primitive starts will be available, but as it goes these will disappear and you’ll be able to start from existing colonies or regions (so late joiners won’t have to start from scratch).

 

 

GAME START

In primitive tribe start mode, you no longer start with a pre established village. Instead you start with a single unit, your tribe. Also, all other pending primitive tribes are actually ingame from the start and visible as part of a primitive tribe non-playable faction. Everytime a player joins, he takes over one of these units.
If players destroy these, they actually destroy that starting point. This way everything is coherent with the universe, and you don’t see villages spawning from nothing.
Also the point is that as starting regions tend to have extra resources making them more interesting, players used to colonize these first.
Now it will be more complicated to do so as they’re defended by an actual unit.
It will require some balancing but in the end the point is to make it hard at the beginning of the game, so primitive starts can be preserved for other players to join.

Also i’m redesigning the bottom left unit menu so that everything regarding units can now be done through this one instead of using a second popable centered window menu. Regions will use that same bottom smaller menu.
Right now i’m re establishing all the functionalities of the worldmap ( still in this general task of updating the alpha1 prototype ). When its done, i’ll move to the region. And then eventually, i’ll be back at the prototype’s point of progress and can start adding new features at last!