Let’s talk about what’s in store for my next game + WIP footage from the engine

I’m not a big fan of talking and showing off my projects when they’re still in the baby/concept form but if it’s one thing I learned from Ebony Spire’s launch is that I need to start marketing as early as possible. However, I want to avoid the good old caveat of having early images from development tied to the future game’s name so I won’t mention it here or “announce if officially” by name. We can talk about the game, the engine and the juicy parts that I never thought I would talk about: Localization support and a User Interface from scratch.

First thing’s first, if you follow me on twitter you might have seen a few screens and details about my current workload. For the past few days I’ve been focusing on:

  • Normal Map generation
  • A general-purpose user interface framework that supports rendering game scenes to texture and full customizability
  • Localization support with the ability to switch between languages “on-the-fly”
  • Procedural generation of in-game maps

The procedural part is nothing new in my games. I use it to either lower the burden of content creation and give the players the ability to re-play the game in a familiar setting or for testing purposes. I won’t talk about it much during this post except to say that it’s on par with what I did for Ebony Spire. Once I finish up more important matters (like finishing what’s left of the ui framework) I’ll focus on procedural generation, especially in terms of puzzle generation and placements.

The main goal of this post is to approach the matter of Localization and User Experience.


Localizing and translating my games is not something I thought about or implemented in my previous games. Normally I’d focus on getting the core gameplay up and running as best as possible and build the entire game around a vertical slice of gameplay. After Ebony’s Spire launch I was faced with the data that Steam and Google Analytics brought me:

The fact that I get most of my sales from English speaking countries but most of my visits are from countries like Russia and China.

Now here’s the kicker, at this point in time 60% of the traffic to my Steam Page comes from Russia. You’d think I sold a ton of copies there, right? Well, Russian territories account for only 2% of my sales. As opposed to the US who brings in about 28% of the traffic but accounts for 44% of the profit.

And just to put things into perspective, remember all those post about dev’s selling only 1-2% of the total copies on Linux? Well, Linux sold more than the entire eastern european nations combined (almost 9%)! So in my case, it pays off more to focus on releasing my next game with Linux support (and seeing as I use linux as my main workstation that isn’t a problem) than trying to sell the games to Eastern European countries.

And here’s where localization kicks in. I’d like to think that the reason I’m not selling at all in Russia is because the game is not localized for that region. And since I’m writing this engine from the ground up for my next game I’m adding in support for localization. And at this point it’s so tightly built in that I need to be an idiot now to translate the game.

With Ebony Spire I was using hard coded strings for most of the UI. Even if someone offered to translate the entire game for free that task would have been nigh impossible due to the way I handled text and string previously. With the current project, well. Take a look:

Everything from the User Interface to the Game’s actual content (story, dialogue, books, etc) can be localized with minimum effort. You remember how much I loved CSV files for Item handling in ESH? They are back with a vengeance! As it currently stands there are three main csv files for localization:

  1. User Interface localization – where I store the ID’s of buttons, english, spanish and russian translations. When ever I create a new gui element in the game I assign it a name using an identifier from the UI csv file. To change it to another language I just need to change the active_language identifier to the proper one. All in-game text is changed in the next instant (and if text is missing it will default to English and create a failed localization.log file telling me what id’s from what documents were not found).
  2. Game Dialogue csv file. As opposed to Ebony Spire the next game is story and dialogue driven. It’s a dark comedy game where you play as a rising anti hero. And since dialogue is the meat of the game outside of a dungeon it needs to be localized. And I need to be able to change and update it from outside the game. So it got it’s own file and it’s own system to make my life easier later on.
  3. Anything else that needs text. And I mean. I have a text master class that keeps track of all the strings used in the game. If I manually add a string somewhere in the game, the master class catches it and searches for an Identifier for that text from the localization document. If it finds no matching records it dumps a log file with the strings that need to be added. So I won’t forget to do that.

So yeah, localization is a big thing for me in the next game. And it’s extremely fun to integrate. A small challenge that I never approached before. I’ll see if it’s manageable in the long run. As for the languages I’m aiming to localize, they Russian (big surprise), Spanish (because I know and I can probably take care of it) and German. Already have some people in mind for the tasks, but if you’ve got an offer don’t shy away from sharing it with me.

The User Interface

There are two reason for why the UI in Ebony Spire looks the way it is (and here’s a screenshot for those who don’t know the game).

Because my previous UI system was crap. And I mean crap. It was a hacked together framework from MOAI community’s UI library and my custom additions and changes. Buttons wouldn’t register clicks when the mouse was over the labels or clicks would pass through one active window to another. So I ditched the mouse all together.

The second reason is that I’m in love with good text based ui. Just take a look at what Josh is doing in Cogmind (those gifs and his game are literary porn for me). I wanted in on the text-based user interface system. I also wanted to see if I can design a game that can be played only with a keyboard. And I succeeded somewhat. I’m happy with the result but I do realize that it was off-putting for some people. So the next game will feature support for the mouse. Actually it might actually be the reverse. While keybindings are something I’m looking into I’m focusing on using a mouse-driven interaction this time around. Part of the reason is that I want to port it to mobile later on (and it currently works) and I don’t want to go through what I’m going through with Ebony Spire’s mobile port (hint: it’s a nightmare).

So for the past few days I’ve been focusing on writing a User Interface framework from scratch. I’m focusing on:

  • Having it be event driven
  • 100%┬ácustomizable in terms of look and feel
  • Able to have game scenes rendered to it
  • Ability to have it adapt and scale based on the platform the player is running it on

And for just a few days of work I’m happy with the progress. Here’s a fresh video:

The panel that pops up during movement is a quick mockup done using resources from Open Game Art. I’m trying to come up with the rules for combat encounters and I want to know how it feels before I start implementing the actual combat system.

There are a few things missing from my UI framework:

  • The ability to resize the windows
  • The ability to minimize them
  • Locking the windows into place (via buttons)
  • Custom controls like Input Boxes and Check Boxes.

Everything else is already in there. It should take me a few more days to get this features in and after that I can start working on the actual game. But it’s good progress for now.

And that’s pretty much it for this progress report! I’m going to leave you guys and galls with a photograph of the current version running Linux and Android. If you have any questions please leave a comment or reach out to me on twitter.

And if you can and want to support me consider buying one of my games. All income from Ebony Spire and Rogue Sweeper go straight into developing this one.

Soon I’ll have to start contacting concept artists for character art and based on the quotes I get I’ll decide how much content the actual game will have (and if you are a concept artist looking for a gig and can draw characters like this – reach out and say hi).