Development – The Skald RPG Devlog

Prologue Patch and Experience

Greetings all!

The Skald Prologue has now been live for almost a month. It’s gotten tons of praise and been a wellspring of vital feedback. In other words, it’s safe to say it’s been successful.

What better way to celebrate, than with a new patch and a mini post-mortem of the demo launch!

Skald got its first fan-art (that I know of)! I’m so happy to see people nerding out over my game!

Thank you so much to all of those who’ve played, rated and offered feedback on the game so far! If you still haven’t given it a go, I highly recommend you check it out!

Note that patch 2.0 will likely not be live on GOG till over the weekend:

Here is a brief overview of Patch 2.0 and some of my experiences with launching the demo:

Patch 2.0

Patch 2.0 has focused on fixing bugs and typos as well as adding quite a few new features that focus on Quality of Life improvements.

The biggest job, by far, has been reworking the save system. Save-times are now pretty fast (around 0.5 second) and this allows me to be a lot more generous with having the game auto-save often (a much requested feature).

The only drawback to this, is that the patched game will no longer be able to load old save-files. I’m sorry for the inconvenience this causes but I hope you’ll take the opportunity to perhaps try a new character-build. Keep in mind that the game also allows you to skip the intro and start directly at the shores of Idra if you don’t feel like playing the intro again.

Another highly requested feature that I found time to put in, was “Windowed Mode”:

This should make the game a bit easier on the eyes for gamers with big screens and you can now even play it discreetly at work.

Thankfully, I managed to fix the dreaded “broken screen” bug that caused the game to look like this on certain set-ups:

This bug was the source of the game’s only negative Steam review so needless to say, I’m relieved I managed to fix it.

I’ve also spent some time trying to find better ways of offering feedback in combat. I’ve done some experiments with hovering text and I feel optimistic for it:

Try it out and let me know what you think!

Under gameplay options, it’s now also possible to ajust how much feedback you get in combat; making it as fast or as slow as you want.

Finally, I’ve tried to make the game a little bit more balanced by having random encounters scale in difficulty and giving the option of attempting to flee or sneak away if you’re keen to avoid the encounter alltogether:

In summary, here is an (in)complete overview of changes made:

Features

You can now play in window mode
Random Encounters now scale in difficulty dynamically
Simple volume controls
The game auto-saves whenever you enter or leave most maps or camps
Pressing SHIFT now highlights interactable objects
Combat info is now shown as floating text on the screen
damage ranges for melee are now slightly more compact with the strength bonus now added as a flat modifier
Added 1 more point of movement to all characters
The rogues back-stab ability now triggers on flanked opponents as well (not just stunned or surprised opponents)
You can now choose to see or not see combat results for the player or opponents in the Options -> Gameplay menu

Bugs

Trying to select a spell from an empty spell-list would lock up combat
The game sometimes booted with the UI elements small and shifted to the lower left corner of the screen
You can no longer assign character points to the “header” during the “Stats” screen in character creation
FIxed bug where you couldn’t flip pages in inventory
For certain models, weapons would blink in and out of existence
The sword/bow target icon should now correctly show as a bow if you have a ranged weapon or a sword if you have a melee weapon equipped
Resolved a performance issue that caused frame-rates to drop as you gained more items in your inventory
Dozens of minor bugs

Launching a Prologue: A Mid-Mortem

Launching the Prologue has been pretty time-consuming and demanding at times. Nonetheless, I’m incredibly happy I did it and here are some key take-aways:

Launch the demo as a standalone Steam/GOG application before the main launch: This as opposed to having the demo build be part of the main (already launched) application.

“Backbone” has become a recent case-study for this strategy with their highly successful prologue. Data seems to indicate that having the demo as a standalone application, increases wishlisting, and post-launch wishlist conversion-rates for the main game.

It also means that it’s possible for players to offer reviews and these seem to go a long way towards driving interest for your game as well as insulating the game from any negative feedback from the demo.

Finally, you should consider how long (if at all) you let the demo live after the main application launches. It’s fantastic to have a demo out before the main game launches. Once the main game goes live however, you should certainly consider if it’s better to perhaps take down the demo. Remember: Steam’s generous refund policy will basically allow players to test your game even if it’s not free.

Double your time estimates: Steam reviews all applications before launch. It can be hard to predict if they will approve or not and you might need to make changes. Each cycle of changes can add 2-3 day of waiting for review. The take-away is to submit the game well ahead of your planned launch date.

Drink from the community firehose: If you’re lucky, people will care enough about your demo that they offer feedback. I truly believe that this is pure gold for any game-developer. Especially if you, like me, don’t really have access to professional testers and QA people.

The silver lining with handling feedback in a good way, is that it’s also a fantastic way to make people feel invested in your game in the long run. My experience is that gamers who end up seeing their feedback being taken seriously, tend to become life-long fans.

This is a topic for a whole post in and of itself, but note that “listening to feedback” doesn’t mean implementing every change suggested by the community. To me, it’s about having the mentality of trying to assess feedback objectively and trying to see the case from the user’s perspective. I try to make a general rule of not defending my decisions publicly. I may offer my rationale for a certain design, but if you find yourself arguing with users over their feedback, take a step back.

Consider how long the demo should be: This is a difficult but important decision. The question you need to ask is “will this demo leave the player wanting more?”. You don’t want players to “eat their fill” with the demo and forgo playing the main game.

At the same time, you need to show enough that the demo feels like a good representation of the main game and offers enough of an experience that players feel invested in the project.

This point becomes even more important if you intend for the demo to be available after the main game launches.

In closing: Launching a demo as a stand alone application, before the main game, is a great dry run if this is your first rodeo. It’s also a fantastic way to build a community and provides valuable play-testing and publicity.

Feel free to reach out if you’re a fellow game-dev and have questions!

But for now: Go play the prologue (and remember to leave a review if you feel like it)!

As always, get in touch via the Discord or Twitter for all things Skald-related (I guess now you can also use the Steam and GOG forums).

A Long Overdue Update

It’s been some time since my last update, but have no fear: The SKALD project is doing great! I’ve just had to prioritized using what spare time I have writing code and doing game-design.

Old School Roots

I grew up knowing and loving games like the Ultima, Bard’s Tale, Gold-Box and Magic Candle series. The more I worked on the SKALD engine, the more I realized that I wanted to use it to make an old school retro RPG.

The SKALD engine now features:

Overland exploration
Tactical menu-based combat
A full party of characters
Deep class-based character creation and progression
Tons of items to find, buy and sell
Magic
A solid branching dialog system

In other words, SKALD is now very well suited for making old school RPGs. This leads me to my announcement:

SKALD: Against the Black Priory

“Against the Black Priory” is the first game under development using the SKALD engine. It features 8-bit graphics and the glorious 16 color Commodore 64 palette.

Keep posted for more info on “Against the Black Priory”.

Support SKALD today!

If you love old school RPGs SKALD needs your support now!

All you have to do is subscribe to our newsletter and follow us on twitter!

Done! That’s it (for now)!

The SKALD Markup Language

The Basics

SKALD is a game engine specifically written for digital gamebooks and interactive novels. The design vision for SKALD has been to create an engine that allows for a strong narrative to be built upon a foundation of classic RPG features (character development, tactical combat, loot etc.) as well as certain rouge-like features (procedural generation). The game engine is designed with a strong separation between data and logic in mind. The reasoning being that it must be possible for a designer with minimal technical expertise to add content. Also keeping all data separate from the logic will allow multiple gamebooks to be published using SKALD without making changes to the engine itself.

A mage — The mark-up language is where the magic happens

The SKALD markup language has three main components:

The XML that encases all the data
A simple string markup used to create procedural content and to set the order of resolution for any embedded dynamic code.
The formatting for embedding dynamic code.

The XML

SKALD uses ordinary XML to store data about all its game objects (scenes, items, NPCs). I briefly considered using JSON. However, after doing some research I arrived at the conclusion that the advantages of using JSON over XML were nil for this application. JSON would perhaps have been more relevant if I had a stronger emphasis on developing for a web-based service (as JavaScript loves JSON).

The String Markup

All the data in the XML files are parsed to strings. Those strings are then run through a processString() function that performs any action prescribed by the string markup, resolves any embedded code and returns a copy of the processed string.

One of the first things I found that I wanted was a short-hand for returning random strings from the XML. My solution was simply to use the ‘/’ character. Adding ‘/’ to any string will cause the processString() function to return the result on either the left or right side of the ‘/’. For example:

processString(“I like hamburgers/I like sushi/I like ramen”)

returns either “I like hamburgers”, “I like ramen” or “I like sushi”.

Right of the bat you can see that this can get verbose. The solution was to add parenthesis. Now the previous string can be shortened like so:

processString(“I like (hamburgers/sushi/ramen)”).

By nesting parenthesis (resolves from inner, to outer) you can make complex string such as:

processString(“I like ((cheese-burgers/bacon-burgers/BBQburgers)/sushi/ramen)”)

The applications for this is to create variety in the text (especially for scenes that the player keeps returning to) or to provide randomized output from certain XML tags.

For instance, each scene has one or more exits that lead to the next scene. That exit contains a tag called <tar> (target) which is basically the id of the next scene to load. Since the value of <tar> is stored as a string and ran through the processString() function, you can write an exit with a target like this:

The result is an exit that randomly sends you to scene 2, 3 or 4. Pretty neat for making things like random encounters.

Dynamic Code

So far, the system is completely stateless. Processing the string

processString(“I like (hamburgers/sushi/ramen)”)

will return a random output every time. The next logical step was to add a system for storing and modifying variables at run-time. The solution is for implemented by using “Reflection” in C# to access functions in the code via strings passed from the XML. For instance I have a function addVariable(key, value) that creates a variable (named key) and sets it to value. So

addVariable(“food”,”hamburgers”)

will set the variable “food” to “hamburgers” and

getVariable(“food”)

now returns “hamburgers”. Using my own notation to embed functions in the xml datafiles the functions must be wrapped in curly braces like this:

{addVariable|food;hamburgers}

It is now possible to write:

processString(“I like {addVariable|food;(hamburgers/sushi/ramen)}”)

This line of code will return for instance, “I like sushi”. And then

processString(“My favorite food is still {getVariable|food}”)

Will utilize the value stored above and return “My favorite food is still sushi”. Note that the “processString” function will substitute everything wrapped in curly brackets for the return value of the function wrapped in the curly brackets.

The SKALD system contains about a dozen functions that can be called dynamically. In large part these are used to manipulate and perform logical operations on variables (allowing for conditional branching etc.). The result is that the number of scenes that need to be written can be reduced drastically. It also allows procedural content to be added by the designer, working only through the XML file.

Overall, I’m pleased with the functionality of the SKALD markup language, as it exists today. It’s expressive enough tell any kind of story and to give a direct binding between the story elements and the underlying RPG mechanics. It also supports the concept of separating data and logic and it greatly reduces duplication of data by cutting down on the number of scenes that need to be written. At the same time, it’s still possible to write an entire module by using only XML and entirely forgoing the use of the string markup and dynamic.

Now, off to write some adventures!

Design Goals for the SKALD Engine

The SKALD Roleplaying System consists of three components:

A set of RPG rules usable for pen-and-paper as well computer RPGs.
A game engine for making gamebooks, interactive fiction and text-heavy roleplaying games.
The games published using the SKALD engine.

The current focus of the project is to finish the game engine. This post will attempt to summarize the design goals for the engine. For more information about the project in general, see the welcome post.

NOTE: I’m writing this post as much for myself as anyone else. As such, this post will be highly prone to edits as i update and change the design goals.

SKALD is a Storytelling Tool

First and foremost, I want to create something that will allow me to tell stories. I was a pen-and-paper RPG game master for years but as I grew older, holding together a gaming group became near impossible. I began to miss the creative outlet that GMing represented. This was been a big driving force in deciding to develop a game engine for text based roleplaying games and gamebooks.

Specifically, I chose text-heavy games because I feel comfortable with using text as a narrative device. Text is easy to add (if you don’t consider the hardships of writing prose) and very flexible. Flexibility was another important point as it gives me the option of choosing between an infinite variety of settings: From sci-fi and fantasy to historical and educational. This was an important rational for beginning this project by creating a setting-agnostic game engine.

SKALD is a roleplaying game

In addition to creating a system for writing choose-your-own-adventure style gamebooks I also want SKALD to be rooted in a proper RPG system. At a minimum the SKALD game engine must allow for the following game mechanics:

a character creation and advancement system complete with skills and feats
skill checks
tactical combat (in one way or another)
looting, buying and selling items
magic and / or psionics

An important part of implementing the RPG features is that the system must be modular enough that it should be fully possible to choose away any and all parts of the RPG system at the design level and without changing the source code. In other words: Using the same game engine, it must be possible to make a vanilla gamebook with no features beyond one paragraph leading to the next, as well as gamebooks with full RPG game mechanics.

SKALD has rogue-like features

In addition to the rpg game-mechanics it’s also important for me that the SKALD game engine allows for certain rogue-like features. In particular I want to have the ability to add procedurally generated content to the game. This, combined with an underlying RPG system will make it possible to essentially write a text based rogue-like. At the same time, just as with the RPG system, it must be fully possible to write a gamebook without using a single rogue-like feature.

Why add rogue-like features? Well, my reasoning thus far is that this will make it a lot easier to add to the runtime of the game. I have a vision of the narrative of the gamebooks being superimposed on relatively open worlds and thus adding a lot more replay value to the game beyond just going through the main plot over and over.

Again: This is an optional feature I’ll add to give myself the full breadth tools to tell the kinds of stories I would like.

Engineered with Sustainability in Mind

Not only is SKALD a labor of love, but it will also serve as a tool I could potentially be relying on for years to come. In the long term, it might even be adopted by other game developers interested in working within the gamebook genre.

As with all code that sees long-term use, there’s a lot to be gained by “measuring twice and cutting once“. In other words I intend to take my time and keep the source code architecturally sound, compact and well documented.

The notion of strictly separating the logic from the data and making all aspects of the game itself modifiable via the data is the prime tenet I’m currently building the engine around.

SKALD as a Brand

Lastly, it would be pretty neat if the SKALD system and the game engine in particular becomes a recognizable brand. It would be awesome to see “Powered by the SKALD engine” and “SKALD Roleplaying System presents:” on games!

That’s it so far. Thanks for reading and be sure to keep following the SKALD devlog! In the meantime, follow Scape-IT and SKALD on Twitter for all things RPG!

Welcome to the SKALD Roleplaying System

Welcome to the devlog of the SKALD Roleplaying System!

What is the SKALD Roleplaying System you ask? Well, it’s essentially three things:

A set of RPG rules usable for pen-and-paper as well computer RPGs.
A game engine for making gamebooks, interactive fiction and text-heavy roleplaying games.
The games published using the SKALD engine.

The system is being developed by Scape-IT and is a passion project born out of a long standing love for all things roleplaying.

So what is a skald?

The skald was a norse warrior poet during the scandinavian viking- and middle ages. Skalds would serve at the courts of viking chieftains where they composed and performed epic poems retelleing the heroic deeds of their patron.

In other words, a skald tells epic stories about heroic deeds. Not a bad name for a RPG system if you ask me!

The Current State of the Project

At this stage, the first order of business is to complete the SKALD game engine. Currently the engine is is in pre-alpha but I hope to have a beta of the engine and a playable gamebook ready during the spring of 2018. The SKALD engine is being developed in Unity-3d.

Code sample — Pretty much the state of SKALD at the moment.

This website will serve as the devlog for the SKALD project and I’ll try to post once a week on subjects related to the delopment process of the game engine, the rules system, world building and gamebooks themselves.

Be sure to check back as more content gets added to the devlog. In the meantime, follow Scape-IT and SKALD on Twitter for all things RPG!

Have any questions or comments? Get in touch!

See you around!