This website uses cookies to improve user experience. By using our website you consent to our use of these cookies in accordance with our Privacy Policy. X

A modern, yet classic sci-fi roguelike,
spiritual successor to Doom, the Roguelike.

An epic battle of a lone marine against the forces of hell,
taking place on the moons of Jupiter.

Coming to kickstarter in November!



Jupiter Hell development live on Twitch!

After a successful test stream we decided to go ahead and take a shot at streaming development live. Additionally I will answer any questions on stream in a mini-Q/A, and do a small intro into parts of the project. 

EpyonCF at 

First stream - Tomorrow (28 September), 18:00 CEST, 9am EDT, Noon PDT (convert time).

We're not sure whether this will become a regular stream, or just a few separate events, but this is the first time you'll be able to see glimpses of the game in action! 

Dev Talk #1 - Physics, part 1

Welcome, in what I hope to become a regular series, the first Dev Talk article. In this series we will try to cover various topics related to the down and gritty development of Jupiter Hell. While this post is rather a overview talk, accessible to everyone, we might venture more deeply into some topics at a later stage: I'll make sure to mark those posts with a appropriate "Here be Dragons" warning sign.

In this first post, I'd like to delve into my work from the past two weeks, where I tackled the basics of the last missing major subsystem of Jupiter Hell's engine code - namely Physics. After much research, we decided to go with Bullet Physics, due to its stability, liberal open source license (zlib), and it's proven track record in prior game integrations. Two weeks in I'm more or less happy with our choice - my only real disappointment was the almost non-existent documentation (40 page manual for multi-megabyte source Physics library?) and outdated examples (good luck trying to find a modern Ragdoll example with skinning).

You might ask, why do we need Physics in a grid and turn based game? That's a valid question! Up till now, there was really no need to have neither a physics library, nor even collision (Bullet handles both), precisely due to the grid/turn based nature of our game. The animation system (which I'll write about in some future Dev Talk post) is based on procedural techniques and for the most part doesn't need any physics integration.

However, multiple systems in the game would benefit from visual enhancements that could be brought in thanks to a physics library. Note the "visual" in the previous sentence: no gameplay system is affected by Physics in any capacity. The way we created the game, physics calculations in the game have no tangible effect on the gameworld. We will use physics to illustrate gameplay effects, not determine them. This has several benefits - we don't need to store physics information between saves, game replays will be unaffected (no need to synchronize), and we can turn on/off the physics system without any gameplay effect. The last two allow replay storage as a simple sequence of commands.

Let's get into details, illustrated by some basic gifs from the engine integration tests (not in-game yet -- see an upcoming post for that!).

So what do we need physics for?

Explosion object physics

Let's be frank - a big part of DoomRL and consequently Jupiter Hell is blowing things up. While we can use particle effects and billboards to render nice explosions, nothing is as satisfying as game world objects making up a tile (imagine a stack of crates) flying in all directions after a careful rocket launcher shot. This effect is present in many games, Jupiter Hell however presents one bonus, and one caveat. 

The bonus is our fully dynamic lighting system which not only will make sure that every object in flight will cast a dynamic shadow, but also the explosion itself will cast proper shadows. 

The caveat is that due to the grid/turn based nature, a tile is either passable, or impassable, there is no middle-ground. Hence, a tile must be blown up or not touched at all, no middle-ground. Once you blow up a tile, all tile elements that scatter will be treated as not taking up space, no matter how they block a given tile. We're still thinking on how to solve that in a way that won't introduce ugly visual glitches.


Even if we make a dozen death animations for each of the enemies (which would take a lot of time!), they would get very repetitive in a game that's supposed to offer tons of replayability. Ragdolls are the only solution to make death animations differ significantly, and go in the fun procedural spirit that we want to maintain in all Jupiter Hell solutions. Sure, they can produce unintentionally hilarious situations from time to time, but given the procedural nature of our game I believe this is acceptable and even encouraged.

Don't be discouraged by the poor behavior of our current ragdoll setup, it's a quickly hacked doll that doesn't fit the mesh very well yet :).

Ragdoll animation refinement

Most of the games that use ragdolls limit their use to death animations and corpse dragging. Due to the procedural nature of our animation system we came up with the idea of controlled blending of ragdoll effects with our pose blending. While this can be used for a variety of effects, the obvious use is the "being hit" animation. Similarly to the death animation, instead of using a fixed set of animations, we can try to generate ones on the fly, that fully take into account the exact pose the character is in at the current moment. This system needs a ton of tweaking to get it to look right (and a way better ragdoll), but I think that in the end it will look pretty good! Here's a quick test of the idea in action:

Procedural destruction

One of my big dreams is making the whole environment in Jupiter Hell fully destructible (like it was in DoomRL). In a 3d world however this is an extremely difficult task if we want to make it look good. Sure, we could just substitute a destroyed tile with it's "destroyed" model, but that would in our opinion look pretty bad in contrast with the visual quality of the rest of the game. We do plan on making most of the scenery elements destructible (crates, doors, etc.), however full environmental destruction that includes all walls will probably be a Kickstarter stretch goal.

The temptation to do full destruction is huge though, as we do not pre-calculate any vision data, or actually anything at all -- the light and shadow play on walls falling apart would be something to behold!

Hence, I've been researching on how to make such destruction look good, and one of the cheaper (relatively) techniques is Voronoi shattering, illustrated by a very simplified example below.

Still, this technique requires a lot of preparation and additional code, including (but not limited to) - object layers, internal textures, runtime subdividing the model into convex shapes, runtime UV coordinate recalculation. After the above test, I'm pretty sure I can pull it off, but there's a long road before I can get any of that into the game.

On this note I conclude this Dev Talk. We need feedback! Both on what we talk about here, and about the games progress. Also, at this moment most importantly, did you enjoy this article? Do you want more such technical rants? Should they delve deeper into technical aspects, or should they be more of a feature discussion and rant for everyone to enjoy? 

Let us know on the forum!

Roguelike Radio: Interview with Kornel Kisielewicz

Thanks to Darren Grey from Roguelike Radio, we can link you to a pretty long interview about ChaosForge games new and old - learn about the origins and design decision of DoomRL, AliensRL, and other CF roguelikes, as well as (at the end) a bit about Jupiter Hell too!

Roguelike Radio: Episode 112 - Interview with Kornel Kisielewicz


Jupiter Hell is a roguelike set in a 90's flavored sci-fi universe. Set on the moons of Jupiter, the game pits a lone space marine against overwhelming demonic forces. Rip and tear zombies, demons and unmentionable monstrosities, using classic weaponry, including (but not limited to!) shotguns, chainguns, railguns and the trusty chainsaw. All to the shine of CRT monitors and the tune of heavy metal!

Dive deep into a true form of the 30 year old roguelike game genre that has resurged in popularity. Experience turn-based, grid-based permadeath and fully procedural levels, all in glorious 3D visuals. Get ready for the spiritual successor to DoomRL, the parody roguelike that years ago streamlined the traditional format and popularised a new wave of accessible roguelikes. Distilled, hardcore gameplay, fast-paced challenge and limitless death all await.

Welcome to Jupiter Hell.



  • Permadeath adds tension and significance to gameplay decisions
  • Turn-based and grid-based world to emphasise tactical decision making
  • Procedural environments mean you never know what’s lurking behind the next corner
  • Brutal but fair difficulty will have you constantly coming back for more

Fast-paced Gameplay

  • Dynamic turn-based action with adaptive animation lets you play at your own pace
  • Intuitive UI for clear and fast decision-making
  • Streamlined gameplay centres on the action instead of menu micromanagement
  • Action-centric game flow with repeated peaks of blood-stained joy

Expert Procedural Generation

  • Sadistic algorithms create unending challenges
  • Randomised missions intertwine with adaptive plot arcs for continuous variety
  • Generated events and environmental interactions keep you constantly engaged
  • Built upon decades of expertise in producing truly engaging procedural content

Ruthless Enemies

  • Highly varied enemies require different strategies to beat, especially in combination
  • Unique enemy behaviours and skills
  • Legendary boss battles that will test your worth as a player
  • Advanced difficulty modes and special challenges for the most masochistic players