I want to talk to you about inspiration. This is an underlying concern for any artist, be it novice or senior, salaried or self-employed.
The first problem I encounter is saturation. Today we are surrounded by images, especially when browsing the internet. It’s a chance, but also an endless spiral. It let me with the feeling that everything has been done, and seeing so much talent can become paralyzing, vain.
The other problem I encounter is picking references from flat images, or similar media. I include Artbooks, although we can touch them. It’s getting boring. So, I get used to look at the world around me.
And I do not mean to scrutinize as to draw from observation (which is rather to practice and improve technically), but to observe the details. It allows me to feed my visual vocabulary but especially to consider using details observed independently in a context detached from its place of origin. In the same way, to look at an aspect of an object (shape, proportion, colors, texture …) without paying attention to its functionality can inspire us in a precise subject that we would have to realize (a good example: the form of tools that inspire Eric Geusz‘s ships ).
To bring together elements that have nothing to do with each other gives me the impression of approaching “creativity”. We must remain curious, in life as in work, to feed our artistic activities.
Concretely, I have the reflex to take pictures of elements that could be useful to me – if I do not have the opportunity to sketch them. These are not quality photos, but sparkes for thoughts, ideas to apply to different topics.
A small selection of my own photos:
At the end of January, we launch the first pre-alpha. The temporary menus are ready on the dev side, just like the launcher. It’s time to update all that to make people want to discover more !
Let’s rethink the UI (user interface), and move away from the idea of it ??being very flat (>see the febuary 2017 blog). My goal is to give a little depth to the menus.
I was still in Alsace a few days before, and the architecture had not left me indifferent. So I went back to my photos to extract shapes and textures. While drawing in architectural elements, I do not deviate so much from the basic functionality, decorative, but I detach somewhat the element from its context. Here are some searches, including what you may have observed during the opening of the servers.
And as sometimes we can remember a detail that may interest us, do not forget the teleportation, aka Google street view.
For the research phase concerning the upcoming arena (Arès), I used it to look at a resolutely typical and old building in some downtown, which could correspond to the type of atmosphere that I imagined. Another time, I wanted to find a building whose architecture had intrigued me, in a train launched at some 280km / h. As I quickly noted an information to locate it – a barracks with the name written in huge, easy – I only had to go up the railway on Maps.
In short, if you are on the look for a similar career, do not be surprised to stop at each winding tree, each original architecture, each harmonious twig, each contrasting sky … and to navigate through google map to find this beautiful rock that you had crossed at the edge of a highway.
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 !
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 !
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.
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
– (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!
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.
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.
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 !
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).
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!
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.
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 🙂
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 😉
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 😉
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.
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 !
During the summer months, much of my work consisted in preparing some little surprises for this autumn and managing the started project with enthusiasm and good mood. I’ve put myself more in a manager’s shoes and I’ve made more solution and validation than creation.
Much of my work was dedicated to the setup of tools of community communication, starting with a community roadmap. It seemed important to give people an overview of the progress of the project for those who don’t have the time (or the energy, or the wish) to read the poetic blogs we prepare every other month. Audrey, a multitask person like me, first began to think about ideas to purpose a map that summarised the advances. A map that will be updated each time there is a major progress.
We’ve also prepared a little nugget for the end of October, we don’t tell you more about it but we’re looking forward to seeing your first impressions.
One of my hats is a “human resources” hat, the team was growing at the return from the summer holidays and we were going to recruit in several fields. In total, 4 persons will join us between late August and early November, in 3D, cloud and communication.
Recruitment period are always really stressful, I need to work fast while being careful not to make an error about collaborators with whom we will have to compose. The more the team grows, the bigger the constraints are, integrating oneself with 3 persons starting a studio is always easier than integrating oneself in a group of 10 who’ve been working together for a year. It’s also a lot of operational work, organisation, ordering and taking notes. A job that doesn’t overjoy me much, as it’s a repetitive and, paradoxically, not a very human work.
If the job interviews are my favourite part in HR, they’re also the part that turns the working rhythm upside down.
This period is over (for now), we don’t recruit anyone before a long time et I’m not unhappy to leave this all behind me and welcome in the team Lucie (3D), Adrian (3D), Johan (Cloud Admin Sys) and Flora (Community Management). The office is getting filled and the atmosphere is all better !
Once the project started, remain… everything that remains. Validation, problems, solutions, precisions. My summer objective was to re-motivate the troops in particular, to progress as much as possible with the mid-term vision to bring everyone’s perspectives out (and see our tasks further than one or two weeks).
I understand that, for you, supervision is less glamorous than creativity, but for me, the “human” is a really passionate part of my work. I’m each day more impressed by my collaborators, their way of seeing things and their creativity. I’m really happy to lead a team in which I’m confident in for pointing out problems and offering me solutions.
During these months, I made a bit more of the variety of things I have to produce, and it was really not unpleasant !
As aforesaid by Diabalzane, we wanted to make a community road map. I didn’t find a lot of references, what motivated me to explore non-conventional trails, even quite shifted from the few 2D elements made so far. We’ll speak about graphic consistency later, when we’ll have a global overview of dWARf.
I inspired myself with 4-5 trails and restrained myself from finishing them all to optimise my time. Yes, I’ll have to live with the doubt of neglecting a trail potentially better. I submitted them to the team and some changes were made.
For Dionysos’ needs, we started to think about the next arena : Poséidon. The pedalo sketched by Solune needed a relooking. It was the opportunity to explore this “quack-quack” fauna; I tested different shapes, and different levels of realism. I simplified their head with some lines that had to be legible in volume.
I wavered between profile researches (rather to give an appearance) or three quartered ones (rather to give an idea of the spatial influence). Finally, it was the most expressive profilesilhouette that convinced us. Little wings, long neck with a rather high head that will brush past the embarked dwarf’s head.
To leave nothing to chance, I thought about a propulsion system somehow ridiculous with rotating legs. I imagined the webbed feet going out and “crawling” on water in little splashes. Ah, I think toys that represent the idea exist, look !
Now imagine the presence… It’s quite the idea!
Then, having taken a step back, we realised that a more manufactured beer source, as a little altar, would be more judicious. I also draw the much-vaunted magic mug which will transport the gentle liquid, whose final version will be a mix of 2 proposals.
Every moment was the good moment to better organise ourselves. So we didn’t avoid a bit of methodology with our quality producer. The files’ nomenclature and their organisation started to show their limitations. We started again on a sound basis, I took the time to re-organise my hard disks – without losing any data !
Even if, at Unexpected, we always want to share most of our work, some ideas have to stay little surprises. One of them already needed a good part of the summer dedicated to it. This time, it’s essentially my work that will be put in the spotlight, so I’m really anxious. #pressure #responsibility
Early in the summer, we’ve made the last playtest of Héphaïstos, and validated the map. It was time to go on the new map ! We had to start from scratch to create a new scene in which dwarves will fight each other. Not to repeat the same mistakes made on Héphaïstos, we decided to review the pipeline and reorganise the way we work.
For a same arena, we work on 3 different scenes at the same time:
The first is the prototype scene, it’s the prototype of the arena containing all the scripts. It’s a playable version, but it does not have any graphic element, it only has simple shapes created by Solune in Unity.
The second scene is the Block Out : every graphic element is there schematically (simple shapes) but allowing us to realise scales and distance of the objects before their final version (see work of Héphaïstos Block Out of March’s blog.
Finally, the third scene is the final scene, in which we import little by little the final 3D elements as soon as they’re created.
We were many to work on these Unity scenes. We therefore decided to create prefabs (instantiated objects) for each object present in the scene (3D objects, scripts, FX, etc…). Yes but, what’s exactly the point of using prefabs ?
When a change is made on a prefab, this change is made consequently on any instantiated object, wherever it is. So when Solune makes a modification on a script prefab from scene 1 (for example, for the UI), this correction is applied automatically on every other scene. This way, every scene has the latest versions of every object, updated with the last changes made. Also, our new arena was filled with many plant elements. We therefore had to create different plants, but each one copied multiple times in the scenery.
For this same plant, we simply use the same object, but if we duplicate it to place it elsewhere in the scene, it causes a problem : these two plants will have different properties, and a change on one will have no effect on the other. It simply is a duplicate of this plant, changeable independently from the other. Or, as they are the same plant, we want them to keep the same properties (scale, material, etc.). So we made a prefab of this plant and every change made on it was applied on all the instances. Therefore, we didn’t have to reproduce the same correction on each copy of the object. However, if needed, it was still possible to edit independently the instances created from this prefab.
Once we’re used to the process, we started creating the 2nd arena : Dionysos. As for Héphaïstos, we started with a Block Out. Then we modeled 3D objects one by one, integrating them in our 3rd scene as and when. So, at the end of the summer, final objects were almost all in the scene, and we could start texturing : adding a bit of colour in this environment !
A little more complex on the other hand, the friends management required bug fixes and coordination between our two mates concerning the bugs raise.
Major problems were raised, both at the level of API and the Libs allowing interactions with them. It was mainly thanks to a pre-prod that we were able to test all services in a fully connected way.
First, a change of the synchronisation protocol and notifications sending had simply broken everything. It required a week of heavy debugging to be able to repair any residual problem.
Similarly, on the Libs side, several problems of functioning were noted and fixed.
The objective was mainly to put all this in real conditions, to check that everything worked and that all the functionalities were present (and while I was at it, starting the implementation).
For this, a simple UI and quite a lot of code to deal with all the necessary information and their display, the hardest being to ensure that every “real” information, memorised information and displayed information were always synchronised :
After 3 months of work, we finally had what we wanted : a game client that supported the connection of the account, the friends management and the chat between friends!
Confrontations with “exterior” reviews, delays in 3D production, a new concept of arena, game design, visual feedback, improvement for Héphaïstos’ gameplay and the arrival of a new prototype : Dionysos, were the main events of this month of June, and we’re looking forward to share all this in detail in this new blog !
– The Manitou’s visit
The boss came to test the very last build of Héphaïstos… No pressure. NO PRESSURE. EVERYBODY STAYS CALM. The exterior review was here, it was a crucial step for us, we’ve had our heads plunged into Héphaïstos gameplay, 3D and game design for 3 months and it was really hard for us to form our own opinion on our work. The 3D team panicked and realised how late they were. Luckily for them, the tester wasn’t here to look at graphics but at pure gameplay, playing sensations and concept.
Some brief explanations of the game’s concept, some games, the handling seemed quite easy, players understood what they had to do and how.
Many issues became however blindingly obvious, zones were unclear, the lack of visual feedback caused many failures of understanding, the UI was too discreet and didn’t enable quick decisions, some clicks were naturally more directed towards UI elements than towards 3D elements… These were a lot of indications that allowed us to set up a new planning for further adjustments. Globally, feedback was really positive. Adrien was surprised by the qualitative visual rendering, he liked the concept of the game. The most helpful feedback related to the end of the game, which was a bit “confusing” and boring for the player, and the delimitation of the action zones.
– Héphaïstos’ revision
We then started a month lasting period on the gameplay update : the invention of a new mechanic for the end of the game which needed to be written, the graphic conceptualisation and polishing. On their side, the 3D team had a lot on their plate, they had to texturise many assets and create animations.
To motivate the 3D Team, some of the excel tables went from dematerialised to “wall + sticky notes”.
In order to give a better definition to the zones where players have to remain to make their craft bar fill up and to highlight the fact that you can “push” your opponents, we chose to change the slabs. They until now were used to show the player where to go. We’ve changed them into progression zones, from which everyone can be kicked out easier, and offer a better legibility of the arena.
> Slab Capture
For the new mechanic, Solune (our gameplay programmer) and I began to wonder if there were ways to ensure that the player didn’t get bored in the last seconds of the arena during which they couldn’t start a new object. We wanted a mechanic that could allow the last player to fight for ranks and the first players to fight for their place in the ranking. Many ideas showed up, including an idea of a great duck hunting in the forge that will even become a fully-fledged game mode, I’ll speak about it right after !
Finally, we opted for a zone capture and resistance, giving a deeper meaning to the dash mechanic in this arena in particular. We decided to schedule a new test for July, once the full game mode is textured and animated. A deadline once again, and this time, the 3D team was much awaited !
– New game modes
Poséidon and Apollon made their first appearance in our minds during a meeting fully dedicated to the creation of game modes consistent with our universe. Let me just remind you that those are only code names, and that, in reality, there’s no link between greek mythology and dWARf.
Poséidon came up when we were trying to find a mechanic for the end of Héphaïstos. As we get overjoyed by a duck-hunting, which was absolutely incoherent with the very principle of a forge, and as we went deeper and deeper into the complexity of the mechanics, we decided to keep all of our ideas and to use them in due course. The due course had arrived, and this is how we drew a new game mode. We don’t tell you much about it now, but the mode is the upcoming after Dionysos, the Lake in the upper-right of the image ? In fact, a duck pond 😉
We also developed during this meeting an idea of mini-mode inspired of “Grandmother’s footsteps” and musical chairs. All this came to fill an already loaded Game Design Document and we decided to prototype directly these ideas to know straightaway if these modes were viable instead of keeping them before giving it a serious interest.
Everyone ended up with a lot of work, and I couldn’t believe that the month of June has passed so quickly !
Let me check my notes ; I feel like I haven’t touched Dionysos for a little eternity ! I made several proposals on visual feedback, which we shared with you on Twitter and Facebook to evaluate the general feeling, and noted some relevants reflections !
For the loss of beer doses, only the direction of the animation can mean different actions (violence, fall, impact…). Its realism can influence its legibility and its harmony. Its space hold and the length of time can influence its importance. But this also depends on the moment where the animation appears (a thing that is already defined a priori), and on the fact that other effects can accompany it (flashing of the doses bar, sound effect, global effect on the screen…).
I also made some messy animations for the teleport, working on the shape, the effect, and the time necessary to develop it.
I worked back on Héphaïstos to draw a zone ready to receive the new mechanic. The central cross not having a defined visual, I took advantage of it to harmonise the whole. Editing the concept art in the build under construction rocked ! But drawing over anything would imply the 3D team to modify it all, and in way longer than I draw; I restrained my ardours, it was not the purpose !
New mission: the FX, which I realize with Sarah supervision. Let’s recap: a jet of steam escaping from the pipe, maps of lava to adapt, still images of steam that she animates on the cooling tank, and an animation of flame that she updates with sparks and smoke! This is the first time I have created such FX, and I admire how 3D artists incrust and adjust my work !
As my colleagues merged their brains and imagine new arenas, I was assigned to work on Hadès. I’ve had for a moment very few game design information and I spent my time gleaning references and sketching some researches… with a pencil ! It’s crucial to grant yourself such a madness when you’re working full-time on a computer!
JI indeed reached an agreement with Lauriane concerning the arena’s atmosphere and the basic ideas that will lead me. Ideally, these strong ideas will be unchanging, irrespective of possible evolutions of the arena. Aka, we made a mood board!
Finally, a construction logic of the level was decided, and ► I adapted my researches to the in-game camera angle that Solune gave me. I traced some lines of construction to make the perspective visible and therefore drew the elements as they will be seen. (I’d say that my distant lesson on projective geometry helped, but I’m not even sure). I could then visualise the passages where the player could misinterpret the way. But I had to remember that the perspective, which unthreads and deforms the overview of the elements, can hide some others and disturbs the players; it’s tricky.
This month purpose was to come once and for all to the end of the map of Héphaïstos. There were some textures to finish, and once every model integrated in the game engine, I could re-work the scene : replacing some elements, and peopling the scene with little objects placed here and there, to give a little life to our environment.
Then, for the scene not to be too static, I needed to animate some elements of the scenery : for example, the bellow that fuels the oven, and the moulds that open and close. Audrey and Sarah also worked on some FX (Digital effects) that will be integrated : the lava that flows, the torches’ flames, some smoke… Solune also had to configure the materials so the runes shine at specific moments. And thus the forge came to life !
Finally, I needed to animate the characters. The dwarves will have to move in the environment, craft objects, wear them, etc… On the other hand, the player will be able to craft very different objects (crown, shield, fork…). The character will then have an attitude depending on the object they hold. For example, they will hold the crown with their two hands above their head, the fork with two hands in front of them, the shield on their left arm… It was then necessary to make different animations for the dwarves’ movement according to the object they are holding in their hands. It’s the same for the dash and the character’s idle.
Once all the animations done, Solune could import them in the game engine.
That way, dwarves can move in this environment, interact with the scenery, and we finally had a functional map.
We could finally bring Héphaïstos production to a close (almost really closed), and start the new map ! Phew!
In Unity and in programming in general, the generic programming (making a code that can be used in as many cases as possible) is a very important notion to save time and stay efficient.
dWARf isn’t an exception, quite the reverse as there are mini-games, it was therefore important to ensure that as many scripts as possible could be reused from a game to another, for example the controls.
Even if the controls were not exactly the same from a game to another, the generic programming of these scripts allowed us to reuse them in any case, requiring only a few changes in the configuration, which was made really simple by Unity with the “inspector” (what you see above).
These generic scripts had to function with other generic scripts, as well as with specific scripts, which managed what is never in another game than theirs. For example, “DwarfInputScript” received user inputs and transmitted them to the scripts that had ‘signed up’ to these inputs.
With the gameplay of our first game done, a great part of the “generic” scripts (which will be used in every game) were functioning and approved, as well as the movement, the interaction with objects, etc.
These generic bricks allowed me to quickly prototype next games and thus validate their gameplay, and organise a first “level design”, either from an Audrey’s concept, or even before any graphic work was made on it.
► The prototype of Dionysos was then ready to be tested, and to welcome 3D elements as soon as Héphaïstos was graphically validated !
Poseidon is moving ahead step by s… pedal stroke?
Respecting deadlines, making the best rendering possible, getting out of the prototype, refining, working, re-working, creating an atmosphere, and finally, fi-ni-shing.
April / May was for us the baptism of fire. Our objective ? Finishing from A to Y (without the sound design) the first arena of dWARf to get people outside of the studio test the playability and get feedback on taking the game in hand, graphics, atmosphere and arena’s principle.
The pressure was at its maximum and, with the return of sunny days, motivation was often shaken by the desire to go for a nap in a park or have a drink on a terrace in a small pedestrian square of Montpellier.
All this explains our lateness on these blogs and our absence on social networks, although we tried to make up for it with Audrey’s stream at mid-May. We also prepared other small surprises in terms of video to immerse you in the heart of dWARf’s creation.
I had to be completely multitask again : game design, graphic approval, technical documents…
One of the major task was the revision of the controls with Solune. Something was wrong and it had been really hard to put a finger on it. Giving the desired sensation required us to inspire ourselves by many references and to play games (in a purely professional way, obviously) whose controls could suit dWARf (and all its game modes). It was no mean feat because we wanted to keep a certain harmony (all games having the same controls for the same types of actions) so the player doesn’t have to learn again how to play for each arena. On the other side, we had the task to make up controls that allowed the player to enjoy each mode intuitively.
Solune will explain this with more details, but after researches which were confirmed afterwards by the tests, we decided to offer 3 modes of controls (mouse, keyboard, and game controller) to the players. These modes are interchangeable at any time so the players can adapt the way they play with the mode that best corresponds to them.
For the creation of the controls, here is the list of the games we had tested and analysed to better understand the mechanics we could then add to dWARf. Some of these games allowed us to confirm that some things weren’t possible for dWARf, and other games gave us good ideas. The list is probably not exhaustive as we relied heavily on our personal knowledge.
– Full Mojo Rampage
– Hotline Miami
– League of Legends
– Mages of Mystralia
– Diablo III
– LEVEL DESIGN WITH PLAY DOH
Early in April, at Unexpected, there was a meeting on level design. Note that, in a first place, in our company, no one is level designer and it’s a step of the construction of dWARf’s arenas that doesn’t appeal much to me (and yet is my onus).
While I was trying to draw on paper my first ideas of the conception of the arena, I was quite annoyed to have to erase elements to transform them, at the risk of making holes in my sheet of paper.
I thought I might use a software as Photoshop but I instantly estimated how difficult the task was : renaming each layer “rock001”, losing time drawing shapes never fully satisfying and having to present to my collaborators the result in front of a computer’s screen towards which they would point their fingers “can’t we move this element of 1 mm ?” “and this one should have more of a fox shape with big eyes and littles ears”… In short : it would be a plague.
I then went to seek for my team’s help. Audrey quickly proposed to “cut” shapes in paper and to place them. The idea was instantly good to me, everyone could move elements where they thought it was the most appropriate, and we could even introduce a colour notion (grey elements wouldn’t move, red ones would randomly move etc…). Yet, the shape problem remained : how to give a new shape to an object already cut in paper ? How to increase its size ? We would have to re-cut a new shape every time… Could there not have been something that could be at once modified, moved, and coloured ?
Thus I had introduced the playdough in the interactive process of creation. As you understood, I love participation. I love when everyone can play a part and I’m stimulated by, and really enjoy, working as a group.
Everything in this experience was positive :
1) We all fell back into childhood : as soon as we opened the first box, the smell of the playdough took me in a journey in the past. To me, everything in playdough is positive, it’s playful, funny and infinite. It pleased everyone to smell the dough and to play with it. And you have to admit that it is quite de-stressing !
2) Everyone could make himself understandable easily : the frustration ensuing from not being able to show what comes to your mind at a given moment didn’t occur a single time. You propose something that others have troubles imagining ? You just have to shape playdough with the good colour and place it on the table to make it clear for everyone. You can make the shape change, make it as thick as you want and everyone can then change it or suggest modifications.
3) We saved time : not having to go from the drawings of ones, the long texts of others, and the incomprehensible conversations made us save a considerable time. There was no need to ask “but, it will block here, won’t it?” and wait for tries and returns. The instantness of the reality is surprising !
Convincing result : at the end, we found ourself with something convincing and structured with colour codes, and we made sure that a lot of elements functioned. We even had new ideas immediately testable ! Some pictures and we could transfer it all in Level Design’s folders to leave the hand to the artists !
Conclusion : A good team time, far from boredom and complicated ; as children around a table, we made participation a non-frustrating moment where everyone was able to make themselves understood and understand others, appreciating anyone’s idea immediately.
Members of the team who didn’t participated and went to see the work done enjoyed being able to see the elements moving, as an anytime modifiable and convertible mockup.
Thanks Play Doh !
In a first place, I had to confirm the design of ingredients, which will be in 2D. Alloy or ore, the list of the ingredients progressed. Each one must be recognisable (or at least distinguishable); therefore, when you think iron, steel, silver or mithril, you have to play with colours (a little rust on iron, some contrast on iron, a light grey for silver, and re-inventing a grooved turquoise mithril), and the shapes (not only ingots).
The design of the objects changed too, but should be visible only in 3D. I simplified the crown to avoid ambiguity (not to mistake it with a big ring), the pickaxe became offensive (a pickaxe is badass)…
For the UI itself, I first made a mock-up : I scribbled elements where they had to be.
We realised that the idea of a ranking at the bottom right was bad. The eye would be forced to go back and forth between the action and this information, and then to analyse where are the players whom they should keep an eye on strategically. The arena lasts a few minutes, you therefore don’t have time to lose searching for information. A way simpler solution : writing right above the head of the dwarves the ranking number. It seems obvious when you have the benefit of hindsight, it’s true!
There is also the recipes’ interface that must deliver several information.
For their analyse time to be as a drop in a gameplay ocean (I’m a poet in my spare time, indeed), their reading must be ordered :
– What is the demand of recipes ? > strategic aspect
– How to realise them ? > informational aspect for the general gameplay
– What objects are then crafted ? > storytelling aspect
Then, I made various proposals to get round as many problems as possible : Takes too much space > doesn’t stand out from the background > too shifted from the sober and flat style of the lobby > unreadable request at a glance > lack of balance… until reaching one or two design solutions (practical and pleasant if possible).
The 2 level bars (the craft bar on the player and the refiner bar at the top right) must have a similar design via the same colour and a trapezoidal shape. The little “ + “ has an asterisk function that is supposed to make the player understand that both bars are complementary.
This arena required a new scenery, a new atmosphere.
We shared our level design ideas while playing with playdough (I swear it’s pure happiness). Inevitably, I already thought of what elements could look like. We wanted to put only natural elements (no mechanism or manufactured objects), they therefore proposed me a floating nenuphar so the mobile zone we wanted to integrate would be a passage. Further away, the mobile zone would be an obstacle; it could be a stump. In brief, the arena came alive, making more and more sense. “You’re smarter with your hands” (French’s slogan of Play-Doh, ed.) = true story..
I let Lauriane transmit me the reference images to be sure we were on the same wavelength. Basically : an underground cave, a phosphorescent wood. Fairy grove, shiny creatures, wet and magical area.
I spent a few days drawing varied vegetables in different styles to adapt them to the work previously made. As a junior concept artist, I immersed myself with a new visual vocabulary : the flora ! This research work was essential because educative, even if time limited me in studying every possible and thinkable vegetable shape (A French forest is not the same than a Laos one) ! But it’s by studying little by little than I can hope someday being able to… take over the world ! (citation of “Pinky and the Brain”, ed.)
Finally, it was time to select those which seemed to best correspond to the wanted environment. No exotic, alien, spiky, polished plants. No conifer, nor too tortuous trees. I settled for 2 types of trees, 1 type of bush slightly different, one type of dead trunk, 3 flowers, 4 mushrooms (sponges, toilet paper and 25cl of crème fraîche).
As our screen covered an area of modest size, the ecosystem had to be harmonious
Another important point : I often checked if my work, which I made directly in colour (unlike Hephaïstos process) was enough contrasted once in black and white.
After March’s block-out, it was time to produce every environment object in 3D and replace them one by one in our previous scene.
To do so, we had to model every building and every element of the scenery. It went from main buildings (anvil, oven, refinery…) to elements which will structure the scenery (rocks, ground slabs, walls…), by way of all the little objects that coat our scenery (pliers, hammers, torches, standards…).
The challenge, when it comes to creating an environment in 3D, is to produce the objects with the fewest polygons possible. At the end, we want our objects to have as few sides as possible.
Indeed, in a 3D environment, we often find ourselves duplicating objects of the scenery to occupy the place (vegetation, rocks, buildings…). A scenery object not as low-poly as possible is more likely to cost a lot in terms of performance, not only once but as many times as the object is duplicated. We therefore had to avoid most of the useless points (vertices) in the 3D modeling, without sacrificing the general aspect of the object. We had to find a good compromise between performance and aesthetic.
For the production of an object, we went through several steps :
First, I made a 3D template, with simple shapes, but already on the right scale. I then used it to sculpt my “high poly” : it’s a model that contains a lot of polygons (sometimes even millions !), but that is very detailed. I could allow myself to sculpt every detail, even the smallest nut ! Because after this, I then proceed to work on re-topology : From my high poly shape, I drew a model with the fewest polygons possible, while trying to stay the closest to the general shape of the object. During this step, we started with a model composed of several hundred of thousand polygons, and ended with our final model (100-600 polygons in general).
It’s during the texturing step that I will get all the previously sculptured details back : the baking texture is a process that enables the transfer of a model details to another. We can then get our high poly details back, make them appear on our low poly texture, and give the illusion that our model is way more detailed than it really is. In addition to every little sculpt detail, we then added colour, materials texture and a few shadows to the object.
We could then import it in the scene, replacing the basic shape that was placed for the block out.
That way, the scene is built little by little, and we can see it evolve practically from day to day. Even if when this blog is published, there are still some elements to refine, the scenery of Héphaïstos is coming closer and closer to its final version.
These last two months were dedicated to the finalisation of the most complete playable prototype of Héphaïstos. This task implied to focus on issues so far put on a sideline because not priority, as it happened the controls and gameplay final touches.
dWARf’s controls were, at the beginning, similar to Overcooked’s, a game which was a part of our inspirations, more by a lack of will to address the issue than by an informed and stationary choice.
Contrary to Overcooked, dWARf is not only composed with cubic elements, narrow passages does not have a direction following cardinal directions, nor the eight possible directions with keyboard arrows (or WASD), which happens to be really unpleasant for some people.
dWARf needing, in general, the mouse to aim / attack, the interaction and dash key had to be on the hand handling the movement, which did not pose a problem for the dash (space key), but the interaction key forced the player to move one of their finger from a movement key ; once again, some players dislike this.
After thinking about it, we wanted to test controls inspired by ARPG (movement and interaction with the mouse) and those who disliked the previous controls instantly liked these ones ! On the other hand, some still prefered the old ones… We then simply chose to let players the choice between 3 modes of controls, of which, moreover, every bind is configurable.
– A WASD mode, probably more adapted to FPS players and used to this type of movement
– An ARPG mode, suitable for RTS, Hack & Slash, LoL players, and probably to beginners
– A Game Controller mode, for the regulars !
Obviously, these controls are subject to change, depending on user feedback. It’s also possible to add more, with the purpose that irrespective of your level and the games you play, you find intuitive controls with which you’re at ease !
Héphaïstos game design was fixed since a long time already, but some things required tests before being defined. Is the game enough intuitive ? Isn’t it too short ? Can gameplay ergonomy be better?
The objective was to find all these questions, answer them, and make the gameplay better if needed. Obviously, it was not possible to fix everything at that stage, but each point tested doesn’t have to be reviewed by testers, and therefore gives a greater accuracy for the remaining remarks.
It was, for example, important to have at least a visual feedback basis so the remark isn’t “the game needs visual feedback” but “it would be great to have one more visual feedback here, and there, when we do this”, which would help us way more !
Overall, Héphaïstos is close to its “final” version, and it’s very encouraging !
Ah, the month of April ! The month of jokes, of spring… and matchmaking. Concerning multiplayer, this month was filled with diagrams, debugs, and setting up solutions for matchmaking.
As several services were already done, I started tackling the most annoying issues, but also the most interesting to handle : the management of synchronisation. To make it simple, it is knowing, on all services, if a player is connected, sending them messages (even if they are on several platforms at the same time), being able to make him interact on the less used service, etc…
These were indeed very important problems to deal with, especially because we work with mini-services (and not micro-services, even if a division will probably be done to allow a better distribution of the load and a more adapted network route). So this month was mainly based on the preparation of the matchmaking service (with only the matchmaking option automatised), the synchronisation of the latter with its side nodes, and the process allowing us to choose a server depending on its use for the games’ creation. I would have loved to tell you more about this, but it’s classified, so shush 😉 .
May, meanwhile, was filled with debugs and a focus on management service of the games. This service is the service that launches instances of the games (to allow players to join them and be able to play), as the management of the aforementioned instances. The goal is to monitor, communicate and recover important data during the game (player scores, duration of the game, game information, etc…). This service is also in charge of communicating with the rest of the services to allow the players to get their rewards at the end of a game.
Finally, I set up a double-authentication system (a bit like Blizzard with their Authenticator), that can be enabled or disabled by the user, according to their wish. It’s based on the TOTP algorithm, which is itself used by several companies to offer 2FA as Google, Blizzard, or even Microsoft.
Thereby, these months were filled rather technically than productively on the multiplayer side. The focus was mainly on the monitoring of user connectivity and security of services rather than on the advancement and creation of new services.
What a wonderful experience to meet you at “Lyon eSport” ! The whole team joins me in thanking you for your presence, for your questions and for your support. After a long day spent discussing and testing, you created more than two hundred different dwarves !
We didn’t expect so many participants and we didn’t even plan to present the studio (before presenting the game) to uninitiated visitors who didn’t know us neither from ZeratoR nor from Internet’s depths. But it was very interesting for us to chat with people outside the community of Unexpected.
And that was only the beginning of one of the busiest months !
Overall, this month was dedicated to game design, test and improvement. After “Lyon eSport”, we had a good idea of the team’s dynamic and of what we were able to produce. Better than that, we welcomed a new recruit, Sarah, who joined the 3D team as a student for 6 months.
We got back to game design and gameplay on dWARf. We set aside the dwarf editor, fully aesthetic functionality, to focus on setting up a new prototype whose code name is Héphaïstos. Actually, after a first prototype on one of dWARf’s game arena (code Dionysos), we realised we prefered become aware as fast as possible of the diversity of the game arenas.
Everyone then met to review Hephaïstos’ game-design. It was pleasant to restart on game-design, level-design and scoring. It’s certainly my favourite part of the general process. At Unexpected, each one’s opinion is taken into account and meetings are a nice moment of sharing.
Working on a prototype’s prerequisites is a bit tricky. Most of the time, at the end of a meeting, I’m very satisfied with what was decided, yet I know everything is going to change to fit our gameplay criteria. The game will be too basic, too simple, too short or too hard to handle. During the tests, we realised that some movements didn’t accurately transpose what we wanted, that the camera wasn’t placed optimally and that the gameplay was insipid. The latters make our job an experience every time more incredible : questioning ourselves, testing, modifying, discussing.
On the process side, I finally had the opportunity to refine plannings and prepare more specific documents. Working back on the game gave me a better understanding of what the team expected of me (the dwarf’s editor was documented for a long time, and our schedule stopping at Lyon eSport, I didn’t have to work on these production’s aspects for a while). There were a lot of adjustments to make as Héphaïstos wasn’t the arena we were supposed to begin with.
For the communication (I’m sorry I speak about so many different things, I’m a multi-task person), Audrey made the second stream of Unexpected Twitch channel pour présenter ses recherches autour du concept de Hephaïstos, elle vous montrera très certainement le résultat dans la suite du blog ;).
On this, I leave the sequel to the wonderful people who make up Unexpected’s production team. They will probably have more “visual” things to show you ! Don’t forget to tell us what you appreciated in these blogs by commenting here or on social networks !
For Lyon eSport, we planned to have a personalised t-shirt so the team could be recognisablee.
– I took advantage of the opportunity to work on a fit to be seen logo, even if we didn’t plan to work on it so early. The logo’s silhouette -the letter’s cutting- had to be legible on a few centimeters. It had to work or adapt on a white background as on a black one. Liam quickly had the idea to create a symmetry between the “d” and the “f”, as if the same shape was reworked.
– Concerning our alter-ego dwarves, I gathered every member of the team desires to get me started. T-shirts had to be sent to the printer one week before, so I quickly turned to an illustrative style, with contour lines that imitated a slightly dry brush and a messy, watercolour colourisation. (Kyle T Webster’s brush).
I also had a few details to finish : the mail sending interface and a maximum of eyes for the editor. After selecting, we realised that it would be interesting to choose a pair of eyes AND their emotions… stay tuned about this !
And finally, Lyon eSport ! I already attended eSport competitions, but I didn’t really know what to expect from this one ; what place would have the studio within such event. But plenty of you approached us, which was amazing, and we adjusted our speech little by little; it was a good exercise !
It was a very good team experience (the car ride under the rain listening to the good songs of our teenage years, seeing PSG’s lineup playing, attending our first cosplay contest) : ex-ce-llentt !
Since then, I started working on Héphaïstos’ concept art ! It was the occasion to share a little about my work on Unexpected’s stream. You made my-very-first-stream-ever a very pleasant moment ! I now know that the creation phase is not the perfect part to stream though. Thinking/deciding does not go with answering your questions. I have to organise myself better to offer you a funnier step to watch live !
oncerning creation, gameplay and some visual choices led to bloody constraints. It was therefore more logical to draw objects directly in the perspective under which they would be observed. But this process didn’t convince me totally, maybe I will realise key elements from more frontal angles afterwards.
Whatever it be, I didn’t find any interest imitating the eponymous dwarf forges, full of things. I had a very different approach of Héphaïstos than of the Tavern, rather focused on objects : I wanted to favour atmosphere, contrasts, coherency. I’ve spent more time searching for references, achieving researches (environment, minerals, typical architectures, colour keys…), and trying my hand on textures to be impregnated by this universe which I slightly explored hitherto.
I have to admit that when I think “coherency”, I think of “Beechwood Bunny Tales” >
(or the research work that leads to the “Lord of the Rings” screen that bonus editions or magazines learnt me by 2001, but that’s less class !). The idea : finding peculiar shapes in the architecture and in the objects of the environment (beveled edges, juxtapositions of sharp edges, aesthetic edge for me).
For “Lyon Esport”, we decided to set aside some features of dWARf’s editor. But once the event was over, we had to work on various problems : optimisation of maps and customisation of colours.
Actually, we want the players to be able to choose the colour of certain of their dwarf’s clothes and accessories. On the other hand, for optimisation matters, it is necessary to load only one map of texture per object, whatever its color, and not one per colour, which would be too heavy. Moreover, only a small part of the object will change colour, and not the whole object. We finally decided to put each “tintable” information in the same alpha channel of the image. In other words, it was the same image as the texture itself, but it included in addition a “mask” determining the colour changing area.
On top of this, we wanted dwarves’ hairiness (eyebrows, mustaches, beards, hair) to be dyed in any color according to the player’s choice. But some assets contained elements that should not take the color of the hair : for example, knots in the hair or jewelry in the beard. Also, these elements could potentially be dyeable too, and the alpha channel of the image was already dedicated to this information. We wanted to avoid loading a second map for the same element, because, for the same reasons, it mustn’t “cost” too much during the loading, and the game/editor must run smoothly.
We finally decided to use the colour vertex. Therefore, the vertices (=points) of the 3D model itself (a beard, for example) will contain the information “dyeable” or “non-dyeable”.
So on some objects (for example, a haircut with ribbons), the player can change independently from each other the colour of the hair and of the ribbons, while only one texture map is loaded in the editor.
We could then go on the creation of our first game scenery : Hephaïstos project.
Audrey made a lot of environment researches, and finally gave me an overall concept of the scenery, detailed enough for me to reproduce it in three dimensions. So I moved to the block-out phase : creating a 3D scenery, very schematically to come to a judgment on the balance of sizes and scales between objects, characters, and distances.
From this scenery, we could start testing the gameplay to decide on the exact positioning and the elements’ sizing. This made it possible to realise if there were “empty” zones, if the game was legible and not overloaded. It also made it possible to determine which assets to delete/move, or whether to add new ones. We then made several games in different sceneriesto define which one worked best.
Once this testing phase was done, we could begin a more detailed and final modeling of the scenery elements.
The preparation period for “Lyon eSport” and therefore of intense work on the dwarf editor being over, it was time to work on the second arena prototype, whose code name, as said above, is Hephaïstos.
After fixing the game mechanics required for this prototype, I started working on its production. As usual, we started very simply to test basic mechanics.
Basic functions were here : taking ingredients, going from one workshop to another to make the object and finally selling it at the counter. We could start the internal test phases. After a few games, we already thought we had to change the controls and add obstacles in the centre of the scenery so players bumped into each other more often.
Simultaneously, graphic designers added a first “graphic prototype” of the game to come to a judgment on the balance of the sizes and the visible scenery. After the first tests, we already had to adjust the angle and the distance of the camera, as well as the position of the UI to better fit in the scenery :
There is still a lot of work balancing and some improvements are possible, but we’re having fun, and it’s very encouraging !
In a prototype production (especially in an indie studio), a gameplay programmer’s work is also to extrapolate some game design elements, because at that stage, nothing is defined with certainty and once made, some gameplay mechanics highlight issues.
It’s therefore important to have skills in game design to offer solutions in my prototypes without having to ask systematically other members of the team when I realise there is an issue. Of course, this issue must be discussed, but it won’t get in the way of the prototype production and a solution base will already exist.
The prototyping phase is one of the most interesting development phases in my opinion. It requires a wide variety of skills and needs a lot of reflection, making it probably the phase giving the most experience.
On the multiplayer and network interactions side, March was filled with progress.
In a first place, I started developing Unexpected notifications service, and then linked this service to all other services having a real-time interaction with the user. That way, the account management and messaging services have been linked to this service.
On dWARf side, big progress was made concerning the user data management system, as well as the setup of the same notifications service than previously, but on dWARf side (both notifications services being independent from each other. One is here for every account/user interaction, the other for every interaction between dWARf/user).
As said previously, there have been major advances in services. dWARf data management service went from the “Heavy Dev” phase to “Tests” (i.e. from the development phase to the testing phase), as well as the load testing phase.
Two new services have been finished during this month : the friends chat service and the notifications service. A new one has been started : dWARf game servers management service (it will create dynamically the games and the dWARf game services while dividing the load up between our servers).
Thanks to the implementation of services that finally had real-time attractions (such as the notifications service and the message sending service, for example), I could finally verify that the inter-service communication worked correctly. As part of this inter-service communication, we used intelligent load distribution and inter-service messaging services. The purpose being to make possible a fast synchronisation of our services while guaranteeing access to constant data.
Thereby, all the services can connect to an “inter-services messaging system” which allows them to send orders to each other. This system makes it possible to centralise (and therefore better monitor) the messages. You can see this service as a post office : you post letters with an addressee in particular (here, a whole service OR only one member of the services) and you are sure that the addressee will receive it. If a problem occurs with the message sending, the “post-office” job is to ensure that the service receives its message as soon as it is possible to send it.
During this month, we also had a discussion about the optimisation system of dWARf’s game client. We looked at several possibilities and finally decided that it would be wise to start a study with the community so that we could have information about our community’s most used computers.
This is how “Specs Retriever” project was born.
The goal of this little project was simple : to analyse the computers of volunteers who accepted to use it so we could receive the information about their computer hardware configuration.
It’s a system that sent us totally anonymous information and that will eventually allow us to define accurately the optimisation needs for dWARf and Unexpected future projects. Thank you again to the volunteers who participated in this data collection which will be very useful in the future !
To conclude, it was a quite busy month on the network and multiplayer part. Lots of new things saw the light of the day. More and more advances are made, and it’s very positive! I personally had an excellent time among you at Lyon eSport and I think I can speak on behalf of the team : thank you for coming to Lyon eSport, it was a pleasure to meet you, and it’s always a pleasure to have feedback concerning our work 🙂 !
For Unexpected, February was an intense month, with a lot of new things and challenges. It tested the team’s qualities, both in terms of efficiency and dedication. The team had a double objective : to communicate for the first time on their first game, dWARf, and to work on the dwarf editor, the first feature of the game that should be shown at “Lyon eSport” (a french LAN-party gathering several competitions on League of Legends).
“Lyon eSport” was the first real close deadline for Unexpected, that, until now, organised itself around mid and long-term objectives. It was also an inflexible deadline as the event took place on March 4th and we had to be ready by this date. Actually, it’s a public presentation, so we needed a perfect product that summarizes our work accurately.
These month’s blogs were written around this context and these objectives to share February’s adventures.
These blogs represent a first exercise for us and we will try to improve them constantly, so don’t hesitate to give us your feedback !
The idea of going to “Lyon eSport” came out by chance, as we learnt that the event had a dedicated area for independent video games. dWARf was at the very beginning of its development (and 3D graphics were barely started). Wanting to present something to people so early was ambitious.
However, I still made a meeting with the team to gather everyone’s opinion about our ability to create something that we could share to people before March. We all agreed that it was impossible for us to create a demo of the game before this date : there are too many gameplay and animations prerequisites, not to mention that there were no texture and that we needed to work both on character design and environment, all in 3D.
An alternative quickly came to our minds : the economic model of the game and the rewards essentially based on the cosmetic aspect of the dwarf, we considerably reduced the amount of tasks by deciding to focus on the dwarf editor, first feature of the game the players will encounter when they will launch dWARf for the first time.
The dwarf editor was already conceived and even partially coded. It needed an interface, and, of course, 3D objects and textures that will be incorporated into the dwarf.
We all agreed on the amount of objects to be modeled and textured for “Lyon eSport”, and on their originality. We chose very different pieces to give a preview of the future variety of esthetic objects available. We also selected some animations that needed to be incorporated into the dwarf to make it look alive.
The interface was already discussed in a meeting, during which we made ergonomic and aesthetic decisions. However, we had to set the limits of the dwarf editor’s interface we were going to show at “Lyon eSport”.
The bright side is that our gameplay programmer could also work on a prototype which will probably be the subject of an upcoming blog.
While they worked on it, I spoke with our multiplayer programmer about making an Alternate Reality Game (ARG) with the community on social networks. The purpose was to prepare the pre-alpha and to give the opportunity to very involved people to take part in the very first releases of the game and in various tests.
This ARG also gave us the possibility to introduce dWARf and its universe before “Lyon eSport” and to reveal a bit more about this new project.
For more information about the progress of the ARG, take a look at This document sums up all the game created by the fantastic community who participated.
Making this ARG was a new and very rewarding experience, but it was a very hard project to manage by a little team like ours. It took a lot of time and a daily involvement. It was also our first community contact, so we had to be very present to understand all expectations and immediately take into account the remarks to evolve the game (especially in its difficulty). Overall, for us, the ARG was a complete success, even if we will not do it every two months
After mentioning the need to work on the dwarf editor’s interface, I made 2-3 proposals and refined one of them in a rather cartoon and colored style ; maybe even a little too much. My personal productions being generally lightly saturated, when it comes to flat, I allow myself bright colors !
Between “Lyon eSport”’s deadline and my personal excitement to suggest something quickly, we didn’t really think about the style we want. But the quick realisation of the first prototypes made us realise the issue of this first approach :
As a matter of fact, the game will be visually rich and in 3D, even the pages out of the game. To stay clear and modern, the interface must therefore be able to overlap on a relatively charged universe. And as we were not remastering Adibou (Adibou is a french educational children’s game with very simple 2D graphics, ed.), I had to find a new graphical angle of attack.
We talked about sober current websites/applications’ interfaces and subtils and “sensuals” interactive animations. This direction seemed more appropriate.
For the editor, we also needed outfits to try them on our dwarves. Liam drew some elements to begin modeling them.
I added a lot of hair type elements (mustache, beard, hairstyle, eyebrows) and I could start working on a key point : the concept art of their outfits. For homogeneity, I first worked on full sets (having a harmonious dwarf is nice!).
But after a few days, the team emphasized that working by object type seemed more appropriate. In an editor, I would indeed tend to choose by punctual favorites. Outfits thought as a full set will be uncommon, to keep their prestige and ideal harmony (ideally, now we have to imagine it!).Homogeneity would be created with the different styles, colors, and themes(medieval, mythological, anachronistic, funny….
I also started to see the limits of this method in terms of creativity, so everyone agreed on this idea, and here I was working on boards of objects (helmets / belts / clothes / shoulder pads / gauntlets), rather by theme (to avoid finding myself with a majority of objects too shifted from dWARf’s universe).
With dWARf, our objective is to create a cartoon and funny game. We wanted the game to be populated with nice and funny characters. To me, in most of animated movies or video games, the attitudes of the character really defines their personality. The way he moves gives him their own traits and sensitivity, and therefore what makes him appealing and alive. For that reason, their design had to be original and allow us to create comic and varied animations afterwards.
We all agreed on “floating” characters, without arms or legs, but wearing big gloves and shoulder pads to simulate an arm’s position in order to maintain a certain credibility and realism in their movements.
Our dwarves now have an elongated silhouette, while keeping a potbelly as dwarves usually have, which will then allow us a wider variety and freedom in animations, whereas we would have been limited if we had kept a round appearance of the character (so they can lean forward, backward, swing left or right… among other things).
Dans dWARf, le joueur à la possibilité de créer son propre Dwarf qui sera son avatar au cours des parties, et devra donc être aisément reconnaissable par ce dernier par rapport aux Dwarves des autres joueurs.
Ainsi, il nous a fallu définir quelles parties des Dwarves allaient être customisables lors de sa création.
Nous avons décidé de garder fixe la morphologie du Dwarf, dans un souci d’adaptation des objets: en effet, si tous les personnages ont la même corpulence, ils peuvent alors tous porter les mêmes vêtement, sans distinctions, et sans demander des modifications de notre part outre mesure. Les Dwarfs seront donc tous trapus et ventripotents.
Il en va de même pour les couvre-chefs: Comme nous avions en tête de créer des casques intégraux, qui reflètent bien l’univers du Nain Fantastique, une forme de tête standard permettait à tous les joueurs de pouvoir choisir n’importe quel casque, qui serait forcément adapté à la taille de sa tête.
Une fois ce cadre défini, tous les autres éléments nous semblaient modifiables facilement.
Les formes de nez, d’yeux et la couleur de peau resteraient fixes après la création du personnage. Cependant, les éléments de pilosité (:sourcils, moustache, barbe et cheveux) pourraient être modifiés à tout moment, aussi bien leur forme que leur couleur, et indépendamment les uns des autres.
On her side, Audrey created a wide range of concepts she gave me, so that I could model the most of it in 3D.
At this time, we realised we had an important issue : at first sight, some haircuts seemed incompatible with some sorts of hats. Regarding integration, we needed to see how we will manage these elements. Solune and I thought about the compatibility of these elements between them. Some hats just covered the entire haircut (full-face helmets), some hats naturally landed over the haircut (little hats), but some haircuts were almost impossible to combine with most of the hats (ponytail on the top of the head). Finally, Lauriane and Solune created a classification of haircuts, specifying which one was compatible or not with specific hats’ criteria in order to deal with the compatibility between all the elements, almost on a case-by-case basis.
So I created different types of haircuts and hats to represent the diversity that will later exist, and to allow us to organise the management of the classifications directly.
In dwarf’s editor, the remaining customisable elements are clothes : gloves, shoulder pads, belts and outfits. For these elements, compatibility problems didn’t show up because they didn’t overlap on one another, except for the belt that, theoretically, will always have the same shape and be placed at the same spot : a ring around dwarves’ waists.
Audrey has created a lot of concepts for each object. As for hairiness, I didn’t have enough time to model a lot of objects in 3 dimensions, due to the short deadline of “Lyon eSport”. I then decided to reproduce the most varied elements which are also representing our game’s universe : fantasy elements from dwarves’ world, but also anachronistic and unusual elements.
To create as many elements as possible to be shown at “Lyon eSport”, I chose elements in Audrey’s researches and recreated them in 3D as close as I can not to misrepresent her concepts, but I took some liberties concerning the textures of objects, along with shapes modifications in three dimensions, which are invisible in two dimensions.
At that time, Solune had to put all these elements in the game engine and created the interactions between interface and 3D models.
At first, we had this :
A classic unity UI and a dwarf made of customisation elements with deformed and primitive shapes. Simple and efficient ! Unfortunately, it was not enough for Liam and Lauriane so I needed to do better :
As a first step, I integrated the UI Audrey carefully prepared :
To reach this point, we had to pay attention to several things :
– some UI elements have to be proportionate to the screen dimension, in order to support every ratio and resolution
– square elements have a dimension depending on the screen, the other being in function of the first
Unity has tools allowing us to do these things easily :
The element will have a 60% width of its parent, and the “Aspect Ratio Fitter” ensure he will stay square ! Even empty, it was already beautiful ! I really wanted to complete it !
Then, a little more technical : how was it going about the code ? The dwarf being animated(unlike the pizza-dwarf) and having deformations in their animation, customisable elements had to follow this deformation. On this, most of the work was made by Liam, who binded (skin) different parts of the element to different parts of the dwarf’s body (bones), but I had to make sure that elements followed animations accurately when they were changed in the editor.
In Unity, this could be made by using a skinned mesh renderer feature (for the skin) and an animator (with an Avatar that represents bones). To do so, the element was instantiated as the animator’s child, then the Rebind function of the animator was used.
Until that time, everything was fine. Nonetheless, the Rebind function reseted dwarf’s animations and it was not really beautiful. I therefore saved the animation I was working on when I changed the element, and restarted where I was after making the change. In a nutshell, it roughly looked like this :
From here, we could clearly identify the issues concerning the creation of a dwarf with a greater or lesser choice of customisation we wanted for the game.
For instance, although we wanted a lot of choice in dwarf’s editor, we chose not to make the player able to change their right gloves independently of the left ones (and the same for shoulder pads), for aesthetic and consistency matters, as our customisable objects are part of varied and often unique universes.
As Liam already noticed it, an issue came out quickly about hats/masks compatibility and different parts of the face. Not to work on a case-by-case basis, hats and hair have criteria and some other rules automate the process : hair is removed under full-face helmets, light hats disappear on an irregular haircut, etc… The result of these criteria is an accounting matrixbetween hats/hair still adjustable on a case by case basis.
Integrating all these elements wasn’t a simple work : once Liam sent me an element, I tested it to check if there was no graphic “bug”, I used a handmade script to create an icon from the element’s model, I set up exclusion rules and checked one last time if everything was okay.
February was quite busy concerning the field of multiplayer management, as well as managing interactions with the community.
Most of my job being to create every network links of communication between the customer and Unexpected services, I was assigned to create (the technical part of) the ARG, taking place in February. Besides the ARG, advances were made on different services, including Unexpected account management service and server communication lib of Dwarf client.
As aforementioned, I mainly progressed on Unexpected’s core services during February : accounts access, users authentication, online payments management etc…I wanted to offer a service adapted to most users in a simple and efficient way.
For this, I decided to develop a “cloud ready” application. It means that the application is designed to be put into production on one or more different servers so that the load can be distributed efficiently.
So I thought services with 3 different types of services : restful Applications Programming Interfaces (APIs) for accessing and modifying the data, notifications services for all that is in “real time” and services for the game’s servers.We can thus represent the interaction between an user adding another user as a friend like this:
The ARG organised during this month was for me a first challenge concerning Unexpected server load : more than 15 000 different IP addresses connected during the week that lasted the ARG. I also worked on the development of different riddles (mostly on the technical dev side [programming, production, etc.]), and the imagination of the latters with Unexpected’s team.
To split the load properly, I set an architecture up, which was simple but efficient :
And it managed to support the transferred queries. In total, 606 188 queries were registered on web servers and more than 6 319 554 interactions were registered on real-time services (H.A. Grid [with 6 044 913 queries in 3 hours] and Andromeda [with 274 641 queries in 5 days]).
I was totally amazed by the ability of the community to coordinate ! Riddles were solved in a very efficient way, and we didn’t expect a community that large to be so organised !
To conclude, this month has been really busy concerning multiplayer development and services : progress in Unexpected main services were made, just as in game servers (dWARf) and finally, a community event (ARG) that, in my opinion, went really well ! I think I can speak on behalf of Unexpected’s team : we all had fun watching the community interact around the riddles, and it made us even more motivated. We look forward to seeing future interactions in our upcoming game : dWARf !