Author Archives: Sébastien Bénard

  1. Tenjutsu announcement!


    Today, I’m proud to officially announce the existence of Tenjutsu, a new addition to the roguelite world, with the help of the incredibly nice people at Devolver Digital.

    Tenjutsu is born from a Ludum Dare game jam and the ashes of Dead Cells, despite my desire to NOT make another rogue. Guess what, I’m doing another one :)

    To sum it up, Tenjutsu is what John Wick or Jackie Chan would be if they were a combat roguelite. An action-packed melee combat system, where you face multiple enemies at the same time, filled with split-second battle opportunities.

    Picture this: you enter a room with 3 thugs, one has a gun and the other two only have their fists. You start chaining kicks and punches the first melee guy, then send a violent elbow kick to his friend attacking you from behind, and proceed to finish the first melee thug. Suddenly, the gun guy starts to aim at you. You throw a knife at him, killing him instantly. You then roll behind the remaining thug (still stunned, he surely has lost a few teeth), and dash-kick him into a nearby wall.

    Bam. Everyone is down in about 4 seconds.

    My idea was just this: make the combat way more dynamic than in Dead Cells by adding opportunities, combat space management and crowd control to create true “one vs many” situations.

    But wait, there’s more!

    Tenjutsu of course has tons of unique weapons (each with a specific gameplay), loot, upgrades and bosses. It’s a rogue, right? 

    But I also wanted to address the issues with the quite linear world design from Dead Cells. I want the player to have control on their path. So, you can take down the game bosses in whatever order suits you. The later, the harder. Don’t like the bullet hell boss? Take him down first. Think of it as Megaman, but “roguer”: each eliminated boss will have consequences on the rest of the run. 

    There’s sooo much more to talk about (the city evolutions, the enemies, the progression system!), but… no, today is not the time, yet :)

  2. Game feel demo (v2)


    This prototype is not exactly an actual game but a tool to learn game-feel techniques.

    It was designed to show the impact of small details on the overall quality and feeling of a game.

    You can enable or disable individual game features in this demo by pressing the START button (gamepad) or the ENTER key (keyboard).

  3. Regarding Dead Cells termination

    Credit: Evil Empire announcement (X/Twitter)

    I posted on Discord a hot take on the recent announcement from Motion Twin (“MT”), my former company where I operated as a Lead dev and Lead game designer.

    It was late, my words were definitely a bit impulsive, and I truly apologize for the blunt words.

    So let’s clarify my own statement.

    For the context, I’ve been an associate at MT for about 19 years and was responsible for most of the design of Dead Cells, and its development, from gameplay, controls, balancing, items and down to the engine (see gamebase). I was not alone, but frankly, I had direct implications on all its parts.

    Here is also a quick presentation of the Dead Cells related companies:

    • Motion Twin (including myself) created the game and released 2 DLCs.
    • While Motion Twin retained the IP, Evil Empire, created by former MT associates, continued the hard work and released 22 new major updates and DLCs, for about 5 years. They hired 50 people during that period of time.

    Recently, MT abruptly decided to cancel all upcoming updates for Dead Cells, a move that left the player community quite speechless. Note that Evil Empire (EE) had official content plans for at least 2024 and 2025 (see, or google it)

    My take

    Someone from the Discord called for my take on that event and I decided to throw some extra light on this strange decision.

    To put it shortly, Evil Empire did a tremendous job at keeping the game fresh and alive, while taking great care of their players.

    On the other side, I’ve seen first-hand how we, Motion Twin, considered our player base, years before Dead Cells even existed. Back when we were making dozens of Browser/Flash games. Our short term strategy was: release, update a bit, drop. It’s not some confidential information, it’s basically what our old player base, from the pre-Dead Cells era, know. I have obviously been part of that, but as a cooperative company, decisions were taken together, and I had my share of disillusion on that topic.

    Obviously, when Dead Cells became the success we all know, MT decided to instantly ignore all of its past web-era player base. Fun fact, our former loyal players even waited more than 4 years and hundreds of requests to get the source code of long dead web games, mostly because MT didn’t care much. Thanks to their incredible love and dedication, some of our old creations were brought back to life (see Eternal Twin).

    Seeing a similar abrupt termination decision from MT about Dead Cells, I can all but extrapolate on what happened behind the scene.

    The current Motion Twin team is more or less 3 people from the former Dead Cells team, including one employee that joined lately, and one who took care of the administrative stuff. Most of the true original team members are now gone. Even MT founders are long gone: one founded Shiro Games (Dune, Wartales, Northgard), one created Shotgun King, and me, well.. wait for it, cool things are in the making :)

    To be honest, the only true Dead Cells team is now basically Evil Empire that managed to carry the flame for so long, with a true love for the franchise.

    Even I didn’t trusted them, when we decided to give them our baby. I seriously doubted that anything cool would happen from this deal. Oh I was so wrong. Five years later, Motion Twin was responsible for the 1st million units, while Evil Empire made the 9 following millions (public data).

    The kind of obvious reason for all this fuzz is certainly to leave room for Windblown, the upcoming dash-dash-dash rogue from MT. As the press slowly started to realize that the Dead Cells true architects were now EE, I can easily see how the panic happened at MT. If you check the recent articles about Dead Cells, EE was mentioned more and more as the actual authors, which was honestly quite fair, given their supportive pedigree. But I can imagine MT didn’t like the fact that people started to realize that.

    I kind of understand the MT strategy: it’s a rather logical marketing stunt. Get rid of Dead Cells to leave room for Windblown. But as Motion Twin always did, it’s a one-way strategy that leaves people behind: both loyal players and employees at EE. Nothing really new, unfortunately.

    I’d close that topic by simply quoting someone still part of the current MT team (I hope he won’t mind, I kept him anonymous). He had some interesting take, as we debated about how we should, or should not, take care of our past communities and our former player base:

    “Why bother? What do we owe them?”


    Absolutely everything man.

  4. Have a nice death

    Leave a Comment

    I worked as a gameplay consultant with the amazing team at Magic Design Studios.

    Have a Nice Death is a 2D action roguelike where you play as an overworked Death, whose employees have run rampant, completely throwing off the balance of souls – and his vacation plans. In order to restore order, you’ll have to grab your trusty scythe and show your employees who’s boss.

  5. Tenjutsu (48h version)


    Your dojo has been attacked by mysterious armed men in black. You have to take it back!

    Tenjutsu was made in 48h for Ludum Dare 51. The theme was “Every 10 seconds“.

    Fight enemies, collect DEATH MARKS (ie. skulls) and tag enemies with these marks. Every 10 seconds, marked enemies will die. Some stronger enemies will require more marks to get rid of.

    Making of timelapse
  6. Dungeon prototype



    This is not an actual game, but a proof-of-concept prototype that implements a retro/modern “Dungeon Master” engine:

    • True 2D engine: no 3D involved here, it’s all fake.
    • Fake texture details: all wall angles and 3D details on them are generated on startup, making the process of creating art for such engine quite fast (you only need a wall texture and its height map)
    • Smooth movements: using various motion design tricks, the movements should be smooth and understandable for an external spectator.


  7. Market study spreadsheet


    Market Study is a Google Sheets document which allows you to get a rough estimate of sales and revenues of any released title on Steam.

    It’s precise enough to get an idea of how successful a particular title was, which is a critical piece of information for any game dev. I use it almost every single day.

    Update: Julien Cotret (@CotretJulien via Twitter) made a script to fill in details automatically: link.

    How to use it?

    To use it, just fill in the required information:

    • Game title,
    • Game Steam AppID (it’s part of the url of a game:
    • Game release date (from store page)
    • Game full price (from store page)
    • Open the SteamSpy page of the game by clicking the “📈” icon. Copy the “owners” count. You will need a Steam Spy account. Please support their great work!
    • Open the SteamDB page by clicking the “” icon. Move your mouse cursor over the review rating percentage on the right, and copy the total review count from the tool tip that appeared.
    • That’s it!


    This document is released CC BY-SA 4.0 license. It basically means you can do whatever you want with this document/tool, as long as you keep the same license if you re-share.

  8. Nuclear Blaze (48h version)


    48h version

    The building is on fire? Nah, not today.

    This game was created in 48h for Ludum Dare 48 entry. The theme was “Deeper and deeper“.

    I definitely spent too much time tweaking the fire effect but I’m pretty happy with the final result anyway :) I couldn’t implement everything I wanted to get closer to the actual theme, but the general idea was to make a game where you really feel that things are getting worse and worse, and out of control at some point.

    The initial intent was to make the final levels feel like “you can’t stop the fire anymore, you only have to survive and find your way out“, but this didn’t make it to the 48h game.

    Extended version

    Nuclear Blaze received lots of positive feedback, and as a matter of fact, my 3yrs old kid also loved firefighters stuff, so I decided to turn this jam project into a full game on Steam and ItchIO :)

  9. April 2021 – Roadmap update



    • LDtk 0.8.2 is coming within the next few days.
    • The current LDtk discord will be re-organized to become official “Deepnight Games” discord, with separate sections for LDtk, gamedev and soon, “Survive” game project.
    • I’m about to focus mainly on my game project code name “Survive“.
    • GameBase for Haxe will have some major 2.0 update really soon


    Being back from holidays and it’s now time to slow down a little bit, to prepare for the future. So here is a rough roadmap on my personal plans about LDtk, “Survive” game project, Deepnight Games, and other side projects.

    • Deepnight Games (ie. me, Sébastien “deepnight” Benard) is a single person company where I do everything, from coding to art, including support and marketing. This obviously means I have to prioritize, and I’m not in a state where I can do everything ;)
    • LDtk: I plan to reach 1.0 stable state within a few weeks, as I believe LDtk is now almost feature complete. This is not the end (obviously, but still, it’s important to mention that), but only a major milestone for me to reach. After that point, I plan to continue to support it and add more & more features, but this will happen at a much lower rate, as I’ll move my focus to “Survive project“.
    • LDtk discord: as of today, the discord server features a mix of discussions about LDtk app, related libs and stuff about GameBase and other game dev topics. To be more consistent with that, I decided to make things a little bit cleaner by making it the official Deepnight Games discord, which will continue to focus on LDtk itself, but will also include channels about GameBase and the future Survive projects when this will be needed.
    • Survive (project code name): a HUGE project and the reason behind making LDtk. Not much to reveal about it for now, except it’s a 2D platformer with a strong emphasis on exploration, mood and combat. I like to think of it as a mix between Final StationSTALKER and System Shock 2. The combat prototype is done and quite satisfying, the main tool (ie. LDtk) is ready and I now really need to starting working on the game full full-time, to make it happen. Good side effect though: because it requires a very solid level editor, LDtk will get more & more extra features as I make progress.
    • GameBase: One of my goal in life is to teach/share as much as possible. GameBase is a code base for any game dev out there who wants to get a compact and efficient 2D “engine/code base”. I personally use it for all my games (from Dead Cells to Survive, including most of my game jams). It’s based on Haxe language, with Heaps game engine. I just finished wrapping up a major 2.0 milestone for it, soon to be officially announced. I might build some dedicated website at some point to make it reach the “next level”.
    • ElectronBase: same idea as GameBase, a starting point for devs wanting to make a Haxe/JS/Electron app. It’s mostly for my personal use, but still, it’s open source.
    • Improvise: I play lots of tabletop RPGs with my friends (mostly using Roll20 platform) and Improvise is a small side project I’m building on my free time to help game masters resolve quick random content generation. It features a very cool dice roller with ease of use in mind and a “random table” editor to create your own stuff. Not released yet, will be “when it’s done”.
    • RPG Map: another tool I previously released for tabletop RPG game masters. I don’t think I’ll work much more on the current version (except a few bug fixes), as my long-term plan is to create *RPG Map 3* as an Electron/WebGL based app, for easier future development. Some merging might also occur with Improvise, depending on the state of both project.

  10. Fort Loop


    Everytime the torches turn off, the whole castle resets and goes back in time. Everything goes back to its original place, except you.

    A 48h game developed for Ludum Dare 47 game jam.


    To me, this game was some crash test for LEd, the level editor I’m developing for the indie community. Pretty much everything went really smoothly, and LEd allowed me to create visually advanced levels with quite few work.

    Gameplay wise, I add a very bad time trying to make the time-loop functionality fun, and it never became a really good base for interesting puzzle design. It proved to be hard to create many unique situations with it. With some sleep, I now have some better insight at what should be fixed, but I’d love to hear about your comments :)

  11. Petit Tracteur Bleu


    You are Little Blue Tractor and your goal is to find all the cows and bring them back home before night falls (the game lasts about 3 mins).

    Petit Tracteur Bleu” is a game I created for my 2.5 years old son, Gabriel, because he loves tractors. So please, don’t expect anything crazy here, it’s just a very simple game :)

    It was designed to be played by someone who never played a video game before, and most movements are automated. The manual jump mechanic is only useful to explore hidden areas (using bumpers).

  12. Dumber Dwarves

    1 Comment


    Dumber Dwarves is a dungeon crawler where you can’t control the adventurers directly and they are not the sharpest tool in the shed. Slap them or throw some meat on the battlefield to give your “instructions”.

    The game was created in 48h (well, more like 35h) for the GMTK 2020 game jam. The theme was “Out of Control“.

    Please note that there is no sound nor music in this game. Didn’t have time :)


    The game first started as a god game where you were to teach humans things by only slapping them. So, if a disciple was picking up some food for example, slapping him would teach him to avoid food (ie. “god thinks food is bad“). Problem was: a disciple who learn something tends to repeat the concept on its neighbors. So, someone who thinks food is bad will also slap other disciples picking it. It was even possible to slap someone slapping, so it would teach that slapping someone was bad. And so on :)

    It was a funny little prototype, but too sandboxy to actually become an interesting jam game. Maybe with some extra work, but definitely not in 48h.

  13. July 2020 – Roadmap


    Going rogue, part 2

    Hi everyone!

    TL;DR: you can simply check the roadmap at the end of the article.

    First of all, let me thank everyone of you ​for your amazing support :) I received many very touching messages which were really important to me (and actually balanced the total lack of support I received from my former team mates at Motion Twin). I’m now really motivated to prove worthy of your confidence.

    Moving forward, I’m now officially a game company, called Deepnight Games

    Some of you might notice the tiny red star on the character shield ;)

    I’m now legally allowed to make, publish and hopefully earn money from games.

    L-Ed / RPG Map

    Aside from all the administrative stuff, one of the first things I did was to work on a 2D level editor for game-devs, based on my experience with RPG Map 2, code named L-Ed (for Level Editor). It’s not released yet at this point, but should be out there really soon, probably open-source. I will talk about this one a little bit more in a future article.

    This project, plus the whole Covid-19 thing obviously had a few impacts on the development of RPG Map 2. My time was very limited and it was impossible for me to invest as much time I would have loved to on RPG Map. This means the Update 17 was delayed a lot: it’s still planned, just without any estimated release date yet.


    So here are my general roadmap for the next few months. Please note the timeline may vary: some events might occur before some others, depending on the time I’ll actually have and the progress made.

    L-Ed release
    Game-dev oriented 2D level editor, free and probably open-source
    RPG Map (Steam release)
    Not much to do here, except a few bug fixes, and me getting used to the Steam publishing workflow.
    RPG Map update 17
    This is a big one. I plan to rework completely the UI using what I’ve learned from making L-Ed (basically: using NodeJS). This will allow the app to become completely cross-platform: Mac & Linux support is coming!
    My first game as a solo dev
    Top secret stuff for now, but I’m quite excited :)
  14. Part 4 – Localize texts using PO files




    PO files are part of the GNU GetText localization technique. It’s a very simple format that can be edited using various tools, like POEdit (available on Windows, Mac & Linux).

    The philosophy

    The “classic” way to do things is to write “dev English” sentences in your code, then use this Dev-English to kind-of translate to “proper English” (which will be used in the release version of your game), or translated to “proper whatever-language” you might want.

    Note that your Dev-English are the keys for the translation texts. So changing your Dev-English texts will break the keys. The good thing is POedit handles that well, and properly suggests “lost” translations.

    My implementation

    My GetText implementation has 3 elements:

    • GetText.hx (from deepnightLibs): the lib that can read/write data files
    • Lang.hx (from gameBase): the main API to access texts from my code
    • LangParser.hx (from gameBase): a separate script that parses all source code files and extracts strings directly from them (built using the Haxe “makefile” langParser.hxml).

    If you want to use the GetText lib for Haxe, you will need to install it:

    haxelib install deepnightLibs


    Marking translatable strings with Lang.hx

    In your code, just use calls like: Lang._("Some translatable sentence"). This will allow our tools to extract all the strings that require some translation, so we can feed our PO tool.

    For example:

    function myStuff() {
      trace("This is an untranslated text");
      trace( Lang.t._("This text is meant to be translated, and will be extracted.") );

    Extracting texts

    You can run haxe langParser.hxml from the command line to extract all strings in Lang.t._(...) calls.

    All these strings will be stored inside a POT file, which is a Catalog file.

    Using POedit to translate

    In my above example, the POT file is my “Dev-English” string catalog. It should be stored it in the /res/lang folder.

    In POedit, start a new translation by setting the target language (could be French for example, or English again, if you want to turn your dev-English into something better).

    Import your POT catalog using the menu Catalog -> Update from POT. This will add all the untranslated strings extracted by the LangParser script.

    Translate or validate existing entries “as-is”, and save your PO file. It will also generate a MO file which is basically the optimized/binary version of the PO file.

    Import translations into your code

    Modify the Lang.init() method to import new languages. All your Lang.t._("My string that needs translation") calls will be replaced by the translated string found in your MO file on runtime.

    Important: all the PO and MO files should be stored in /res/lang folder!

    Advanced features

    Strings with parameters

    If you need some dynamic content inside a translatable string, you use the ::myVar:: system. To replace myVar in your string by the actual value you want, you need to provide an anonymous object to the Lang.t._(“…”) call.

    See the following examples:

    Lang.t._("Hello ::name::! How are you?", { });
    Lang.t._("::v:: + ::v:: equals ::eq::", { v:5, eq:10 });

    Note that the compiler will check any anomaly here:

    Lang.t._("Hello ::name::! How are you?");
    Lang.t._("Hello ::username::! How are you?", { name:"foo" });

    Both will pop a compile error of variable name mismatching.

    Adding translator comment

    Sometimes, you may have some strings that could translate differently based on context.

    For example, in your app, you might have a setting for some font size, and one possible value is the string “Large“. In this case, it means “Big“. For another setting, like a world size, you might have a setting string “Large” again, but this time it means “Vast”. They would translate in different ways in French for example.

    To disambiguate these strings, you can use Translator comments:

    Lang.t._("Large||for a font size"); 
    Lang.t._("Large||for a level size");

    Both will return “Large” at runtime by default, but they can now have distinct translations, if needed (so the return will vary in this case).

    Warning: due to some technical limitations, you shouldn’t have ANY space around the “||” (double pipes) characters.

    In POEdit, translation comments appear right in front of the corresponding entry:

  15. Part 3 – Distributing a Haxe project


    After hundreds of hours spent on your Haxe / Heaps project, you probably want to release it at some point.

    All you want in the end is a basic Executable file that you could push on your favorite distribution platform. Let’s see how we could do that.



    RedistHelper is a free tool I wrote to facilitate my RPG Map redistributables creation. It makes the whole process automated and hassle free.

    Install latest stable version

    From a command line, just get the latest release by running:

    haxelib install redistHelper

    You will need my general purpose libs too:

    haxelib install deepnightLibs

    Git version

    Optionally, you can also you the latest GitHub version using the following command. Be careful though, as it might be unstable.

    haxelib git redistHelper
    haxelib git deepnightLibs

    Using redistHelper

    Showing help

    The most basic way to use is to open a command line inside your project root (where the HXML files are), then type:

    haxelib run redistHelper

    This will display the tool help, including some examples.

    Basic usage

    To package your project, just run:

    haxelib run redistHelper myProject.hxml

    RedistHelper will parse your HXML and create a redist folder containing all the required files. You can simply distribute that package and it should work :)

    You can package all your HXML files in one single call:

    haxelib run redistHelper gameHashlink.hxml gameJs.hxml gameSwf.hxml

    You can optionally add the following parameters to the RedistHelper command:

    • -zip : will create a ZIP archive for each package
    • -v : enable verbose mode (mostly useful for debugging)

    Embedding extra files

    You might need to add some extra files to your packages, like a README or a LICENSE. Just add their path to you RedistHelper command:

    haxelib run redistHelper game.hxml docs/README docs/license/LICENSE

    You can rename any extra file on the file by adding a “@” to their path:

    haxelib run redistHelper game.hxml docs/README@readme.txt

    Available targets

    HashLink project

    The goal here is to turn your app into classic and easy to distribute Windows Executable (EXE).

    When packaging HashLink (HL) projects, RedistHelper will copy all the required runtime files directly from the Haxe and HL folders from your system. This includes DLL and NDLL, the HL executable and a few other things.

    Your project.hl file will be renamed to hlboot.dat which is the default file loaded by hl.exe when it’s run without parameters (see link).

    The hl.exe itself is renamed to something closer to your actual project name, feel free to rename as you wish.

    If your HXML uses the hldx library, the redistHelper will package a DirectX folder.

    If your HXML uses the hlsdl library, the redistHelper will package a OpenGL (SDL) folder.

    You can use the -hl32 to also package a 32 bits version of the HL runtimes, for older systems. Warning: this will use the last release HL 32 bits (1.10). All recent HL updates won’t be included!

    HTML5 / Javascript

    When packaging a JS target project, RedistHelper will produce a basic HTML file to load your app properly. You can use it to create your own integration.

    In your HTML body, you basically should have something like that:

    <canvas id="webgl"></canvas>
    <script type="text/javascript" src="myApp.js"></script> 

    Please note that the webgl ID is important here, as it’s the primary target for web apps build with using Haxe.

    Neko VM

    Neko is a lightweight virtual machine for Haxe which can be useful to build small command line tools for example.

    RedistHelper will turn your Neko binary file (*.n) into a Windows Executable and add all the required runtime files.

    Adobe Flash

    While Flash is supported, it’s not super useful here, as the SWF file is already a package in its own.

    Distributing on platforms

    You have 2 ways to push an app on

    If you install it, Butler can be used right from the command line to upload your fresh new build to in a single command line:

    butler push redist/directx myUserName/my-app-name:win-directx64

    If you want to upload a JS app that should be played right from the user browser on the website, you just have to package your app using the -zip parameter:

    haxelib run redistHelper myJsGame.hxml -zip

    This will create a ZIP archive that you can easily upload to your dashboard, or send using Butler.


    RedistHelper is open source (under MIT license). You can download the source, adapt to your needs or add more packaging targets.

  16. Free time tracking tool



    This Google spreadsheet will help you to keep track of time spent on your projects:

    • Single user oriented to keep it simple,
    • Easy to add projects,
    • Shows a clear summary of your current and previous week, and how you spent your time globally,
    • this time tracker is simple and does its job,
    • you can easily have all your data at your disposal,
    • it can be updated to your needs, if you know how to do Google Sheet formulas.

    Being confined (thanks Covid19), I’ve spent some time making this tool for my own usage, to take care of my new indie career. Feel free to use, share or change it!

    How to use it?

    Make a copy of the spreadsheet on your own Google Drive (File > Make a copy)

    Go in the Projects tab, fill this sheet with your own project names & colors.

    Go in the Time Tracking tab, just enter a date (make sure to match the spreadsheet date format, see File -> Spreadsheet settings), pick a project from the list, and fill the hours column.

  17. Part 2 – Using GameBase to create an Haxe+Heaps game



    Every time I start working a new game, I use “GameBase” as a starting point. It uses the Haxe language and the engine.

    GameBase offers a minimal set of classes and tools to get started quickly making your own game. It’s completely open source and easy to adapt to your needs. Oh, it’s also quite simple and not bloated with tons of useless classes or features.

    Of course, you could also start from scratch, but that’s not something I’d recommend if your goal is to learn Haxe language + Heaps engine.

    Getting GameBase

    First thing first, here is the official GameBase repository on GitHub:

    Installing Haxe + Heaps

    I wrote a step-by-step tutorial on how to install the whole thing on Windows.

    Please check it out if haven’t installed Heaps yet.

    Installing dependencies

    You’ll first need my deepnightLibs, which contain many useful classes I use in all my projects. To install it, just run:

    haxelib git deepnightLibs

    Also install CastleDB lib (a simple database for Haxe games, see

    haxelib git castle

    Getting the GameBase source code

    Method A: template

    Just go to the repository on GitHub and click on the Use template button. Learn more about GitHub templates here.

    Method B: fork

    Go the following GitHub repository:

    Just fork this repo and clone it on your computer. Feel free to adapt/edit/copy for your own usage (see LICENSE).

    Method C: adding an upstream remote

    This method is mostly for my own usage, as GitHub doesn’t allow me to fork my own projects.

    • Make a new repo on GitHub (WARNING: do not add any license or don’t commit anything in it for now)
    • Clone it somewhere
    • on a command line:
    git remote add gameBase
    git pull gameBase master
    git push origin master
    • Or for the Advanced game base branch:
    git remote add gameBase
    git pull gameBase advancedBase
    git push origin master

    Checking if it works


    If everything is properly installed, just run the following command right from the gameBase root folder:

    haxe build.directx.hxml

    This should generate a client.hl in your /bin folder.

    Other platforms

    You can build for other platforms:

    • DirectX for HashLink VM: haxe build.directx.hxml (recommended)
    • Javascript (WebGL): haxe build.js.hxml
    • OpenGL for HashLink VM: haxe build.opengl.hxml

    Please note other platforms could be targeted by creating a corresponding HXML file (see:


    To run the game, execute one of these commands:

    For DirectX or OpenGL Hashlink:

    hl bin\client.hl

    For WebGL (javascript):

    start run_js.html

    You should see something like that:

    This is the default GameBase sample game.

    Building and debugging from VScode (recommended)

    From VScode, just run the “Debug: start debugging” command (press F5 by default, or check the VScode command line with CTRL-SHIFT-P).

    This should run the default pre-configured HL Debug command which compiles & runs the HL DirectX version.

    If you plan to debug WebGL (Javascript) content, you’ll need one of the following extensions for VScode:

    Don’t forget to change the HXML used for code completion before starting to code:

    Check the bottom left corner of VS Code
    • Click on _base.hxml at the bottom of VS Code window.
    • Change it for whatever HXML you plan to use for building/testing your game (probably, which is Direct X with added “debug” flag).
    • This HXML will then be used for code completion

    Making a game!

    The hero we need

    We’re now ready to make the very first any game needs: adding a playable character.

    First step: create a Hero.hx in /src/en/Hero.hx. The “en” folder is the package for “Entity”-based classes.

    This is our hero:

    package en;
    class Hero extends Entity {
    	public function new(x,y) {
    		// Some default rendering for our character
    		var g = new h2d.Graphics(spr);

    In the Game.hx, you can create an instance of your Hero at the end of the new() constructor.

    class Game extends Process {
    	// [...]
    	public function new() {
    		// [...]
    		new en.Hero(5,5);


    We now need a little bit of control. If you have a gamepad, you can use it easily. You can also still use a standard keyboard too.

    We need the dn.heaps.Controller class:

    class Hero extends Entity {
    	var ca : dn.heaps.Controller.ControllerAccess;
    	public function new(x,y) {
    		// [...]
    		ca = Main.ME.controller.createAccess("hero"); // creates an instance of controller
    	override function dispose() { // call on garbage collection
    		ca.dispose(); // release on destruction
    	override function update() { // the Entity main loop
    		if( ca.leftDown() || ca.isKeyboardDown(hxd.Key.LEFT) )
    			dx -= 0.1*tmod;
    		if( ca.rightDown() || ca.isKeyboardDown(hxd.Key.RIGHT) )
    			dx += 0.1*tmod;


    Build & run the game (F5 with VScode) and test it. Your red hero should move left/right on key presses or gamepad.

    That’s how any great hit actually started.

    About “tmod”

    tmod is a value connected to the duration of the frame, and more precisely, the time elapsed between two consecutive game frames.

    • on 60 FPS, tmod is 1.0 (the “normal” value)
    • on 30 FPS, tmod is 2.0
    • on 120 FPS, tmod is 0.5

    tmod can be used to adjust values that are FPS dependent, such as velocities or accelerations.

    The idea is:

    • if the game runs slower (ie. less than 60 FPS), all the movement increments should be higher, to compensate for the missing frames.
    • if the game runs faster (ie. more than 60 FPS), all the movement increments should be smaller to acknowledge the extra frames.

    See Delta time to learn more about this classic concept.

    Working without “tmod”

    The dn.Process class has a fixedUpdate() which runs (or at least tries to run) at a fixed lower FPS, usually 30 or 24 FPS (check the fixedUpdateFps variable). The FPS of these fixed updates is guaranteed, within the realms of possibility.

    The Entity class also has a similar fixedUpdate() which runs at the same fixed FPS as the Game.

    A classic approach is to do every gameplay related things, like physics, or velocities inside the “fixed” updates, and do everything else (rendering, particles etc.) in “real FPS” updates.

    This keeps the gameplay code quite simple, without having to rely on the tmod/delta time values.

    You might think it would be an issue to have your gameplay code in a 30 FPS loop instead of 60 FPS or more, but bear with me: no one will notice. Dead Cells, which is known for its fast-paced action & gameplay actually uses 30 FPS loops for the gameplay elements. The render is done at 60 FPS.

    Important: all the controller related checks should happen inside the real FPS updates, because that’s the only way to catch a user input at the exact moment it happens. The fixed updates won’t catch these events, because these fixed updates don’t occur on every single frame.

    Classes & API

    Boot.hx: where everything starts

    The first thing called in your code is in the Boot.hx method main(). From here, we create a Main, which creates a Game.


    All the updates are called in the following order:

    1. Boot.hx has an update() which takes care of low-level stuff. You shouldn’t do much here, unless you have very specific needs.
    2. Main.hx has an update() too, and is basically your global app main update. It also has a postUpdate() which happens after the update().
    3. Game.hx also has an update(), a preUpdate(), a fixedUpdate() and a postUpdate(). This is where your game related code will happen.

    Note that Boot extends hxd.App which is the top-level app class in Heaps. I use a different class for Main and Game: dn.Process.

    My dn.Process class takes care of the updates, and each Process can have children processes, support pausing, have preUpdates, fixedUpdates, postUpdates and few other useful things.

    The philosophy with GameBase is quite simple: all your future Processes should be either children of Main (any section of your app which is not the game, like an intro screen), or Game (if it’s part of the actual game).

    Important classes

    All code files are in /src folder.

    • Main.hx: the main app loop, see the update() method
    • Game.hx: created every time a game is started, it also has an update()
    • Entity.hx:: the most important thing after the Game. It’s the base class for everything that moves in the game (player, enemies, bullets, items etc.). Everything except particles (see Fx.hx). Read below for more explanations about the Entity class.
    • Level.hx: your world, level, room or whatever is your environment. Some games might have none of these, or multiple instances, it’s up to you.
    • Camera.hx: a basic camera which can optionally track an Entity (say, the player)
    • Fx.hx: a simple particle system
    • Lang.hx: a neat way to automatically extract your texts directly from your code to generate PO files compatible with the popular GetText translation ecosystem. Check the specific tutorial to see how it works.
    • Const.hx: contains a set of constant values I use to tweak my game, like the standard FPS, your starting health points or stuff like that.
    • Assets.hx: a single class to access assets like tilesets or sounds. All your assets (art, sound, other data files) that are meant to be loaded/used by the game should be put in the /res folder. You can access them in your code using the hxd.Res.myAsset API.

    Misc classes

    • import.hx: note the lowercase format of this file name, it allows to have global imports for every classes of your app (see: Neat.
    • tools/CPoint.hx: a simple Point class that supports grid-based coordinates.
    • ui/Hud.hx: a process of Game which can be used for any HUD (head-up-display, aka. interface) for your game, like: gold, life, ammo etc.
    • ui/Window.hx: a simple pop-up object.
    • ui/Modal.hx: same as Window, except it pauses the game while it’s open.

    The Entity class


    Entity.hx uses the same “grid-based” logic as described in my Simple 2D engine article.

    Please note that it’s totally up to you to write a very different Entity system to suit all your needs. Basically, all the 2D grid-based logic is here. Everything else in GameBase should fit any kind of game, be it a platformer, a match-3 puzzle or an hidden object.


    • Loops: preUpdate, update, fixedUpdate and postUpdate
    • Safe disposal mechanic: just call the destroy() of an Entity to mark it as destroyed. It won’t be destroyed instantly, but only at the end of the current frame (the onDispose() is then automatically called), to avoid any null value in the course of the loops.
    • Listing: access Entity.ALL static array for a dynamic list of all existing entities. Note that some might be flagged as “destroyed” (see previous point).
    • Coordinates: each entity uses a grid-based coordinate system. cx,cy are the grid coordinates, while xr,yr are the position inside a single cell. For example, cx=5 and xr=0.5 means “in column 5, at 50% of the cell“. More explanations about this approach in my Simple 2D engine article.
    • Velocities: dx,dy are the current x/y speeds of the entity (added to coordinates on each frame). They also use “grid-based” values. So having dx=0.5 means “moving 50% of a cell on each frame“. dx,dy are multiplied on each frame with frictions which slow them down (if friction<1).
    • Sprite: the visual representation of an Entity is the variable spr. It’s a dn.heaps.slib.HSprite class, which is a super-charged h2d.Bitmap. Please note that the coordinates of this sprite are only updated during the postUpdate(), it’s never updated nor manipulated outside of this loop. If you need the coordinates of the entity object, you should always refer to cx,cy + xr,yr.

  18. The Level Design of Dead Cells


    This article was originally posted on Gamasutra.

    During my time at Motion Twin, I’m was the Lead Designer on Dead Cells, a procedurally generated Metroidvania.

    As you would expect, questions about the quality of our procedural generation pop up very regularly, with both players and other devs. After recent high profile procedural generation controversies, we can’t blame people for being sceptical. This is particularly obvious when talking about a genre that relies on meticulous level design at its core. So we’d like to acknowledge these concerns and take a deep dive into how we’re planning to bring rogue-lite re-playability to a metroidvania. If you’re more a video guy, we also released a “lighter” version (still rather technical (read “boring”) though) of this dev diary on youtube. 

    Before looking at the how of the matter, let’s discuss the why, the reasons we chose to involve procedural generation in a genre known for painstaking level design. 

    At first, about two years ago when we began to design and build a prototype for Dead Cells, we went for the traditional, handmade way of doing things. Unfortunately, we quickly realised that we wouldn’t have the time to do it properly, considering the modest size of our team.

    From there, we knew we had to find alternatives. Before Dead Cells, we had already done quite a lot of browser games, most of them involving randomized elements and procedural generation so we were already quite familiar with the core concepts of procedural generation. On top of this, great use of procedural generation was being shown off by a bunch of critically and commercially successful games: Isaac, Minecraft, Starbound, etc. In light of this, it seemed like an obvious choice to at least build a prototype to test out the idea for Dead Cells. 

    And it worked well, bringing more replay value, a significant improvement for a game with any type of permadeath mechanic. Even better, we found that it fundamentally altered the feeling of the combat of the game, placing the emphasis on the player’s instincts and reflexes rather than relying on rote learning a level in order to progress. Overall, it felt really good.

    There was of course a catch. While the core gameplay feeling was improved by the freshness of new enemy placement, the level design took a great big hit. In short it was illogical, chaotic and left you with no feeling of consistency or immersion in the world.

    Not satisfied with either full handcrafting or full procedural generation, we could feel that there was a way to find a middle ground that would work. 

    Here, we’d like to thank the guys behind Spelunky, who came up with some interesting solutions to the same problem. You can find a brief explanation of how that works here, if you’re interested. But to sum it up, they used a hybrid approach between procedural generation and handmade levels, giving them that consistent feeling while maintaining a lot of diversity. 

    Before we get into the technical details of how this hybrid approach is implemented in our game, I want to mention two other sources of inspiration for Dead Cells.
    The first one is Faster Than Light, which we regard as a model when it comes to a game allying procedural generation with a well orchestrated plot and a very consistent universe. 

    The second one is Left For Dead. Unexpected right? Well, it’s something of a trace left over from “that time Dead Cells was a zombie tower defense game” but we definitely took some lessons from their underlying ideas. In LFD, Valve designed the levels to be dynamically modified through its “AI Director” system. Have a look over here for the basic explanation of the concept, it’s really quite interesting. 

    At the time, we began to develop our own “AI Director”, adapted for Dead Cells. While there is very little of that AID in the current version, we kept the underlying philosophy: building the level’s generation system around dramatic peaks and relaxing “breaks” to ensure an interesting game pacing and keep the player enthralled.

    So to sum up, the challenge was to build a partially procedurally generated world to create a feeling of change and diversity, excellent replay value and difficulty which is based on the players reaction to an evolving situation rather than rote learning. And we had to do this while keeping a feeling of consistency between runs and levels. Learning from previous games, and after many trials, errors, adjustments and a stack of tweaking, we’ve got six steps that we hope will help you approach procedural generation with quality level design as the underpinning rule.

    1. First, we place the fixed elements, acting a bit like a frame in which the procedural generation can express itself. The overall design of the map of the island, how the different levels are interconnected, where the keys to unlock new paths for your future runs are located etc. All of this never changes no matter the loaded variant (seed) of the game. In short the overall world layout is fixed and designed by hand.

    2. Then we hand design a bunch of level “tiles” chunks of carefully designed rooms with a certain amount of variations possible in each of them depending on their configuration. Here’s some examples of the CastleDB software we use to create the tiles:

    In practice, each tile has a specific layout of platforms designed for a specific purpose. A room designed to host a hidden treasure won’t be the same as another hosting a merchant, and both will be very different from the rooms designed around combat. As mentioned there are variations possible in the handmade tiles. These are defined by a handful of parameters, mainly the numbers of entrances and exits available and the room’s purpose. 

    Each room also pertains to a specific biome: for instance rooms used in the prison aren’t reused in the sewers. This allows us to give each level its own strongly defined identity. For example the sewers are very tight, restricting the ability to jump and dodge and forcing the player to think about their mob management.

    3. Ok so we’ve got a bunch of tiles that are fun to play, now we need to arrange them in a logical, interesting way. So we create a concept graph for each level (our “biomes”). A graph is a schematic visual display of the layout of the tiles inside a biome, represented here by nodes. We start by placing the entrance and exit of the level, then we add the special rooms (treasure, merchants, etc.) and finally the tiles in between where you fight and explore. 

    This graph acts like a set of instruction to the procedural generation algorithm describing the: length of the level, number of specials tiles, how much of the biome will be a labyrinthine, how many tiles separate the entrance from the nearest exit, etc. Again, each biome has a different graph to make it consistent with the part of the island it’s supposed to represent. For instance, we made the ramparts much more straightforward and linear than the sewers. 

    4. Only once we’ve laid down all of these constraints and set out the overall level design do we let the procedural generation algorithm loose… For each node, the algorithm tries a random room, among the ones dedicated for this particular biome, and tests to see if it complies with the instructions given by the graph (location and number of entrances, type, etc). If it doesn’t match, the algorithm tries another room until it finds one. And voilà! But wait… there’s more. 

    5. Next comes the reason to keep looking around. You need something to fight. The number of monsters in one level is defined by the total length of the combat based tiles in the level. Taking some random numbers, let’s say we have 250 combat based tiles in a procedurally generated sewers level. We then define the number of monsters that should appear per combat tiles, so say for example it’s 1 monster for every 5 tiles, you’ll have 50 monsters to place in the level.

    Each type of monster has its own constraints and parameters: for instance, some monsters being more dangerous than the others will count for 10 tiles, some can’t be used more than once per tile or level, some can’t be with other monsters on the same platform, some are placed where there is a lot of space to move and fight, etc. 

    6. The final step is to generate the gold, cells and loot, but the recipe for that is kept secret. Legend has it that each dev only has access to one file controlling one loot in order to avoid abuse…

    Well, congratulations for making it through the wall of text trial! We shared our method here, in the hope that someone else will be able to get something out of our take on procedural generation. I’m also hoping to encourage others devs to take risks – like wedding two seemingly incompatible ideas. Sometimes, it might just work.  

    If you have any questions or ideas, just leave me a comment and I’ll be glad to get back to you as soon as I can.

  19. Part 1 – Installing Haxe + Heaps


    For this guide, I will presume that all Haxe related files will be installed in the c:\HaxeToolkit\ directory. Make sure to update the paths if you install your files somewhere else!



    Haxe is a cool programming language that can compile to multiple platforms. It’s free and open-source.

    Install it (including Neko) to a folder like: c:\HaxeToolkit

    Important: for the next sections of this tutorial, I’ll assume Haxe is installed in this HaxeToolkit folder.

    After the setup, you should have the compiler and all the standard libraries in: c:\HaxeToolkit\haxe.

    Does it work?

    • Open a command line,
    • Type haxe, you should see something like that:

    If you get a “file not found” error:

    1. reboot,
    2. check again,
    3. if it still doesn’t work, re-install.



    Hashlink (HL) is Haxe virtual machine. We use it to build cross-platform titles.

    Install it to the Haxe toolkit folder: c:\HaxeToolkit\hl

    Important: you must add all the Hashlink (hl.exe) folder to your PATH environment variable (how?).

    Does it work?

    From a command line, type hl:

    If it doesn’t work:

    1. reboot,
    2. check again,
    3. if you get an error, type where hl,
    4. if you get an unknown command error, check your PATH environment variable.

    Installing Heaps

    HeapsIO is a free open-source 2D/3D engine used in large game projects, like Dead Cells, Northgard or Evoland 2.

    The engine is actually a library of Haxe (ie. an Haxelib) which can be installed easily using the bundled haxelib.exe tool.

    From a command line, run the following command:

    haxelib git heaps 

    Important notes:

    1. we won’t use the default haxelib install heaps command here, because the GIT version is much more up-to-date than the haxelib repo (don’t ask me why)
    2. we also don’t use the official Heaps latest GIT because it’s often unstable. My version is the same as the official, but a few commits late, where it should be stable.

    Installing other important Haxe libs

    From a command line, for DirectX support in HashLink:

    haxelib install hldx

    For OpenGL/SDL support in HashLink:

    haxelib install hlsdl

    You can check the installed libs by typing:

    haxelib list

    Working with VSCode (recommended)

    VScode is a nice IDE that features full Haxe integration if you install the dedicated extension. Out of the box, you’ll get code completion, easier project setup, debugging & much more.

    Please note that you can do that from the extension panel. See below:

    Use the built-in extension browser to get latest Haxe Extension Pack

    Making a game

    Now everything is ready, we can take care of the most interesting part: making an actual game using my GameBase.

  20. Going rogue!


    TLDR version:

    I left Motion Twin, the game company I worked at for about 18 yrs.

    I’m now becoming a full-time indie game dev, and it feels really great! :)

    Read the announcement on Twitter

    A little bit of history: the F2P era at Motion Twin

    Different Motion Twin logos from the last 18 years

    I started working at Motion Twin in 2001: I was hired as a graphic artist to update the art of existing games. But being a coder first, my art wasn’t that great (sic), so I quickly switched back to development, and we hired an actual 2D artist.

    The company was new: we barely existed for only a few months. So we spent a few years trying things, without great success, until we met the CEO of, a quite notorious French website specializing on virtual scratchcards.

    Long story short, we discovered the free-to-play (F2P) model with them, and kind-of imported it in France. Prizee and this new business model helped us in gaining a financial independence: for the first time, we were earning our living from making games, and were paid by players instead of publishers or pro clients.

    We spent the next ~10 years creating tons of web games, from simple match-3 titles (Swapou), or pokemon-like titles (DinoRPG) to more hardcore things like Hordes, Intrusion or Alphabounce DSi.

    But the web as we knew it was about to collapse with the arrival of the first iPhone.

    We tried to make a few mobile games (Uppercup Football, Monster Hotel) but we quickly realized that creating F2P games on mobile was waaaay different from making F2P for the web.

    Hey, please note I don’t want to sound like the old guy bragging about how better the good’ol times were, but… Seriously, web F2P was pretty much all about gameplay & making an actual good game, mostly because you had some level of control on traffic sources & user acquisition. Mobile F2P on the other hand was (and still is) all about data: ARPU, user-optimizations, funnels, retention, and basically, any stupid idea to make players pay on a daily basis. If you know what a “daily quest” is, you certainly know what I’m talking about.

    Damn, I think I sounded like an old guy bragging.

    Dead Cells

    I already talked a little bit about the story behind the game before, so let’s just say that this project was a real game-changer for Motion Twin and saved our asses from the F2P shift.

    I was the lead on this project, and honestly by this time, I couldn’t have imagined what the success of this game would be.

    For us, making a PC game wasn’t the easiest way to leave the web market. The name “Motion Twin” didn’t mean anything to people outside of France, and Dead Cells was our very first Steam title.

    Furthermore, the early access thing was a really intimidating experience for us. You know, it was Indiepocalypse everywhere, and Steam was over-crowded and dying, according to everyone. So, going all-in on this platform sounded like a very risky move to many people. Including us. The company was in a very bad shape, and failure would have probably let to destruction.

    At first, our sales expectations were around something like ~20k units during the first few months. We actually sold ~100k units on the first week. As of today, the game sold more than 2.5M units across all platforms. These results were absolutely crazy…

    To me, working on Dead Cells was probably the best time I ever had at Motion Twin: we were a dream team, players loved the game and Dead Cells was trusting the top charts.

    Dealing with the early access

    This success put higher expectations on us. We wanted to deliver the best possible game: that meant giving everything to it.

    This update was called The Brutal one for good reasons: it was probably one of the most ambitious change of Dead Cells.

    To meet these expectations, we planned monthly major updates during the early access, which meant “make big changes but don’t change things too much”, from a marketing perspective. So to me, everyday was a delicate balance between fixing the gameplay, following the vision and listening to the community.

    And boy, that was a complicated task!

    We didn’t crunch a lot, though ; maybe a few weekends by the end of the early access, but that was it. But I was basically thinking about Dead Cells all the time. During work hours, evenings, weekends and holidays. Every time I wanted to make a major gameplay change, I knew that the other devs would be waiting for me. So I kept myself under-pressure to deliver a good game while sticking to the deadline. That was pretty intense for everyone. Maybe too much.

    “Next project 2019”

    After the release of Dead Cells in 2018, we kept working on a few big free DLCs and updates for about 1 year. We then decided to give the baby to a (kind of) new company, Evil Empire, created by a former Motion Twin member, Steve Filby. You can read the announcement on Steam.

    We then decided to switch the main team (aka. Motion Twin) to a “Next Project” research phase. The broad idea was to create multiple small prototypes, in game jam way, to find an unifying idea. Things didn’t go as expected: designing all together a new large project from scratch proved to be a huge challenge.

    The unique cooperative approach of Motion Twin is, in my opinion, the perfect tool to make people work together in a human centred environment and raise the overall final product quality. But it was clearly not the best tool when all we needed was to define a robust creative vision that would serve as a base for a large project.

    Actually, before Dead Cells, all our previous games were actually small projects initiated by 1 or 2 people in the team, that grew larger as they left pre-production phases. Even Dead Cells started like that: I created the core concepts, Thomas Vasseur was experimenting with the art & rendering, and we basically started this roguevania as team of 2. Then the rest of the team started to join, driven by production needs.

    After Dead Cells, the team wanted to create the next game all together: we wanted to try to have a global vision by making 8 people getting in tune with each others. Seemed like a complicated task, if you asked me back then, and, damn. It was.

    During this “Next Project” period, I built about a dozen prototypes (game design, code & animations, while the background art was mostly bought from, but none was validated to turn into an actual Motion Twin game. Of course, I wasn’t the only one to create prototypes, but nothing was promoted to an actual global project.

    As months passed by, and nothing happened, my relations with the team became more and more complicated. So complicated, actually, that it ultimately led to my forced departure, as I was asked to leave in December 2019.

    Background art credits: Cavernas by Adam Saltsman, Inca by Kronbits, 8BIT top down by Canari Games, Gwenaël Massé.

    What now?

    Trying to create the post-“Dead Cells” game was a very stressful task, and it now feels incredibly great to be able to think about smaller scope projects. “Smaller” doesn’t mean I plan to work on very small experimental games though: I still want to release complete titles and I still plan to sell them on Steam, or other markets ;)

    Right now, I’m eager to start working on 2 game projects I’ve been thinking about a lot. I also plan to update RPG Map, including a possible Steam release, if it’s accepted on the store. And of course, I have Ludum Dare and other game jams :)

    I also updated the games page to list all projects I’ve worked on at Motion Twin and, before that, on Atari ST. It was a very interesting introspective thing to do: good to look where you’ve been, to decide where you’ll go next.

    Last but not least, I want to come back to things I left years go: taking active part in open communities. Being a Haxe developer, my first focus will probably be the game dev community gathering around this language, by helping newcomers getting onboard.

    I honestly feel great today. The success of Dead Cells gave me some legitimacy which will certainly be useful in the near future and I’m super excited to start working on personal stuff.

    So, expect new things in the next few months, I’ll keep you updated on my Twitter :)

  21. Game feel demo (v1, ENJMIN 2019)


    Please use the newest version available here.

    This prototype is not exactly an actual game. It was developed to serve as a demonstration for a “Game feel” talk in 2019 at the ENJMIN school.

    It shows the impact of small details on the overall quality of a game.

    You will need a GAMEPAD to test it. You can enable or disable game features in this demo by pressing the START button.

  22. Sabotage



    This is the post-compo version of my Ludum Dare 45 game: Sabotage.

    Changes include:

    • better controls
    • HUD
    • auto-pick some items (keys & healing)
    • balancing


    You are Colonel Jean-François Hubert from the French army. As the most badass colonel ever, you take on your missions naked, without any weapon.

    Improvise, adapt, overcome.

    Sabotage is my Ludum Dare 45 entry. It was created in about 72h using Haxe language. The theme was “Start with nothing”.


    Music by David Whittaker, from the game Leatherneck (Atari ST version)


    You start with absolutely nothing: use the environment to kill enemies. 

    Play using keyboard or a compatible game pad (Xbox controller recommended).


    • ARROWS – move around
    • SPACE – grab/use an item
    • ESCAPE – release current item
    • R – restart current level

    Gamepad (xbox controller)

    • LEFT STICK – move around
    • A – grab/use an item
    • B – release item
    • SELECT – restart current level
  23. Sabotage (72h version)



    You are Colonel Jean-François Hubert from the French army. As the most badass colonel ever, you take on your missions naked, without any weapon.

    Improvise, adapt, overcome.

    Sabotage is my Ludum Dare 45 entry. It was created in about 72h using Haxe language. The theme was “Start with nothing”.


    Music by David Whittaker, from the game Leatherneck (Atari ST version)


    You start with absolutely nothing: use the environment to kill enemies. 

    Play using keyboard or a compatible game pad (Xbox controller recommended).


    • ARROWS – move around
    • F – grab an enemy or an item
    • SPACE – punch (if your hands are free)
    • SPACE – use item in your hands
    • R – restart current level

    Gamepad (xbox controller)

    • LEFT STICK – move around
    • A – grab an enemy or an item
    • X – punch (if your hands are free)
    • X – use item in your hands
    • SELECT – restart current level
  24. Save & Sacrifice



    You are the Supreme Lord Commander of the Heavens, which is kind of cool.

    Hell is on Earth, and you were sent down there to save your fellow worshipers. Well, actually, your contract says you should at least save ONE worshiper in each area.

    The other might be sacrificed for the greater good.


    Play using keyboard or a compatible gamepad (xbox controller recommended).


    • ARROWS – move around
    • UP – jump / use wings
    • SPACE – kick
    • R – restart current level

    Gamepad (xbox controller)

    • LEFT STICK – move around
    • A – jump / use wings
    • X – kick
    • SELECT – restart current level
  25. Dead Cells


    I created Dead Cells, as lead game designer and lead developer.

    The game was developed using Haxe language, HeapsIO engine and my GameBase code.

    The concept is born from the ashes of Hordes Zero, a multiplayer tower defense game for web & mobile, featuring coopetition (play together, but only the last survivor gets a reward). This early project even had a public Alpha version, but it proved to be a really big failure: not fun, no clear vision and tons of gameplay & balance issues.

    An ingame screenshot of the last “tower defense” version of the game, before it was sliced down to a single player Castlevaniesque adventure.

    We basically decided to cut every single aspect of the project that we were not confident with: mobile, cross-platform, multiplayer and last but not least, tower-defense.

    This was a “last chance” move to save the project (and the company, we were not in a great shape) from obliteration. It was also the moment we decided to go “all-in” on Steam & PC, which was something completely new for us.

    The final product is quite different from the original idea as you can see ;) We decided to call it a Roguevania, because it sounded cool, it was quite close to the actual game concept and because no one could stop us from doing stupid things.

    One would say this change from Tower Defense to Roguevania was a good move, as the final game sold more than 5M units on all platforms and won the Best Action Game award, during the Game Awards in 2018.

    A very early mockup of the game, when it was still a top-down tower defense in a modern world.

    Early prototype

    Tower defense prototype

    Pre-production prototypes

  26. Blossom


    If everything is lost, try to plant a seed.

    This is my Ludum Dare 42 entry! You are a tree. Try to escape pollution by growing away, planting seed and picking magic stars that will clean up some dirt.

    Please note that I made it in about 9h, and partially during a flight between Taipei and Paris. So don’t expect much here:

    • no sound,
    • no music,
    • no proper ending :)
  27. Nightclub Showdown


    Don’t aim. Shoot quickly. Then go for the head and finish the job.

    — John Wick

    This is the post-compo version my Ludum Dare 41 entry! It features :

    • the ability for you to grab enemies to use them as cover!
    • a new enemy type (strong big guy),
    • a better UI,
    • updated music & sfx,
    • an extra combat area,
    • balancing.

    If you intended to vote for Ludum Dare 41, please rate the original jam version.

    Making of video
  28. Nightclub Showdown (original 24h version)


    Don’t aim. Shoot quickly. Then go for the head and finish the job.

                                                           — John Wick

    This is my Ludum Dare 41 entry!

    My goal here was to try mix turn based and fast action. I drew a lots of inspiration from John Wick movie & gun fights :) This game is quite special to me as I only created it in less than 24h! Much happy.

  29. Cats are assholes


    Praise the cats, hooman.

    A shelter simulation game made in 3 days for Ludum Dare 40. Even if the game was submitted to Jam instead of Compo, I still made everything all by myself.

    All you have to do is to take great care of your beloved stray cats. If you fail, they will eat you, plain and simple. Make sure the fridge and the bowls are always full of fish, empty the litter boxes, buy extra equipment and upgrade your existing fridge capacity.

    Be sure to use Mark, your grandson, as often as possible! That’s basically how you do multi-tasking in this house.

    Making of timelapse
  30. Zero Volt X



    Manage your ship power distribution while avoiding thousands of bullets!

    A 48h shooter I made for Ludum Dare 39 gamejam! The theme was “Running out of power”. Once again, this game is actually the second one I made during a single gamejam weekend. I cancelled the first one because it wasn’t fun at all, so I decided to switch to a shooter with a fast paced gameplay like old-school ones :)

    Source code of a canceled LD39 entry: GitHub

    How to play

    Distribute your generator power to your ship sub-systems.

    • max out the Shield to regen it when you get hit,
    • max out Gun to increase damage in front of you,
    • max out Missiles to throw dozens of homing missiles around you!