Summerscape

Hello!

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.

inventory-big

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.

journal-big

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!

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.

old_coll_system

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.

new_coll_system

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.

Playing

* 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!

Prisonscape – Technology and platforms

As Pekka has been detailing the gameplay for the last few blog posts, I decided to write a post about the technology behind Prisonscape.

The game engine is custom written in Java with a few dependency libraries. As of now, the engine supports(among other stuff): 2D tile maps, player movement, collision detection, camera controls, Lua script integration (LuaJ), MP3 playback (JLayer) and UI functionality. The engine is still a work in progress with lots of stuff in the development pipeline. The level editor is also written in Java with Swing driving the UI functionality.

Why Java? Here’s a few reasons:

  • No manual memory management -> eliminates a certain class of bugs completely
  • Excellent multi-platform support -> can easily target multiple platforms at launch
  • Ecosystem which is both large and mature -> no need to reinvent the wheel
  • Improved Java Virtual Machine performance -> reasonable execution speeds for 2D gaming
  • Static typing -> programming errors are caught at compile time
  • Familiary with the language and platform -> optimal programmer productivity right from the start
  • Based on C -> easy to bring other programmers onboard

The popularity of Minecraft has also spread Java to a wider gaming audience which means that many of our potential customers will already have Java installed and updated. As for users with no Java installed, we will wrap the game with Launch4j so that the process of launching the game is smooth.

Overall, Java is a great platform with excellent tools all of which enables me, the programmer, to maximize my productivity. Java isn’t “perfect” but it gets the job done really well.

I also have to say that Lua is fantastic. It was easy to integrate the language into the engine and start getting stuff done. Pekka has really enjoyed scripting the dialogue and NPC behavior using Lua. With script integration, the players can also make their own NPCs, quests, dialogs etc. when they get their hands on the game.

As it was discussed in the introduction blog post, we will release Prisonscape on Windows, Mac and Linux. We’re already doing testing on all of these platforms, and so far the game’s performance has been excellent.

So, what’s coming next in the pipeline? A lot:

  • Custom paths for NPCs (level editor) and pathfinding
  • Improved audio support
  • Support for scripting events
  • Improved quest scripting
  • Improved combat screen
  • Lots more!

Well, that’s it for now. Stay tuned for more tech updates!

– Tuomas