Prisonscape Alpha 4 Release

Trucking along towards beta.

NOTE: Release notes might contain spoilers!

Release Notes


  • [PS-1] – Fix fleeing in combat
  • [PS-18] – Add a boot option for directly loading a save game
  • [PS-19] – Put combat variables into file
  • [PS-20] – Implement a “Quit game?” pop-up
  • [PS-21] – Remove ‘Literacy’ skill from the game
  • [PS-22] – [County Jail] Finish storyline for both factions
  • [PS-23] – [Miranda] Add experience to quests
  • [PS-24] – [Miranda] Finish ‘Krokodil’ quest
  • [PS-37] – [Miranda] Add warden’s death cutscene
  • [PS-66] – Fix character stats in debug view


  • [PS-63] – Split editor, engine and game into different packages
  • [PS-64] – Implement basic unit tests for editor, engine and game
  • [PS-65] – Implement a better serialization strategy

Prisonscape Alpha 3 Release

This is probably the last bigger alpha release, hopefully the next ones will be out much faster. I had to throw away the previous combat code and think up a better system. Normally I don’t like doing heavy refactoring this far in a project, but it was mandatory (for my sanity) in this case.

Alpha 4 and Alpha 5 will still be heavily concentrated on combat, we are still missing stuff like: animations, particles, sound effects, ranged attacks, henchmen and consequences. Once those are implemented, then we can say “We are looking so damn good”.

List of completed stuff:


  • combat v2: complete refactoring
  • combat v2: new script API
  • combat v2: larger combat levels
  • combat v2: free look
  • combat v2: flee spots
  • combat v2: simple enemy AI
  • combat v2: action turn bar v1
  • combat v2: smooth scroll camera
  • fix bug where item locations are not removed when the item is taken
  • add setPlayerSpawn() to LevelAPI
  • add game debug command: show trigger areas
  • fix bug where player activation line is not aligned properly after a cutscene
  • add trigger actions to trigger areas: STOP_PLAYER -> causes player to stop
  • pass target level as a program argument, not as a property
  • implement zooming in and out
  • implement transitions between all levels


  • only set the background tile when increasing level dimensions
  • fix bug where tile debug data is not shown when increasing level dimensions
  • pass target level as a program argument, not as a property
  • only show level files that can be loaded
  • implement zooming in and out
  • implement free spawn placement
  • add level editor debug command: show trigger areas


  • fix all warning generated by -Xlint:all
  • fix compile time warnings
  • fix world object selection in level editor (can still be improved)
  • refactor java2d rendering code
  • refactor opengl rendering code
  • update JOGL

Working on Prisonscape Alpha 3

Short update on where we are at:

It’s looking like the combat system needs to be split into two alpha releases. Currently I’m working on completely refactoring the combat model, adding stuff like side information, custom AI scripts etc. Pekka finished the design of the new combat in September, I just need implement it so that we can start tinkering with the details.

I naively thought that I could build on the existing system but it was just a pile of garbage built fast so that we could demo the combat in general.

Alpha 3 will have the basic system and rules working, and Alpha 4 will have the animations, sounds and other bells and whistles implemented.

Until next time.

Prisonscape Alpha 2 Release

Only took a year to release.

Anyways, I recently started working part-time so that I can concentrate on finishing Prisonscape.

This release contains mostly bug fixes and code refactoring.

List of completed stuff:

– add license attributions (LICENSE file)
– add teleports to level editor
– add trigger areas (game model + level editor)
– fix all bugs found from Alpha 1
– refactor texture atlas creation process
– update all libraries
– upgrade to Java 8
– fix redundant code style issues
– delete useless libs
– update lib folder structure
– update and clean build file

Alpha 3 will contain Consequences and Drug Effects, maybe some improvements to the combat as well.

Once there’s more stuff to show I’ll be posting screenshots on our forums at the RPG Codex.

Prisonscape Alpha 2

Hello hello,

We’ve been working on Alpha 2 for a while now and hopefully it will be out in July.

Alpha 2 will have few engine related things I’ve been working on, mainly a refactoring of our asset pipeline so that, for example, Pekka can add new textures easily.

As for features, consequences after combat is a big one we’ve been wanting to get right. Now fights in Prisonscape don’t matter as there are no real consequences, they guy you killed or injured just disappears without any blowback to you or your status inside the prison.

We don’t want combat to be just another grind for experience and items. Even though we’re not aiming for realism, it would be kind of funny to just slaughter groups of inmates like you’d do in Chrono Trigger or Final Fantasy. We’d like the fights to be harder (and maybe longer) and have both positive and negative effects during the game.

Anyways, stay tuned!

Prisonscape Alpha 1


We started alpha testing in the beginning of August, and soon we’ll be releasing Alpha 2. You can follow alpha and general discussion here.

We’re still accepting alpha testers, please only apply if you don’t mind testing a half-finished game. Send email to for info.

EGX Rezzed 2015 and development news

Pekka will be hitting the road again to show Prisonscape at Rezzed. This year Rezzed will be held at Tobacco Dock, London, UK.

We won’t have a stand there but Pekka can show you a quick demo on his laptop. The reason we don’t have stand is that we feel the game is still in really early alpha stages and it doesn’t have all the features (and polish!) we want to show off. It is getting there, though.

On that note, we discussed earlier that how should we demo Prisonscape in a live setting? It’s not a flashy action or platformer game, some of the game is fairly slow paced where you talk to NPCs and think on how to solve a quest. One solution is that we make a short scenario where the character already has some skills and levels, and then we put you in a tough situation, e.g. you need to solve certain quests in 10 turns or else the character is put in solitary confinement. That’s one idea… do you guys have any suggestions?

As for development, recently I finished saving and loading for Prisonscape. Sounds pretty mundane, but it makes testing the game faster as you don’t have to start over again and again and tell Danny to “Fuck off” (Danny is first NPC you talk to in the game). Now I’m putting in the sweet UI graphics David finished a while ago, and also implementing character levels and experience.

We originally tried to a design where character progress was mostly hidden from the player, but Pekka noticed that the game then lacked a sense of accomplishment, which is really important in RPGs. So now we have “the standard” design of levels and experience: you level up and then put points to stats. Skill training is done by using the skills (e.g. fighting), and also using trainers in the weekly menu, which appears when the current turn (week) ends.

Alright, that’s that for now. Gotta get back to coding ->



I’ll be talking about our future plans and some tech stuff in this post.

It has been going slow for the past month, mainly because Pekka and I have been on vacation. Add some nice summer weather and there hasn’t been much progress. I’m certain our productivity will return to normal levels when the weather gets shittier, which should be in approx. one month. 😀

We were originally planning to go to the Gamescom and Eurogamer conferences, but the game is still quite “alpha” so we decided to just save that time and keep working on the game. There aren’t that many game mechanics missing however. Combat and trading are the major ones (combat version 1 is already done), after those I think we won’t be adding new major features to the game. Minor ones we can add during alpha and beta testing. Replacing the “programmer UI” also needs to be done soon, David did some pretty sweet graphics for the new UI.


People who pre-ordered Prisonscape have been asking about the alpha testing and our response has been that we’ll deliver the first alpha when the major components are in the game. Not to worry, when we’re ready we’ll contact all who pre-ordered and have access to the alpha.

As for programming stuff, I’ve been implementing an OpenGL based renderer as my latest task. I was originally trying to just use Java 2D, but it didn’t cut it. I realized this when I bought a new laptop with “ok” specs, and the game’s FPS started going all over the place. There should be no reason why a game like Prisonscape couldn’t run at 60FPS all the time, so after digging and debugging for a while I decided to learn and implement OpenGL.

After a few days I got the basic rendering working and man, it’s smooth now. The Java 2D renderer used to skip and glitch even on my beefy desktop PC, but now it scrolls beautifully. I’m fairly certain Pekka doesn’t even recognize the difference, but I saw it immediately. Apparently programmers (esp. graphics) get this thing where they notice every little detail and glitch because they stare at the screen and animations constantly.

Also, JOGL (the OpenGL framework I’m using) implements V-Sync in windowed mode which saved my ass because apparently you could only get that in Java2D in full-screen mode. I don’t think I’ll implement a full-screen mode for Prisonscape unless there’s great demand for it.


Implementing OpenGL also sets some minimum computer requirements for Prisonscape. Your graphics card should support OpenGL 2 and 1024×1024 textures. That’s the minimum I’m coding for and that should cover a huge chunk of laptops and desktops. I was originally gunning for OpenGL 1, but it seems the support has been dropped from JOGL. 😀 No wonder, the OpenGL 1.1 spec is from 1997.

Of course changing the graphics context broke something else in the game. I had implemented our video cutscenes with JavaFX and it seems JOGL and JavaFX don’t work well with each other. A little note on those video cutscenes: I originally tried to render them as just full-sized .PNG files, which turned to be really stupid. Memory consumption quickly jumped to 1GB during the intro cutscene – apparently it isn’t a smart idea to render uncompressed PNG data. To solve this, I encoded the intro animation as a .flv file, but JavaFX only supports VP6 encoded .flv files, so I had to dig up a trial version of some Adobe software to encode it properly. Side note: Google owns the VP6 codec, but they don’t offer new licenses for it, so who knows if you can actually even use VP6. Hopefully I can find a library which can playback Ogg Theora (.ogv/.ogg) files in a JOGL context (jmcvideo seems promising) so I don’t have to hack some custom made video playback system together.

Seeing all this technical work and the troubles it brings one might ask “WHY DON’T YOU USE UNITY????” and my answer is that I’m planning to be a highly skilled game/graphics programmer ten years from now, and in my opinion you don’t lay a foundation for your skills by using Unity or any other game engine. The reason John Carmack and Tim Sweeney are so good is that they put in the time to do the low level work of building game engines (and also because they had to). Yeah, it’s slow, painstaking and financially not so sound. But if you commit to it and do the work properly, the rewards will come in due time.

Aaaand that’s that. See you later!

Core features and beyond

Why hello there!

While Pekka has been designing NPCs and the layout of the County Jail, I have been working on the core features of the game. I’ve completed first versions of the combat system, item handling and quest (job) system. I’m sure we’re going to rework these features several times, but it’s nice to have even rough versions up and running. Prisonscape is starting to come alive! As a side note, people from Reddit seemed to like the fact that you can taunt your opponent during combat. 🙂

We’re currently working on getting the tile layers work with each other, so that transparencies and object rendering orders are correct. It’s actually quite a bit of work to get them working properly, but once the system is done we don’t have to touch it for the rest of the project.


Layering in action – player character is standing behind the table

The reason we switched from working on core features to engine functionality is that we’re trying to get our first gameplay video out. It will feature a simple quest, combat action, and in general show the ‘world’ of Prisonscape a bit. So, having working tile layers will be nice so that the player will actually disappear behind walls and items instead of climbing all over them.


Checking if the Dance with The Dragons has finally arrived…

As for deadlines, we’ll try to get the demo ready for September or October. I’m guesstimating that we will be working mostly on gameplay features this year with polishing and the rest of the engine work going to next year. There isn’t much engine work left anyways, implementing OpenGL rendering and building an audio system basically. Making sure the game works as intended on our target platforms will also require time.

It’s important to note that we’re basically building Prisonscape from scratch, using a custom engine. I know we could have accelerated the development of Prisonscape by using Unity or some other existing engine, but I made the decision to use a custom engine based on few key reasons. Mainly, I like to have control over everything in the code. Having total control over code means that I can tweak every aspect of the game without waiting for a 3rd party. It also allows me to implement Pekka’s ideas without ever going ‘Nope, sorry, the engine can’t do that’. We also won’t be bound to any license fees or royalties.


“Sir, I’d like to checkout from the premises.”

Even though custom development is slow in the beginning, we’ll begin to see the advantages in the mid to late stages of the project. Also, we’ll have a “production tested” code base which can be used in our next game. Anyways, Tommy Refenes (programmer of Super Meat Boy) had a nice blog post about this same issue at Gamasutra. He also seems to like the idea of custom engine development.

Well, this rambled on longer than I expected. Until next time!

Engine work, part 1

As Pekka mentioned in the last post, I have been working on the engine features for the last month. I basically rewrote the game loop and collision detection system from scratch because the earlier versions weren’t cutting it.

I noticed how the animation was not smooth at all and tracked the issue to bad game loop design. After identifying the problem, I spent a good amount of time researching on how to build a proper game loop. I guess every programmer will eventually end up reading the ‘Fix Your Timestep!’ article by Glenn Fiedler. He does a fantastic job of going through different game loop implementations and explaining why they work or don’t work. You can read the article here. Long story short, I implemented a version of the semi-fixed timestep game loop and it’s working nicely!

Next up was fixing the collision detection system. The earlier version worked fine, but things started to go south when I implemented partial collisions in the game. The partial collisions allow us to define regions of a tile which are not accessible, instead of blocking the whole tile. For example, we can create walls the player can walk right next to, giving the game a sense of depth. Because I didn’t refactor the old collision detection system properly, weird glitches and bugs started appearing when new tiles with partial collisions were created.

What followed was an exercise in rewriting the collision detection system again and again. I have to admit it was really frustrating when you thought you were about to nail an implemention only to realize it would crap out in certain special cases. I could sense when a certain version of the system wasn’t going to work because I started adding a lot of special cases in the code. And sure enough, the special cases were not tight enough and the system would break.

For example, one of the older versions looked like this.


Separate external lines

The problem with this system was that the player would get stuck at the edges between the tiles. I tried working around this issue in several ways but all of them ended up breaking the collision detection system in some way or another. Finally, I found out that the way to handle this issue is to collapse all the external edges into combined lines. This fixed the ‘getting stuck’ issue nicely. Having this implementation also enables you to have arbitrary sized shapes in your engine (like we have with different sizes of rectangles). You can see the new collision lines below.


Collapsed external lines

Here’s the algorithm I came up with:

Loading the level

* First find all the external edges in the tiles
* Then sort the edges into horizontal and vertical edges (we only have rectangles in the game)
* Detect adjacent edges by comparing their start or end point. If the edges are combined, keep the combined line and remove the lines you just compared.


* Collide the player rectangle(s) against the lines
* Detect if the lines have a corner point and if the player needs to resolve a corner collision
* Resolve collisions, adjust the player’s x or y position back to the previous position

This is just a high level view of the algorithm, but I think it illustrates how the collision detection works in general.

Anyways, I guess that’s enough of tech stuff for now. Next up, I’ll start reworking the battle system. Until next time, stay classy San Diego!