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).
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:
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 https://www.pushsquare.com/news/2023/06/dead-cells-dlc-planned-until-2025-as-game-sells-10-million-copies, or google it)
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?”
Everything.
Absolutely everything man.
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.
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.
This is not an actual game, but a proof-of-concept prototype that implements a retro/modern “Dungeon Master” engine:
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.
To use it, just fill in the required information:
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.
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.
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 :)
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.
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 :)
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).
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.
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 ❤
I’m now legally allowed to make, publish and hopefully earn money from games.
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.
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 “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 GetText implementation has 3 elements:
If you want to use the GetText lib for Haxe, you will need to install it:
haxelib install deepnightLibs
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.") );
}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.
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.
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!
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?", { name:user.name });
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.
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:
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.
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
Optionally, you can also you the latest GitHub version using the following command. Be careful though, as it might be unstable.
haxelib git redistHelper https://github.com/deepnight/redistHelper.git
haxelib git deepnightLibs https://github.com/deepnight/deepnightLibs.git
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.
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)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
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!
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 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.
While Flash is supported, it’s not super useful here, as the SWF file is already a package in its own.
You have 2 ways to push an app on Itch.io:
If you install it, Butler can be used right from the command line to upload your fresh new build to itch.io 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 itch.io 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.
This Google spreadsheet will help you to keep track of time spent on your projects:
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!
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.
Every time I start working a new game, I use “GameBase” as a starting point. It uses the Haxe language and the Heaps.io 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.
First thing first, here is the official GameBase repository on GitHub:
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.
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 https://github.com/deepnight/deepnightLibs.git
Also install CastleDB lib (a simple database for Haxe games, see castledb.org):
haxelib git castle https://github.com/ncannasse/castle.git
Just go to the repository on GitHub and click on the Use template button. Learn more about GitHub templates here.
Go the following GitHub repository: https://github.com/deepnight/gameBase
Just fork this repo and clone it on your computer. Feel free to adapt/edit/copy for your own usage (see LICENSE).
This method is mostly for my own usage, as GitHub doesn’t allow me to fork my own projects.
git remote add gameBase https://github.com/deepnight/gameBase.git git pull gameBase master git push origin master
git remote add gameBase https://github.com/deepnight/gameBase.git git pull gameBase advancedBase git push origin master
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.
You can build for other platforms:
haxe build.directx.hxml (recommended)haxe build.js.hxmlhaxe build.opengl.hxmlPlease note other platforms could be targeted by creating a corresponding HXML file (see: https://haxe.org/manual/target-details.html).
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:
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:
_base.hxml at the bottom of VS Code window.build.dev.hxml, which is Direct X with added “debug” flag). 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) {
super(x,y);
// Some default rendering for our character
var g = new h2d.Graphics(spr);
g.beginFill(0xff0000);
g.drawRect(0,0,16,16);
}
}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() {
super(Main.ME);
// [...]
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) {
super(x,y);
// [...]
ca = Main.ME.controller.createAccess("hero"); // creates an instance of controller
}
override function dispose() { // call on garbage collection
super.dispose();
ca.dispose(); // release on destruction
}
override function update() { // the Entity main loop
super.update();
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.
tmod is a value connected to the duration of the frame, and more precisely, the time elapsed between two consecutive game frames.
tmod can be used to adjust values that are FPS dependent, such as velocities or accelerations.
The idea is:
See Delta time to learn more about this classic concept.
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.
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:
update() which takes care of low-level stuff. You shouldn’t do much here, unless you have very specific needs.update() too, and is basically your global app main update. It also has a postUpdate() which happens after the update().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).
All code files are in /src folder.
Main.hx: the main app loop, see the update() methodGame.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 systemLang.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.import.hx: note the lowercase format of this file name, it allows to have global imports for every classes of your app (see: https://haxe.org/blog/importhx-intro/). 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.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.
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.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.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).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.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.
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.
haxe, you should see something like that:
If you get a “file not found” error:
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?).
From a command line, type hl:
If it doesn’t work:
where hl,
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 https://github.com/deepnight/heaps.git
Important notes:
haxelib install heaps command here, because the GIT version is much more up-to-date than the haxelib repo (don’t ask me why)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
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:
Now everything is ready, we can take care of the most interesting part: making an actual game using my GameBase.
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! :)
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 Prizee.com, 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.
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.
This success put higher expectations on us. We wanted to deliver the best possible game: that meant giving everything to it.
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.
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 Itch.io), 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é.
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 :)
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.
This is the post-compo version of my Ludum Dare 45 game: Sabotage.
Changes include:
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).
Keyboard
Gamepad (xbox controller)
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).
Keyboard
Gamepad (xbox controller)
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).
Keyboard
Gamepad (xbox controller)
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.
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.
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:
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 :
If you intended to vote for Ludum Dare 41, please rate the original jam 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.
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
Distribute your generator power to your ship sub-systems.
Castle Of Deception is a 24h jam game created during the “Geekopolish Jam” (as part of a french event called “La Grande Confiture de Jeux“).
The game is a puzzle platformer in which you can (and are encouraged to) cheat, using developer tools.
