Development Update: May 14th, 2018

Quick Update Stuff

Coding is on schedule. I worked out the kinks in the random level generator, see below.

Art is coming along nicely. I got the combat UI two days ago and we made several improvements to the status UI. All but two of the combat animations are complete. Urimas is currently finishing item icons, and Chicken needs to get me 1 more enemy design before I can finish up Serenity Crater.

The Random Level Generator

I just finished putting together the basic exporter for the RLG. It still needs to generate useful enemy and object data, but the really complex texture mapper is complete.

The RLG was designed to be used in both auto and manual modes, to better allow me to identify bugs. So, here’s screenshots of it in action. To use the RLG, you just press the number keys and the generator stops at each stage.

Stage 1: Rolling Sizes


Not much to look at, but the red border indicates the sizes. You can use the arrow keys to scroll around in-game.

Stage 2: Generate Rooms


Here we have generated the ‘rooms’, which are just core points. The rooms are not necessarily connected. The green dots represent a room center, and the rectangles mean a room is elliptical.

Stage 3: Tunnel and Distance Check


Next, we “dig” between each room. Starting at the entrance (white square) we mark all connected tiles. If a room’s center is disconnected, the closest room is found and we dig a 1-tile wide tunnel to the nearest connected room, and then run the algorithm again until no rooms are disconnected. This guarantees it’s always possible to navigate to each room.

Stage 4: Spawn an Entrance


Here we have moved the entrance point to the top middle white square. This is because the entrance is always on a north wall, as it’s a ladder. An exit was also generated but is not yet marked on the map, as well as treasures being generated.

To generate the exit, we take a position that is 75% or more of the maximum distance away from the entrance ladder and modify it to be an exit. You’ll see it on the screenshot below.


To generate treasures, we find the shortest path between the entrance and the exit. The exit is in the bottom middle. Then, we take all locations on the map that are 17 or more tiles away and make them treasure candidates.

Treasure candidates are selected with weight being placed on the most distant ones from the shortest path. Sometimes a candidate is picked that is closer, but it’s usually an edge tile. Then, we find the shortest path between the treasure and the entrance-exit axis and mark it, and then find the distance for all tiles and this new, branching path. Then we run the algorithm again until there are no more tiles that are 17 or more spaces away from any path. The result is the above diagram.

Stage 5: Texture Everything


Programmatically the most complex part, the program checks pit, wall, and floor values and assembles texture data for the renderer. Now you can see how it’s an actual level with pits and walls. Presently the RLG does not place interesting objects and doodads, but it will later.

Stage 6: Generate Enemies


Enemies are purely object data and could theoretically be generated externally, but I decided to build their paths directly into the generator. Essentially, each room is given a priority value and enemies are rolled to spawn in each room. Each time a room gains an enemy spawn, it decreases in priority. The enemy will then mark a path to another room selected at random, decreasing its weight as well. Thus the enemy population is distributed fairly evenly amongst the rooms with some getting little attention by sheer chance.

Note that these are path candidates, and most levels will not have a full complement of enemies. Towards the bottom of the mines, you can expect all the slots to be filled, though. Waiting around corners and ambushing isolated patrols is still the best strategy.

So that’s my random level generator. I’ve already hooked it in to the game’s engine, I just need to generate objects and then I can finish the other half of the Tellurium Mines’ scenario work.

Prototype 5-2 Objectives

When everything is checked off, it’s release time, baby.

  • Serenity Crater (Mostly Done)
  • Tellurium Mines (In Progress)
  • Text Adventure Subquest
  • Golem Transformation images (Done)
  • Latex Drone Transformation images
  • Enemies for Serenity Crater (Mostly Done)
  • All running animations completes (Done)
  • New UI Overhaul (Mostly Done)
  • Eldritch Dream Girl Transformation (Text only, Complete)
  • Work Credits System implemented and balanced
  • Next balance pass of Chapter 5 (In Progress)
  • Darkmatter Girl Transformation (Text only, no images – Being Edited)
  • Electrosprite Transformation (Text only, no images)
  • Steam Droid Transformation (Text only, no images)



Development Update: May 7th, 2018

Programming Stuff

I do so love getting sick. I only spent about three days last week actually working on Pandemonium. But here’s some of what I got done.


I have almost finished the level generator’s basic parts. It still needs to generate treasure and enemies but it currently generates entrances and exits and does so fairly naturally. The entrance is in the top middle and the exit the bottom right. Exits are generates at 75% or more of the maximum walkable distance in the map, which means I can put treasure at the 95% mark and enemies in between.


There is a 10% chance that the level generated will be a cavern. Here, pits account for most of the blockers as opposed to walls, but the other properties are exactly the same. It provides visual variation.

I do intend to put in more types of generators to give more variety, but I’ll retrofit those later. This week I will be adding treasure, enemy patrols, and then actually convert the level generator into usable levels.

Artistic Stuff

Urimas has finished the running animations and is now making tiles for the Steam Droid parts of the mines. Once I get those, working on the scenario for the Tellurium Mines is my next objective.

Hund has been working on the combat animations and should be done the main ones this week. He’s now adding coloring and shading. They look pretty darn good.

CocoMint reports that the UI has its parts complete. We’ll be going over the finalized layouts on Wednesday.

Chicken has nothing to report. Shame!

Prototype 5-2 Objectives

When everything is checked off, it’s release time, baby.

  • Serenity Crater (Mostly Done)
  • Tellurium Mines (In Progress)
  • Text Adventure Subquest
  • Golem Transformation images (Done)
  • Latex Drone Transformation images
  • Enemies for Serenity Crater (In progress)
  • All running animations completes (Done)
  • New UI Overhaul (Mostly Done)
  • Eldritch Dream Girl Transformation (Text only, Complete)
  • Work Credits System implemented and balanced
  • Next balance pass of Chapter 5 (In Progress)
  • Darkmatter Girl Transformation (Text only, no images – Being Edited)
  • Electrosprite Transformation (Text only, no images)
  • Steam Droid Transformation (Text only, no images)

Development Update: Running and Map Generation

Game Update

So, I’ve finished the Serenity Crater event sequence. I’m currently waiting on some images from Chickenwhite and I need to fix up some bugs in the cutscenes, but it’s playable start to finish even if there’s no enemies in the area. I’ll probably clean up the bugs and do balancing work this week.

Chicken has finished the Golem transformation images and is now working on the enemies in the Serenity Crater area. It’s not just Darkmatter Girls!

Hund is working on the last two combat animations I need for our prototype purposes. There are lots more to go, but these are for damage types that aren’t in the game yet, like Crusading and Obscuring, so we don’t need them immediately.

Urimas has been working on the running animations. Look below!

Running Animations



Here’s the running animations in action. Your browser will need to be able to play animated gifs, so sorry for that, some mobile users.

Urimas is most of the way done the running animations. A few of Christine’s forms need to get them still, all of Mei’s, 55’s, and Florentina’s are done. These animations will be in v1.05 and Prototype 5-2 when they come out.

Random Level Generator

So I’ve mentioned that the next thing on my work list is the Tellurium Mines. This area is unlike the rest of Chapter 5 in that it is randomly generated by floor. You’ll be doing a lot of quests and subquests in the mines for the Steam Droids, or you’ll be doing them for Regulus City for work credits. Either way, there’s lots to do in the mines.

I’ve started work on the level generator. It’ll take a lot of work to get it making nice levels, since Pandemonium can build fairly complex enemy patrol routes. I’ll probably do a Design with a Grain of Salt post on the random levels when I get a bit further along.


This is the start of the room-and-tunnel generator. The mines will have several generators to pick from, this one is fairly similar to the NetHack style of generating rooms and then linking them together.

Prototype 5-2 Objectives

Here’s what my objectives are for Prototype 5-2 and Chapter 1 v1.05. When everything on this list is checked off, it’s release time baby!

  • Serenity Crater (Mostly Done)
  • Tellurium Mines (In Progress)
  • Text Adventure Subquest
  • Golem Transformation images (Done)
  • Latex Drone Transformation images
  • Enemies for Serenity Crater (In progress)
  • All running animations completes (In progress)
  • New UI Overhaul (In Progress)
  • Eldritch Dream Girl Transformation (Text only, no images – Mostly Done)
  • Work Credits System implemented and balanced
  • Next balance pass of Chapter 5 (In Progress)
  • Darkmatter Girl Transformation (Text only, no images – Being Edited)
  • Electrosprite Transformation (Text only, no images)
  • Steam Droid Transformation (Text only, no images)

I’m not putting a time estimate on Prototype 5-2 at the current date, because I want to get the mines and text-adventure modules in. I had originally wanted just Serenity done, but since the Patrons voted for more significant updates, we’ll be doing all three of the side content areas for the next prototype.

Argue about this post on the forums!

Support the project on Patreon and enable my squid addiction!

Coding With a Grain of Salt: Ray Tracing and Blockmaps

What the hell is ray tracing, and what the hell is a blockmap?

Ray Tracing is the coding technique used to figure out what can be ‘seen’ from object to object. If you’ve ever played a first-person shooter, you’ve experienced a ray-tracer, because that’s how the game determines what parts of the map you can see and what parts you can’t. Objects in the foreground prevent you from seeing what’s behind them.

Ray Tracing is simply tracing a ray. A Ray is a geometry concept, it’s a line that starts from a point and travels in a direction until it hits something. In strict geometry, rays don’t hit things, but in our code they sure do.

Oh, and this would more accurately be called a ‘line-segment’ as opposed to a ‘ray’, because these have a definite end point. But since the code can be generalized to rays and ray sounds a lot cooler, I’m using ray.

Pandemonium uses ray tracing to figure out if an enemy can see you, the player. If the enemy can, they will chase you and trigger a battle. So it makes sense that they wouldn’t be able to see you through walls unless they have x-ray vision.


In this image, I have enabled Mei’s visibility cone to simplify things. The yellow area is what she can ‘see’ while the red polygon represents what she’d be able to see if the walls weren’t in the way. The red arrows are rays, and they collide with the blue lines which represent collisions.

Pandemonium does not simulate verticality. So, enemies cannot see over the water, because they can’t chase over the water. It’s one of those design decisions that makes a lot of sense from a gameplay perspective but not from a reality perspective.

Okay, so what’s a Blockmap?

Raytracing is computationally expensive. In order to see if a given ray impacts a line, we need to run the line-intercept function. It looks like this.

I sincerely hoped you enjoyed that link.

The line-intercept function must be run for every line in the entire map against every ray you want to trace. For Pandemonium, every viewcone is about 120 rays. You can customize the accuracy in the options menu if it causes slowdown. 120 is just a good middleground number that looks nice without being too intensive.

So, if there are 600 lines in a map, and 120 rays per viewcone, then that’s 72,000 calls of the line-intercept function for every entity with a viewcone. 600 is not an unreasonable number of lines, and some of the larger maps have thousands of lines. This gets expensive, quickly.

It sure would be handy if we had a way to only check a ray against the lines it could reasonably impact, as opposed to every line on the map. The rays are short and always focused around the same spot, so an optimization would mean instead of checking against 600 lines, we check against 10.

This optimization is called a Blockmap.

What does a Blockmap look like? How does it work?

Blockmaps simply sort the lines on the map by where they are.


Here we can see a crude overlay which shows what a blockmap might look like. The vertical lines are labelled ABC etc, while horizontal lines are 123 etc.

Block 1-1 contains lines A, B, C, D, 1, 5, and 6. Any line which touches the block at all is considered to be within it. This can be determined with a simple line-intercept function call, and only needs to be determined once. That is, I can compile this data into the map and it never needs to change. Block 1-1 always has the same set of lines in it.

There are 16 vertical lines and 16 horizontal lines visible in this image, give or take the edges. That’s a total of 32 lines. If I had a ray that started and ended in Block 1-1, then I would only need to check 7 lines.  That means the Blockmap speeds up raytracing by about 500%. Five times faster for a simple bucketing algorithm, pretty impressive!

If a ray starts in one block and ends in another block, all you have to do is check all the blocks it hits, which can again be determined via either a line-intercept function or a point comparison. Simply check which block the start point and end points are in, and check those blocks as well as any blocks between them. For a short ray like the one in this screenshot, a ray can be in as many as 3 blocks, which is still considerably faster than checking every single line on the map. The algorithm becomes faster the smaller the blocks are, up to the point where the blocks are so small that the algorithm spends too much time figuring out which blocks the ray touches and not enough checking line impacts. It’s up to the coder to figure out the optimal size, but in Pandemonium it’s about 3-4 tiles squared since the majority of collisions in the game are big square right-angles.

Bonus Optimization: Duplicate Line Check

When a blockmap gets really small, the same lines start to appear in many blocks. It’s theoretically possible for a line to be contained in dozens of blocks, though that doesn’t happen very often in Pandemonium. When iterating across the blockmaps, checking the same line twice is just a waste of speed. What do we do?

The blocks contain references to the lines, which are stored in a single master list. To prevent duplication, we can use a unique ID system.

Every time a ray begins a trace, increment a variable, called mRayPulse, by 1. Every line in the map likewise has a variable, mLastRayPulse, indicating the last pulse they were queried by. When a ray checks a line, set the line’s mLastRayPulse variable to mRayPulse. If the ray goes to check a line, and the line’s mLastRayPulse variable is already equal to mRayPulse, it was already checked and we can ignore it. Thus we avoid all duplicate line checks.

We can also optimize the algorithm a bit by shortening the ray after each impact. Finding an impact is not enough, we need to find the shortest impact, otherwise entities would still be able to sometimes see through walls. Each time the ray impacts a line, we shorten the ray. If a ray going from Block 3-3 to Block 1-1 gets hit in Block 2-2, there’s no need to continue checking Block 1-1 since it has already hit something in between. This doesn’t save much processor time but is certainly worth mentioning.

Can we optimize this more?

Yes! However, it probably isn’t necessary in this case. Blockmaps with a duplication-proof pulse checker are ideal for short rays, such as the kind used in Pandemonium. Rays that are very long, however, are a different species altogether and won’t work with a blockmap.

For very long rays, you need a tree sorting method. If you’ve ever played Doom, Quake, or Half-Life, you’ve played a game that uses one such method: Binary Space Partitioning. This is where all the lines in the level is split into two (hence the term binary) and the two halves of lines are then further split down recursively until all the lines are isolated. The more advanced methods, Quadtree and Octree, do this same technique but use a different splitter to break space into four or eight parts instead of two. The basic principle is the same, though.

A BSP has the advantage of being fast for an arbitrary set of lines and line lengths, while also not taking up much RAM. Blockmaps are very fast for short lines and take up a fairly large amount of RAM relative to their contents, but for long lines they tend to check way too many extra lines.

I will probably do a post on binary space partitioning in the future but for now, this post is long enough and got its point across.

And for all those of you who don’t care about blockmaps but made it to the end of the post anyway: Congratulations!




Development Update: April 23, 2018

Yes, I know I promised a Coding with a Grain of Salt this week. I got called into work. It’ll be up Wednesday. Damn it.


Serenity Crater is completely mapped and 50% scripted. I decided to add more world stuff to examine and characters to talk to, really brings the place to life.

I’ve also added automated texture atlasing to the program. It only actually applies to the sprites. The atlasing is not meant to improve VRAM usage, it’s meant to improve loading speeds, which it does only in the case of sprites. It also improves rendering speed, but Pandemonium has never been rendering speed choked.

I can’t do statically sized atlases because the texture size is limited based on the user’s graphics card and I don’t want users on older machines to have problems. You have to toggle atlasing on, and it only boosts loading speed by about 0.4 seconds. That adds up when you’re like me and run the program 100 times an hour, but I expect only users on older equipment will notice more than 1 second gain.


Hund is working his way through the combat animations. They’re starting to come together. I’ve also updated the combat sound effects using stolen borrowed sounds. They make combat a lot more fun to observe, and it flows much more nicely.

Chicken is most of the way through the Golem TF, and also got us some updated Mei Zombee sprites. The new UI requires full-sized portraits, and Zombee never had one (because Mei cannot enter combat during that sequence). Well, now she does. Patrons will get to see it.

Urimas is currently working his way through the running animations. I’ll be posting some gifs of those next week. They look pretty darn great and really make the game come alive.

Other Stuff

I’m going to outline my project targets in next week’s post. No, we won’t be doing Prototype 5-2 this month, it will probably be in May.

Argue about this post on the forums!

Support Pandemonium on Patreon and enable my squid addiction!

Prototype 5-1 Poll Results

Project Update

So before we get to the poll, on the coding front I’ve added the backend for the new animations and updated some of Chapter 1’s scripts to use the new formats from Chapter 5. I got a lot of great bug reports from Prototype 5-1 and I’ve sorted those out. I’m also about halfway done the mapping for Serenity Crater.

Chicken is about halfway done the Golem Transformation sequence, which is about 3x longer than the usual TF scene entirely at her insistence. After reading what we had written for it, she wanted to make it longer and more detailed. Hooray.

Hund is currently working on the combat animations. I’ve got some alpha versions in the engine and I can tell you they make combat flow much better.

Urimas is currently working on new animations and tiles for Chapter 5. More on that in a later post.

Poll Executive Summary

(An executive summary is where you write all the conclusions at the top. It’s named for executives at businesses who don’t have time to understand useful things and need to make descisions based on hearsay, rumour, instinct, and other things that are well known for being wrong and stupid. You know, like executives.)

Prototype 5-1 was well received, we’re going to be doing more like it in the future, we’ll be focusing on more new content in infrequent and irregular releases, and everything is on track without need for major changes.

Now let’s get into the nitty gritty.

Prototype 5-1 Poll Results


So this is about as expected. You can’t please everyone, but I’d be really worried if I got several “It was awful”‘s in there.


Also about as expected, as I received a lot of feedback that the early areas were too difficult. Overall, the main story stuff should be easy-medium, while optional content should be medium-hard. So, the next prototype will tone down the early areas a bit as well as adding items to use that will make things easier. The chapter will slowly increase in difficulty as it goes.


I’m assuming that the “needs work” crowd will be satisfied when the images for this sequence come online. I also think it needs to be a bit briefer (it’s easily the longest sequence in the game so far) and have a more sexual overtone.


A similar result here, but more player’s didn’t know about the form being available as a bug in 5-1a prevented the cutscene from firing. If you’re one of those people, you can activate the cutscene from the debug menu.


This is the desired result. Equinox is an optional area and the final boss is meant to be quite difficult, even if you know the correct strategy. I’m still going to be changing things a little bit (mostly on the final boss) but I’m happy with the results here.


Another desired result, we have plans for several new sequences. Since they’re entirely optional and nobody really hates them, adding more can’t hurt.


I was surprised that as many people thought it was too long as they did. I could probably cut one of the scenes without losing anything crucial, and perhaps allow it to be re-enabled as an option somewhere in the chapter.


Well it seems those poor minigames won’t be getting any love until much later, ha! I expect people will want to see them improved once the Work Credits system is in place, but for now they want more forms, more areas, and more monsters.

I’m still going to be doing the rebalancing work, in fact half of it is done, but the optional areas are the next on the list.


Phew. I was really worried this chapter was going to be way too sad and serious, but it seems that I hit the mark.

Starlight Team Steering Survey


So it seems less frequent prototypes won the day here. We’ll probably stick along the current pattern of having several new features/areas completed between prototypes. Since nobody wanted fixed release schedules, it’s up to my discretion when to release stuff.


This is where the polls aren’t too helpful, as the results are nicely split along less-testing, more-testing, and the current level. I’m still thinking I should allow myself a few extra days of testing before each release, because there’s some really humiliating bugs in these prototypes and I feel bad as a coder for letting anyone see that.


Or: How to Read Statistics, With Salty. While it appears that “No, wait for the full release” won, it actually lost. The other 4 categories are all “Yes, after X time”, so 70% of the respondents think the prototype should go public at some point and are just divided on exactly when.

In this case, I’m thinking 1 month is about right. I won’t change the release schedule immediately, but once Prototype 5-2 comes out, the public will get access to it after 1 month.


Congratulations, voters, because now I will probably alternate process videos in with concept art releases. It will likely be 2 concept arts for every 1 process video, assuming both are in equal quantity.


Monday it is!


So you want more transformations? Well you’re gonna get it! I’ve already taken this suggestion and modified one of the later sections of Chapter 5 accordingly.


Interesting fact: People either prefer one of the group, or all of the group, but not two of any of the group.

And if you’re the person who said none of the above:


So there’s the poll results. A lot of “keep doing what you’re doing”, some changes, and a lot of love for goats. As it should be. Now back to work.

Argue about this post on the forums.

Support the project on Patreon.

300$ Patron Update Spectacular!


Cover art by possible genius agrochemist Rune MFB!

That’s right, we passed 300$ in contributions

Counting all income sources (including patrons who donate via Paypal), Project Pandemonium just passed 300$ USD. In case you’re wondering, the pledge number on the Patreon page doesn’t reflect the correct value since it seems to ignore fees and the amount I’m pledging to other creators. It’s kind of crap.

To celebrate I got noted artist Rune MFB to cook up this special Slimey-Mei image! He wanted to make something special, so he did a partially transformed Mei. I think he has a thing for slime girls.

First Big News Piece: New UI in Development!


Status Screen Concept by CocoMint

After 8 long months, I finally managed to convince CocoMint to help develop us a new UI. And not a damn moment too soon, as the old one was getting quite gamey.

I expect this UI will be finished before the end of April and implemented into the engine. When that happens, a new release of Chapter 1, v1.05, will be released to the public with the new UI in it. No new content, just the new UI. I will also try to get Prototype 5-2 up around that time for Patrons to see new content and the new UI around it.

Second Big News Piece: Major Update to Viscones

Okay so maybe this is great for huge nerds like me, but I got around to updating the code to use dynamic viscones instead of the fixed versions.

Dynamic Viscones.png

You can now see exactly where you need to stand to avoid enemy sight lines. I still need to do lots of optimization and bugfixing, but the system works and runs smoothly. This is one of those things that’s been bugging me since I implemented it back in v1.02 (I think).

I’m not going to get too hung up on the complex geometry (such as the barrels there having square collision hitboxes) because that’s one of those things that takes a lot of time but doesn’t yield a huge reward.

There will be a Coding with a Grain of Salt later this week or next week going into detail on how I made this system work. It involves blockmaps and might involve binary space partitions, so all you huge nerds will probably love it!

Third Major News Piece: Patron Polls in Place

If you’re a Patron, please head over to the Patreon to fill out the Prototype 5-1 feedback survey. And, if you’re a 5+ Patron, fill out the second Starlight Steering Survey, which includes things like how often we should release prototypes and how much my music selection sucks.

Fourth Major News Piece: April Budget Statement

Like all good news outlets, I bury the important news at the bottom. The April 2018 budget report is now out for everyone to marvel at. Yes, Chapter 1 and Prototype 5-1 are what we could do with 2000$. I’m just as alarmed as you are.

Everything Else

Coding work is mostly going to be housekeeping stuff for a little while. Now that Prototype 5-1 is out, I’m going back through all the stuff I had to put aside and putting that in. Viewcones and UI are some examples, but there have been minor bugs I’ve been wanting to get to for ages.

The artists are doing their usual thing. I’m told we should have the combat animations this week and the map next week. First TF sequence will probably be this week too.

Argue about this post on the forums!

Enable my Squid Addiction on Patreon!