These last two months were very busy for the studio.

Dionysos’ work, one of dWARf’s arenas, has intensified, especially at mid-october deadline’s approach. Many debates appeared as we went along production. The more we were coming forward to the finishing stage, the more we noticed problematic details that we needed to fix.

     Dionysos was a good way to test the organisation which was set up further to the mistakes made with Hephaïstos. Having a little team allows us to make constant adjustments and to communicate quickly on organisation or method changes. Dionysos allowed us to see that the decisions taken following Héphaïstos’ production worked really well. It speeded up the production and improved team communication. However, a system can always be improved, and, in October, I’ve spent most of my time readjusting production’s processes, making the most exhaustive document possible (but still editable in light of new experiences).


     To all this work was added another pressure : the organisation of a playtest.

A playtest aims to get live players’ feedback of a representative panel. For a playtest to be as interesting as possible, the build (version of the game), which the players are going to play on, has to be the most complete possible. So, the remarks would not be about what we’ve already analysed and fixed on our side.

For instance, if the sound gives a gameplay feedback (a little bell that rings when a player finishes an action), the sound has to be in the tested build. Otherwise, we would take the risk that the player complains on a lack of feedback (what we call a “ sound feedback “) on his action, whereas this feedback is planned. It would thus be too bad that the player focuses on a lack, which exists, in reality, only because the build is incomplete. So October was also a challenge period regarding the organisation of this playtest, and the determining of the presented build prerequisites.


     The playtest is also a good way to test our game communication, especially on tutoriels, gameplay videos and arenas presentations.

These last two months, also on the communication line, we’ve worked on the ► first teaser of the game. You discovered it on YouTube and on Twitch during the Paris Games Week. Giving a story to dWARf was a very personal wish. I really wanted the game to have its own universe, which players could enjoy and wish to enter.


     Alongside, we have made another “play-doh meeting” for the next arena, Poséidon (I told you these last two months were very busy!), and we started working in accordance with the newly created method, more specific and more adapted to how our team works.


     I have also worked on many other little surprises that you will discover as we go along next months !

2D GRAPHICS - Audrey

Réflexion sur les processus

    The 3D creation of the next arena, Poseidon, was initially due by November. Yet, we decided to rather wait a few weeks before this step to make the concept art. We realised that arenas were subject to game design evolutions, including, until very late, graphic elements. If I start working on it too early, I take the risk having to remake a lot of elements, and maybe even having to rework on everything to gain some coherency… and then losing time that I would spend doing something else (see the anxiety, ladies and gentlemen). It’s also this being a small team ! 

For example, this board overview concerning a duck-billed platypus will eventually not be integrated.

    I then had 2 months to carry side missions out : complementary elements (refining pedalos, designing ducklings) or more varied ones (sketching various UI icons, continuing the Community Road Map…). Hence the desire to take advantage of the opportunity to make a teaser, the introduction of the game’s story ! The writing was then started.


     We were a few to keep an eye on this bonus project; the production of the game being the priority. But a quite vague distribution of our roles led us to make a few mistakes in the production.

     Afterwards, other ideas of format (3*1 mn for example) came to our minds. We sometimes start a project too fast in a direction, not wanting to lose too much time beforehand. But it’s important to take enough time in the beginning of a project, because not putting your ideas to the test (of time, or others) can be really constraining afterwards. When we’re coming to the end of the project, it’s difficult to back out (and often unthinkable to start from scratch without completely giving up). It’s a reflex we tend toward regarding arenas creation, but unfortunately, we somehow missed it here.

Steps and choices

     For the neophytes, here are the production steps of an animated video, to be considered in our context, of course – when we don’t want any bad surprises 😉


  –  Rewriting of the story to make a storyline = imagining the key steps of the story


  – Writing the voice-over = linked to the storyline and the storyboard to avoid repetitions

  – Graphic researches = references for the style (visual and animation), colour palettes, tests

Some researches in a graphic direction that we had validated, but I finally thought it was inappropriate regarding the subject. Researches of style (sometimes from graphic references), colour, composition. Tracks often too close to more modern things, too shifted from what’s commonly a teaser’s form.

– (Storyboard from a storyline = Still frames to visualise the upcoming animation and the links)

– Voiceover recording = Defining a tone, its atmosphere, its rhythm

– Animatic = Laying the foundations of the animations, the intervals of 2D animations, motion design


– Animation = clean illustrations, 2D animation intervals, motion design

– Finalisation : Sound designing, mixing, visual effects, colour harmonisation, exporting…


    Concerning the animation, I decided to go for animated illustrations; not traditional pure animation (24 drawings per second for fluid movements), nor pure motion design (animation of graphic elements with a software), but rather a combination of both. 

    On this scene, I used 3 images (frames) to evoke a raw movement; the blaze gushing from the volcano. But I also used some interpolations to make the ashes fall in a softer and more delicate way. I added a 3D option (for the spins), and some blur to provide an illusion of depth.

    Here, I drew some frames to animate the dwarf and the approaching shadow. No deformation effect (squash and stretch); I stay in a quite modest guiding principle of the animated illustration. I make use of the software to make the glass “smash to smithereens” on 2 superimposed plans, and again provide this illusion of depth.


    Finally, I come back to the production of the next arena’s concept art : Poséidon ! See you in the next episode !


     Mid October objective was to end globally Dionysos arena. We then add to assembly-line texture every scenery elements modeled during summer. This quite fastidious organisation allowed us, nonetheless, to keep a better graphic coherency between all these elements. We gradually integrated the different textures in the scene, coming alive bit by bit. It was then easier to balance and correct the colorimetry and the contrast between elements.

   For the ground’s texture, Sarah had a brilliant idea before she left : using a “splat map”. In fact, the ground’s surface is quite important, and, consequently, we should have to use a texture map with at least a 4096 resolution to cover it. Considering this, and in a matter of map optimisation and working time, we chose a splatting texture. It’s a technique thanks to which we can combine different textures using a splat map. This splat map acts as a “mask”, and determines the zones where the textures must appear.


     We then created 3 different maps : one for the grass, one for the soil, and one for the rocky slabs. They are then smaller, because they appear several times (tiling textures) on the screen as they’re repeated, instead of covering at once the whole surface. We could then limit ourselves to a 512 resolution for these 3 maps.

    nly remains the splat map, allowing us to combine our 3 textures. This map will be a RGBimage, covering the whole surface of the ground, and where each colour represents on of the 3 textures. We took the red (R) for the slabs, blue (B) for the soil, and green (G) for the grass.

    The coloured atmosphere of our arena is now set. We now have to add a little life and some movements in the scene. It’s time for us to get down to the FX, it’s what we’ll see next month!


    These two months were mainly dedicated to integration, finishing touches and debugging in preparation of the early november playtest. All this being not really interesting, we will rather talk about dated things, but are always very useful and good to know.
The editor scripts (utilities) in Unity

    In Unity, it’s possible to add some sort of “extension” to the editor itself. These scripts use the same language than the gameplay scripts, but are only useful to make life easier for those who work on the Unity project and won’t be in the game itself.

   Assets, scripts, prefabs, and others things starting to fill the project, editor scripts become essential to handle, manage, use, and maintain all this. For example, one of the first utility scripts that I made is used to create a miniature for the character’s editor from a prefab of a customisable element.

It is far shorter like this than making it all by hand, and it allows us to see exactly where the element goes

    Another utility that quickly appeared to be essential is the script research in the project’s prefabs, which allows us, paired up with the feature “find references in scene”, to find easily where and why is used each script.

These are the few lines that save me from hours of searching in the hundreds of prefabs

    Other utilities, more discreet, are used, for example, to adjust the import settings of some type of assets, which makes the integration quicker and way more pleasurable. On the whole, these scripts are a significant trick to save time for all the team’s members who are using Unity. They allow us to free ourselves from repetitive and laborious tasks that make us want to stay home !

Physic optimisation of the game servers

    Je ne sais pas si ça a déjà été mentionné, mais la programmation gameplay dans dWARf ne se limite pas à coder le client du jeu (le programme que les joueurs utilisent pour interagir avec le serveur) mais également le serveur de jeu !

C’est bel est bien Alexandre qui s’est occupé de la partie communication client-serveur, mais une grosse partie du gameplay est gérée par le serveur, et ça, c’est à moi de le faire.


    Le serveur étant dit “autoritaire” tout ce qu’il se passe en jeu est d’abord “validé” par le serveur. Par exemple la position des joueurs, leur collision, etc… est gérée par le serveur, ce qui veut dire que la physique d’Unity doit fonctionner sur celui-ci.

Ce fait pose un problème plutôt important : il y a un serveur de jeu qui doit être démarré par partie en cours. Il est donc indispensable que le plus possible de programmes “servea    I don’t know if it has already been mentioned, but the gameplay programmation of dWARf isn’t just about coding the game’s client (the program players use to interact with the server) but also the game server !

It’s indeed Alexandre who took care of the client-server communication part, but a great part of the gameplay is managed by the server, and that falls to me.


    The server being called “authoritative”, everything that happens in-game is firstly “validated” by the server. For example, the position of the players, their collisions, etc, is managed by the server. That means that the Unity’s physic has to work on this server.

This causes a rather important problem : there is a game server that has to be started per current game. It is therefore essential that as many “game-server” programs as possible can be executed concurrently on a single physical server (the devices on which are hosted game servers), and so that a single game server use the least amount of resources possible, for an obvious reason, that is cost, but also for stability.


    The optimisation of Unity’s physic, without re-coding the whole engine, is mostly made along the management of the collisions : the calculation complexity of the collisions depends a lot on the colliders form. Therefore, it is obvious that we can not sensibly use the same scene than for the client with “mesh collider” (which calculates collisions corresponding exactly to the visual of the object) for all the objects modeled by the 3D team.


    Therefore, we need to represent the objects that need to have a collider (and the others) in the most correct way with only primitive forms, but here again, every primitive form aren’t the same.

For example, contrarily to what anyone can think, the cube is not much efficient, because it requires a complex succession of calculation to determine the point of the cube that is the closest to the other object potentially in collision, and determine if they go through each other. The spheres, on the contrary, can seem complex because a spherical 3D object is composed with a multitude of sides, but regarding colliders, detecting a collision between two spheres comes down to simply calculating the distance between them !


    The objective is then to reproduce as closely as possible the game shapes with, in order of priority : spheres, capsules (which calculation comes down to look for the distance of the point the closest to a straight line) and cubes (because sometimes, you don’t have the choice).ur de jeu” puisse être exécutés simultanément sur un seul serveur physique (les machines sur lesquelles sont hébergés les serveurs de jeu) et donc qu’un serveur de jeu utilise le moins de ressources possible, pour une raison évidente de coût, mais aussi de stabilité.


    L’optimisation de la physique d’Unity, sans non plus recoder tout le moteur, se fait surtout dans la gestion des collisions : la complexité des calculs des collisions dépend énormément de la forme des colliders. Du coup, il est évident qu’on ne peut pas raisonnablement utiliser la même scène que pour le client avec des “mesh collider” (qui calcule des collisions correspondantes exactement au visuel de l’objet) pour tous les objets modélisés par l’équipe 3D.


    Du coup, il faut représenter les objets qui doivent avoir un collider (et pas les autres) le plus fidèlement possible avec uniquement des formes primitives, mais là encore, toutes les formes primitives ne se valent pas.

Par exemple, contrairement à ce qu’on pourrait croire, le cube est peu performant car il demande une série de calculs complexe pour établir le point du cube le plus proche de l’autre objet potentiellement en collision et déterminer s’ils se traversent. Les sphères au contraire, peuvent sembler complexe car un objet 3D sphérique est composé d’une multitude de petites faces, mais au niveau des colliders, détecter une collision entre deux sphère revient simplement à calculer la distance entre celles-ci !


    L’objectif est donc de reproduire le plus fidèlement possible les formes du jeu avec en priorité: des sphères, des capsules (dont le calcul revient à chercher la distance du point le plus proche d’une droite) et des cubes (parce que des fois, pas le choix).

At the top, you can see what the client sees. At the bottom, you see colliders on the server side. Yes, it is the same map !

    As you can see, most of the objects can be made up of sphere and capsule shapes, the character’s collider being a capsule, the physical calculations are as simplified as possible ! The only cubes are ground colliders that need to be flat in 2D.


    Nothing really exciting at the moment, but the prototype is taking a good shape and we’re still having as much fun during our intern tests !


    Rework of the dWARf API, rework of the matchmaking API, preparation of the shop’s launch, organisation of the server data collection first “pipelines”, working on the dWARf update system, here is what you’re going to read through the dev part of this month’s blog!

Issues concerning dWARf API

    Concerning dWARf API and thanks to a conversation with Solune, it happened that I really misunderstood a part of the technical specifications : the colour management of players’ equipment. A nearly-complete rework on API’s character managment was then necessary. This work filled most of September.

     The libraries allowing the Unity client to communicate with the aforementioned API also had their respective update. This also allowed me to review a great part of the SQL requests optimisation, which mainly used joints to authorize a quick recovery of the data through foreign keys. I prefered using raw data directly updated in the tables, so I will not have to search in different tables during SQL requests.

     All this gave a great improvement of the equipment recovery performances, as you can see it in the graph below. 

Rework of the Matchmaking architecture

    In a first place, as we needed a simple queue for the matchmaking, I thought of setting it up directly in the matchmaking API. That way, when there is enough players are in the queue to make a group, the API decides to create a group of players and to launch the game by sending an order to the management service, as in the following diagram :

      This architecture had quite a lot of problems : HTTP requests were slowed down (it implied a less good answer time from the API too), a possible desynchronisation of the player status and a difficulty to scale the architecture and avoid weak points, which, instead of slowing a single worker, would slow an entire service.

    Therefore, instead of letting the matchmaking API work alone (which also limited me regarding the specific matchmaking management [which uses algorithms that needed more execution time], I decided to use workers, which change the algorithm in accordance with its needs and are as programmable as can be !

    The creation of a matchmaking then looks like this :

    Therefore, if too many players are in the queue, we only have to increase the number of workers to ensure that the service stays fluid ! Moreover, we can make some workers dedicated to a queue in particular, which saves us even more from traffic jams 🙂

The shop

    Christmas is coming faster and faster, and we planned to launch the shop before Christmas. So I put in place the missing payment systems and improved the payment system management, which are handled by the account management API. The backend is ready to be launched, it’s only waiting for the frontend, which is still in development, but it will come very soon 😉

Collection “Pipelines” and data monitoring

    It’s really important for us to always have an eye on current data, as on their use. To keep a close watch on it and organise alerts in the event of problems, we have to monitor them. In this context, we use Prometheus for the data monitoring. I then created data pipelines that allow us to recover monitoring data directly on all our services.The purpose is to find quickly which endpoint is slow on an API, so we can fix it as quickly as possible.

If an endpoint is slow, it runs the risk of putting in queue other users wanting to access it. It’s really not what we want if we want to guarantee an optimal response time of the API ; it’s then important to monitor it. Other resources were monitored too, as the general use of the servers, or the number of players online 😉

Update system

    Finally, I’ve spent a few weeks working on the system that allows dWARf to stay updated, simply.

   This system is a simple updater service, allowing the production of data “packages” which create an update that can directly be exported in production, as well as the system on the client side allowing the download of different data.

    For this, 2 systems have been developed concurrently : the “packager” system, allowing the creation of update packages and the “updater” system, allowing the game update on the client.

The packager allows the creation of a file that gathers all the important information to recover the updates and even contains an option allowing the compression of the files so the players will spend less time downloading.

The updater is more classic : it downloads the versions file, compare it with files version, updates if needed, extracts if needed.

Une version MacOS et Linux sont aussi en cours de développement.

    It’s quite a busy period concerning multiplayer. Lots of optimisations were made, quite a few features were added, an update system is functioning ; I only have to wait until the arrival of the sysadmin to start putting all these implementation processes in production !