Dungeons of Freeport Log 5 – Desktop Graphics
No, literally. Dungeons of Freeport’s new graphical version is designed to evoke the feeling of playing a pencil ‘n paper role-playing game.
I spent a long time deciding what graphics I wanted the shiny new version of DFP to have, and every time I came around to pixel art dungeon crawling, I realised something which I touched on last dev log: there are too many games like this. Or, more accurately, there are too many games that look like this. So, musing on what kind of thing I wanted to see, and noting that Roguelikes have a long tradition of using ASCII (or faux-ASCII) in graphical mode… it just made sense.
This blog post will be about the last few months of adaptation as I move the game’s UI from terminal mode to graphical – and my plans for the next few months.
(Note: the larger fonts shown in some of the below screen shots are WiP)
Paper!
One of the key things I decided on with the graphical version of DFP was to keep a very tactile feeling to it. Every window looks like an early ’90s pixel art version of a bit of paper.
Fortunately, what I’d already done with the engine made this a pretty easy process.
Engine
This move isn’t going to an off-the-shelf but to one I began creating for Deck & Conn – the sci-fi ship combat game I am also creating. It’s based off libSDL and is designed as a very light-weight, cross-platform language to handle 2d graphics and UI. While it doesn’t have to use pixel-art styles, it is very much geared toward that, with its default resolution being precisely half of 1080p in either direction – 960×540. It gives a size that I personally like, and gives pixel-perfect precision on standard 1k and 2k monitors.
The main feature it has which suits the kind of games I prefer to make is a heavy focus on custom UI elements.
Deck & Conn, shown here, is done using numerous buttons and displays.
Each one of the panels shown here is a UIWindow locked in place and given a custom look. Set in it are numerous UIElements, from images whose state changes as required, to bespoke elements like the fire control suites for the ASR Turrets.
In the case of Dungeons of Freeport, rather obviously what I wanted was intended to evoke the feeling of slacking off at school, playing some kind of RPG on legal paper tucked away at the back of a math class you’re ignoring. (I was a model student.) Keeping the ASCII style was something I wrestled with, but in the end I love it too much (and didn’t want to spend another 6 months developing a new map style for the game.)
I’ve kept information stuck around the main screen, almost like post-it notes kept by the player remembering things about the game they’re playing. This made for a fairly easy design style to stick to – certain game modes may require additional information, and I can create a small post-it window that appears in a standardised place during that mode to impart the information the player needs.
For instance, as shown here – what items the players’ character has equipped.
Two Games At Once
Something that is impacting how I work on Dungeons of Freeport right now is this – I am working in (and on) an engine which is being used, as mentioned above, for both this and Deck & Conn.
Which means every time I make a decision to add or change a feature to the engine itself, I consider my needs on the other game. In several cases, this has meant doing a slightly more complex version of the change, knowing that for D&C I’ll wan those additional features.
It’s slowed me down a bit, but it’s resulting in a more robust and useful engine – one which I plant to use in the future for more games than just this.
One example is this – all interface design was hard coded in my original version of the Sapphia engine, for simplicity.
It’s fairly simple stuff – you make your widget, give it settings, customise it including telling it which functions determine when it should appear, and then you move on.
For many, MANY reasons, writing new C++ code whenever you want to change the UI is bad. Including that if I want to let players mod the game’s UI or tweak it in any way, that’s basically impossible.
So I spent a week or so moving the bulk of the UI over to config files, using the engine’s standard KVF (Key/Value File) format. Now, you get one or more UI files which look like this:
It makes life a bit easier for me, and means a recompile doesn’t have to be done every time I want to tweak the game’s UI.
And Then
As it stands, the game now has a 95% working graphical UI, with just a few trivial features yet to be implemented. As they are low priority, my next steps now become: play testing the game, and ensuring all the core gameplay functionality works.
Which means, at the risk of cutting this dev log short – I’m off to play Dungeons of Freeport!
