SKALD: Against the Black Priory - Prologue Patch and Experience
-
Category: News ArchiveHits: 1172
Scape-IT released a prologue demo of their retro RPG SKALD: Against the Black Priory nearly a month ago. Now, they follow it up with a pretty big patch that addresses a whole bunch of issues ranging from typos to game-breaking bugs and everything in-between.
Along with this patch, comes a developer blog talking about the experience of launching a demo and dealing with player feedback, platform-specific red tape, and so on. It's quite an interesting read. Here's the full thing:
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!
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[...]
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:
FeaturesBugs
- 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
Launching a Prologue: A Mid-Mortem
- 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 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).
AL
