The Hog News 19

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

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.

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.

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 :)


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.



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).




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!



The weekly hog news 17

These past weeks i’ve been working on solving lots of different kinds of technical issues.
I’ve now completed a basic registration of Ymir on steamworks and started learning how it all works, uploading my first test build on steam.

I’ve also , at last, merged all the old server code into the client, so everything is now combined into a single program.
I’m now busy repairing and updating all the networking functions and starting to actually get this new server runnning and communicating with the client again.
Its a long process as, since the prototype, not only did i decide to update to a quite different version of the engine i’m using but i also to got rid of as much of the 3rd party extensions i was using as possible.
I did this because even if these were adding tempting new content to the engine, in the end they’re a liability and a source of problems.
Its a bit like having a game with lots of big mods. Each mod sounds nice on paper, adding new features. But in the end you start adding these and when your game crashes you can’t do much about it. First its a problem as everytime the game has an update, you have to wait for all the modders to also update their mods , then reinstall these, and its time consuming. And usually by the time they’re done, there a new game patch.
Then there’s moders who eventually abandon their mods after they get bored, and as they did all that for free they dont own you anything after all. So when the game has a new patch, you’re left with incompatible or unfinished mods and there’s nothing you can do about it.
Well its a bit the same with the engine and its 3rd party extensions. So i’d rather be dependent on as few things as possible and i’m trying to eliminate all the extensions i was using in the alpha1 prototype. Which includes the networking library itself. So all that + the new engine version update is basically why i have to repair/inspect each mecanism of the program one by one.

The weekly hog news 16



As most of you hog followers on facebook already know, Ymir was greenlit last week after 11 days. I’m really happy that it went pretty smoothly and gratefull for all the support , votes and sharing you guys did for the game!
Also thanks to Elissa Park for doing this new voice over in the updated video presentation for the Greenlight.
This had kept me busy for the last weeks and now back to regular development.

Also a special thanks for my good friend Alexandre Chaudret who made well… i beleive it to be the first fanart of Ymir , for the celebration of this Greenlight. Behold Lucius Porcatus! ( Also clic on that hog to check out his awesome other works! )

Now besides that what’s new…
I’ve finished the basic functionalities of the editor.

I added the support for “primitive spawns”.
Primitive spawns are regions that can potentially host a primitive tribe when the game starts. Basically a player spawn, as when a player joins the game he takes control of one available primitive tribe.
Unlike the alpha 1 prototype where things were more random causing problems at game start, these regions ensure the presence of at least :
– One meat source ( wild animals )
– One alternative food source ( generally a cultivable food source like wheat )
– A small fresh water source
– A small clay deposit
When a map is generated, it randomly sets some regions as a “primitive spawn” ( generally regions with a natural source of fresh water like lakes and rivers ), but this flag can be set manually in the editor when creating custom worlds. For exemple this way you can create a world with continents where no player can initially spawn on.
These starting resources will probably change as the game gets balanced, but the tech to allow specific resources for starting regions is here.

A small fresh water source will spawn in regions flagged as “primitive spawns” when they lack any natural source ( like rivers or lakes ).


Also i now started working on the game creation setup and the “New game” menu.

You can choose between procedural and custom maps.
A custom map is a map manually created in the editor.
A procedural map is generated automatically with different settings. You can set these settings yourself or use presets like “Terra” that generates standard Earth-like maps.

Game settings have 2 different modes : Official labelled games and custom.
In an official game, you cannot customize settings and -if ever one day- mods will not be allowed . Official games offer standardized game-balance and speed presets for a reliable game experience so players won’t have to struggle looking for real “vanilla” games.
Theres is for now 2 types : persistent and real-time. Persistent is the official preset made for games meant to be run 24/7 in a more “MMO” experience, with higher player number and where players are not supposed to be ingame all along. In this mode things like resource production , population growth or units movement on the worldmap are slow and balanced for a server running permanently.
Real-time is meant for smaller games, such as a private game played with a small group of friends and where all the players are supposed to be ingame at all times. This is a game meant to be played, stopped and reloaded for the next session, and where things like resource production will be fast enough to keep players busy in real-time. Think Anno in multiplayer.
But you can also create a custom game. While it won’t be labelled “Official”, you’ll however be able to set your own balance by tweaking the game parameters like construction speed, resource production multiplier and cycle duration, unit speed etc…

Now that the game is greenlit, there is actually a set of administrative things to do in order to complete its registration before i can fully acces Steamworks , including getting a US Tax identification number which can apparently take a while… :(
After that, i can start discovering and learning how this all works and test/continue the development in steam, which will take a while ( that’s why i needed this greenlight this ‘early’ ).


Ymir now on Greenlight


This is it gentlepigs, today we signed up Ymir on Steam greenlight.
This is the first major milestone for the project, and now more than ever we need your help to support Ymir and share this news.

Why the greenlight now even though the game isn’t finished ? Greenlight is critical to gain access to steam so we can test and develop the game within its final aimed environment as a final product ( exemple for accounts, server management and listings etc ) but also to be able to easily organise alpha and beta testing as the development goes.

It is of the highest importance that you vote for us on greenlight and share this to everyone you can! And i mean EVERYONE!