Ahoy there Skald fans! The last weeks have been exciting in the Skald universe: The soundtrack has dropped, I’ve started streaming, gotten some new Skald tools, celebrated my wife’s birthday, gotten my second COVID shot and ran my first marathon!
The Skald Soundtrack is Out
Created by Skald composer and deranged genius Romanus Surt, the Skald soundtrack is now live on Steam!
The music for the game has gotten a lot of attention with it’s dark, unsettling ambience and I highly recommend checking it out. All proceeds from the sale go to Romanus Surt himself and as a great guy and fantastic artist, he truly deserves your patronage and attention.
If you backed Skald on Indiegogo or Kickstarter at “Knight” tier or higher you should have gotten a message from your platform with the Steam key for the album.
I’ve recently dipped my toes into streaming Skald development on Twitch and I have to say, so far I really like it. I’ve been coding and doing level design so far on the stream and I really enjoy the company as well as discussing my work process. I’d also love to have you guys tag along for some of my favourite RPGs every once in a while.
It seems like a very low effort way of keeping in touch with the community via video content since it doesn’t require any editing. If you enjoy watching streams, have questions about the Skald or just want to hang out, be sure to follow me on Twitch. I’ll be looking into finding times that work for both me and you guys, but in general I think the idea will be that if I’m working, I’ll consider streaming if what I’m doing might be interesting to follow in any way.
I’ve been doing a lot of work on level-design tools and actual level designing this week. In particular I’ve been working on elements of the Horryn village, keep and sewers using my newest level editor tools.
One of the big changes in the new workflow, is the ability to create prefabs of map components and then cut and paste them into new maps. The great thing is that the system works such that if I go back and change the “mother” prefab, the change will cascade to all its children automatically and this makes it so much easier to maintain and reuse components.
As an example, the sewer above is made out of prefab corridors and the tunnels above took about six mouse-presses to lay out. The time-savings for areas with a lot of repeating components (such as dungeons) will be huge.
In other words: Beta-testers should start getting ready to explore Horryn and its environs!
This one focuses on the inventory system and adds a lot of requested features like displaying items by categories and showing equipped items by characters.
There’s also a bunch of other features as well so here is a full list:
Pressing a quick button to open a screen (M to open Map) can also be used to close the same screen
You can toggle between fullscreen and window from Options -> Graphical
Game starts in fullscreen mode.
You can now see the loot after combat before deciding to take it
The game settings are saved from save to save
You can now toggle the “text crawl” on/off
You can now view and sort the inventory by category
You can hide or show equipped items from the main inventory
You now see the player model and all equipped items in a separate field in the inventory screens
The inventory can be fully operated by using the keyboard
You can now sell stacks of items with a single click
You can now hold your action until the end of turn
The active character now has a flashing outline in combat
Added the “Knock Back” feat which allows characters to push opponents in combat
You can access options from the intro menu
Weapons now show damage-type in the description
Right-clicking while in the inventory screen no longer activates an item if you’re not mousing over it
Using non-useable items no longer plays a use sound effect
For the next patch, I’m probably going to look into making combat smoother. I want to allow for more ations by the player and I need to look into a way to make that work that doesn’t rely on multi-layer, text-based menus.
Under the hood I’m currently also working on my editor tools. I’ve been adding in a search function and some tools to help spell checking (about time). For my map editor I’m currently creating maps tile by tile and I need to add the possibility of adding prefab segments into the map. It will make creating areas with a lot of repeating patterns (such as dungeons) a lot easier so I think that is going to provide quite the boost in productivity.
The Release Date
On the Steam page, the release date has been set to August 2nd 2021 for the Early Access version of the game.
That date is now coming up and I’m not ready for the EA yet. Part of the reason is that I’ve been prioritizing working on feedback from the demo. As you know, I got a lot more of it than I had expected and using it to make the game as good as possible is proving very worth-while.
So when is the new release date? I don’t know yet. Setting a date is hard it turns out. But rest assured that development is currently moving forwards at a very steady pace and the game keeps improving by the day.
There is also a question of how much of the game to have in the EA at release. My original plan has been to do pretty much 80-90% of the game before launching but I really need to think this through.
Experience from the demo shows me that a lot of players will prefer a shorter but more polished product that gets expanded as we go over a larger but more buggy experience.
What I’ll do is that I’ll finish implementing the first chapter (Idra) and see how that plays. If it feels substantial enough, I might consider doing a chapter-by-chapter launch (a bit like Larian is doing with BG 3).
Hope you’re not too disappointed with the postponement of the release date. The game is coming and you’re all helping make it great!
To support the game, keep playing the updates and offering feedback!
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).
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 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:
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
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).
The Skald: Against the Black Priory Prologue is now live on Steam and GOG!
This is a huge milestone for the project as it means that thousands of fresh eyes will be enjoying the game, testing it and offering feedback. It also goes a long way towards getting Skald on the radar of consumers, content creators and press.
I hope you all take the time to download the Prologue and give it a go. More importantly: Take two minutes to offer a review afterwards. This is hugely important for Steam and GOG visibility and it would be amazing if we can get as many eyes on the project as possible.
Leave any constructive feedback on the Steam or GOG forum-pages for the game.
There will always be polishing to do on the engine and rules implementation (such as how combat should work). In general, however, the coming months will see work move more towards implementing the narrative, adding feats, spells and classes properly (the current ones are mostly placeholder) and populating the game with art assets. Sound FX in particular are in line for some love.
To make sure the work flows nicely, I’ll be spending some time polishing the editor-tool so that adding stuff like scenes or character components is fast and easily maintained in the long run.
The plan is still to launch the Early Access (EA) version in August. However, this is depends on two things:
The feedback from the prologue.
How much of the narrative is ready.
The game does not need to be completed before EA but it should be stable, fun to play and offer enough content that you should be able to spend 20+ hours playing around with it.
Time will tell if that schedule holds. Just know that this game is getting all the love and care possible put into it and I can’t wait to get it out to you!
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).
‘Skald: Against the Black Priory’ is an old-school roleplaying game that combines modern design and a fully realised narrative with authentic 8-bit looks and charms.
Delve into a dark fantasy world, full of tragic heroes, violent deaths and Lovecraftian, cosmic horror. Explore an engaging, branching story mixed with rich exploration and crunchy, tactical, turn-based combat that will seem familiar yet innovative to RPG fans, old and new.
The game is currently in development and is set to release into “Early Access” in the summer of 2021.
Check out the store-page today and feel free to wishlist and play the free demo:
Lovingly crafted retro-style art
Experience a richly illustrated world of authentic pixel art using thousands of hand-drawn tiles and images
A palette inspired by the legendary Commodore 64 computer.
Optional CRT filter for that authentic old-school experience.
Deep character creation
Build your main character and recruit a party from among a dozen diverse characters, each with their own skill-set, agenda and personality.
Choose from a dozen classes and backgrounds as well as heaps of feats, spells and equipment as you take your party from level 1 to 20.
Crunchy tactical combat
Engage in challenging, fast-paced, turn- and grid-based combat.
Play it your way, with fully customizable difficulty and feedback settings. Or hit ‘auto-resolve’, lean back, and (hopefully) watch your party cleave a bloody path through their foes.
A richly detailed, living world
Explore the vast expanse of Freymark and the Outer Isles and watch your actions spell doom or salvation for the region.
Focus on the rich, branching narrative… Or live the life of a mercenary and explore varied sidequests and encounters – the plot will wait for you.
Manage your party as you make camp, recruit hirelings, travel by land and sea, and interact with powerful factions and their visions for the world.
Bigger than the box it came in
Skald was made possible by crowdfunding and already has a large, passionate and welcoming community that can’t wait to meet you.
By joining Skald’s Early Access you’ll have a direct line to the developer, get sneak peaks and give feedback on forthcoming plans and help shape the game into a modern classic.
We will publish the powerful tools used to create the game in an effort to support and encourage modding and content creation once the game has fully launched.
The demo is still fairly short (but longer than before at 2 hours+) and still focuses on the starting area of the game. It does however, rework the different locals to take advantage of the new level-design paradigm of larger, more complex local areas.
It also adds a new hub area, a vendor, a recruitable NPC, a bunch of NPCs and minor quests, some new monsters and items, random encounters and so forth.
In other words, in addition to offering a basis for testing a lot of new systems, it also contains a complete RPG gameplay loop.
However, it’s important to keep in mind: The purpose of the demo at this point is still to provide me with play testing – not to offer a fully complete, play experience.
This means that it’s super important that you
Realize that there are A LOT of rough edges
Take the time to offer constructive feedback if you play it!
What to look for when testing
Please use the Discord to report feedback on the following:
Most of the dialogue in the game is still pending editing for grammars and proofreading so feel free to give input on spelling etc. But more importantly: Keep an eye out for, and report and broken logic in the dialogue!
Try to keep an eye out for bugs related to how objects appear and spawn in-game. Especially after saving/loading and when entering or leaving areas. Do objects spawn where they shouldn’t?
If you exhaust the demo content, I’d be very interested in hearing how long it took you.
PLEASE report any crashes or freezes!
I’m not looking for:
Notes on balancing, character development (feats, spells etc) or combat encounters. These are all placeholder at the moment and there will be a more comprehensive overhaul of them in due time.
Notes on character models. These are mostly placeholder as I’m yet to add a larger variety of models and outfits.
The Next Steps
I’ll be doing a burst of fire-patches the next week or two in response to incoming feedback and then I’m planning to step back and do some work on a few larger technical issues I identified whilst making the demo.
I’ll also be adding a few new batches of content as I flesh out the refugee-camp and even open the way into the ruins of Horryn so stay posted for that!
The end goal for this round of demos is to have a well-rounded and semi-polished public demo for use in promotion; especially towards press and content creators.
Let Word Spread Forth!
Skald has the best community in RPGs. Ever. It’s a huge joy, support and resource to me and we’re truly making this game together!
Honestly, the size, interest and support of the community is the bread and butter of the project at this point, and the best way to keep making SKALD great, is to keep the community growing!
And so your Wizard-Emperor decrees:
If you played the demo and enjoyed it, please tell your friends on forums, Twitter, Discords, Reddits and wherever else you hang! Invite them to our Discord server and bid them check out the blog!
That’s it for now. Enjoy the demo and please get in touch via the Discord or Twitter for all things Skald-related.
Hello and merry yule-tide to all friends, fans and followers of the Skald roleplaying game! With 2020 coming to an end, it feels about time for another project update. After all, there’s quite a few new features to show off and even a few delays (believe it or not).
So, what’s been going in the SKALDiverse?
The final game will contain quite a few minor towns and at least one major city. Figuring out how to create large, interesting and good-looking urban environments has been a huge point on my to-do list and something I’ve spent most of the last 6 weeks figuring out.
I’ve spent a lot of time thinking about what kind of architectural style should underlie the look of the Gallina Empire. Having gone back and forth a few time I’m tending towards “Romanesque“: The rounded arches and pillars lend themselves very well to the resolution of the game and the palette feels sufficient to portray a large variation in materials.
The images above are some early examples of the tile-set. Pretty happy so far and now it comes down to adding a bit more flourish. I just love the look of Roman buildings in the Middle-ages where the secrets that went into building them are long gone and they end up being patchworks of increasingly poor repairs. Seems a pretty good fit for this period in the Gallian Empire so why not embrace it!
A second pretty big change was making maps a bit more integrated by having building interiors and exteriors be on the same map. A large reason for this change is that it allows me to have the players be able to enter any structure with minimal extra work. Previously this would have required that I created submaps for every single interior and this quickly becomes messy. I still can if I want to, but for most buildings it’s much more interesting to have it all on one map.
Now you can try and steal from a vendor, have him catch you, flee into the street, dive into a tavern and dash through the kitchen to the back exit and alleys. I love stuff like that.
I also spent quite a bit improving the look of the fog of war. The way it just snapped into place tile by tile, was a bit jarring. Notice how it now “grows” and retracts in a more organic way. Believe me when I say, it makes a huge difference when you play the game on full-screen!
I’ve also spent quite a few hours polishing the combat system. As you’ll recall, I massively overhauled in October and that was a pretty big update that still has me discovering occasional bugs and idiosyncrasies.
None the less, it plays super-nice now and in combination with the new, more complex city maps, it’s truly taking the game to the next level.
Well, it’s no secret that I had hoped to make Early Access by the end of 2020. That’s obviously not going to happen (lol).
No one likes to have delays in their project and I’m no different. However, playing the game today and looking at the build from 6 months ago, all I can say is that it’s been worth every second of work so far.
I always knew the combat system and city maps were “on the chopping block”, and looking back now I’m super happy I took the time to change them. For what it’s worth there are no more major systems that are scheduled for revision (tough there will of course be tons of refinement going on).
Based on that I think a careful estimate is early access in the summer of 2021.
I hope that’s not a huge disappointment to you guys and that you share my enthusiasm for how the game looks at the moment!
The next big milestone for me is finishing the “press demo” which will include most of the first chapter of the game. It is intended for playtesting and as a demo for the press, and content-creators that follow SKALD. This will be around early Q1 2021.
From me to all of you…
Thank you so much for all of your support, friendship, advice, encouragement and enthusiasm throughout 2020. It’s been a hell of a year for a lot of you guys but the SKALD community has remained a warm, inviting tavern in a storm for so many of us. This is a strong reminder of the power of games to comfort, entertain and bind us together.
So from me to all of you: Seasons greetings and a happy new year!
After careful consideration, I’ve made the decision to pivot from a September full launch to an “Early Access” launch late fall of 2020.
What does that mean?
“Early Access” (EA) is a type of distribution where customers buy access to a pre-release version of a game. For SKALD, this means that Steam-users (for starters) will be able to buy access to the SKALD Beta sometime in the fall of 2020.
Backers will of course receive these keys as part of their rewards as soon as we go live. Until then, closed Beta will continue for backers.
The plan is to finish the game’s narrative critical path before the EA release. This means that the game should be about 75% content complete in terms of content but still quite rough around the edges.
The plan is for the complete game to launch fully in the first half of 2021.
For those of you who backed the game on Kickstarter and Indiegogo, this means that reward fulfillment will be postponed until we get closer to the full release.
The plan initially was to accept a product that was a little rough around the edges upon release and then do post-release patches and content additions.
After talking to marketing-professionals and fellow game-designers I’ve realized that it is much healthier for the project to instead brand the “release” as Early Access. This clearly communicates my intentions and the state of the project.
The decision has also been expedited by the fact that the project is behind the initial schedule in terms of play-testing. The delay is partially due to current world events (enough said), partially because the demo->feedback->update cycle has been slower than expected and partially because an influx of money has allowed us to aim for a higher narrative ambition and great writing takes time.
No cause for alarm
Though the schedule now looks slightly different, the project is very healthy:
It is very well funded and I don’t have any reason to rush a launch for financial gain
Early Access will bring more play-testers which, in turn, will lead to a much more polished end-product
A less rushed launch will give us more time to create side-content and result in more fleshed-out world
All in all, this is the best for the project and I’m counting on the continued support and understanding of the community to help make SKALD an AWESOME game.
Believe me: Development is proceeding as fast as it is humanly possible and I’m super excited for the finished product!
I’m releasing an updated Beta-demo for backers in the next month or so. The demo is a bit delayed, but there is a good reason for this: Each Beta-demo at this stage will potentially corrupt save data. This means that currently, each demo-launch may force a restart and this will cause tester fatigue pretty fast. Since I rely on your feedback, I’d rather you have a bit more content to explore once you sit down with the demo.
Speaking of demo, I’ve made a pretty big change to the basic design of the game:
Combat is now grid-based.
I’ve been going back and forth on this for a long time now and I don’t make changes like this lightly. However, the old system lacked a bit of the expressiveness and transparency I wanted for SKALD and working with it was too limiting. Being someone who plays the game EVERY day I can say the new combat system is a lot of fun. I can’t wait to really start fleshing out more feats and spells that interact with the physicality of the battlefield.
It’s back to work for me! I really hope you’ll stay pumped for SKALD and I can’t wait to bring you more sweet content throughout the summer and fall.
If you haven’t already, I wrote two game-design articles a while back and you might want to check them out if you’re interested in the subject:
The Last of Us Part 2 is out and it’s proving to be highly divisive. One of the main themes of the game is revenge and having seen the first 10 hours or so of the game I felt inspired to write an article exploring the issue of character vs player motivation in open world games.
This article is not a review of the The Last of Us Part 2 but it might contain SLIGHT SPOILERS.
I’ve been spending a lot of time recently working on narrative design for my own upcoming game: SKALD: Against the Black Priory. One of the questions I’ve been pondering is: How do you align the motivations of the player with the motivations of the player’s in-game character in open-world games?
Using revenge stories as an example: They are dramatic, visceral and cathartic and often highly appealing. Their use in games, however, comes with some challenges that might not be evident from their use in other media. While the main-character might be out for blood, the player would much rather collect junk.
For many types of games (but certainly not all), it is expected that the game’s in-game main character (the avatar) comes with their own motivation. For the narrative experience to be appealing, the player should:
Understand the character’s motivation and goals
Empathize with the character’s motivation and goals
Actively share the character’s motivation and goals
Additionally, the player’s motivation should also not conflict with the character’s motivation and goals.
From the list above you can see that the points are in increasing order of importance: It’s probably better if we could make a game where the player not only understands and empathizes with character’s motivation, but also feels like their own motivation overlaps with the character’s.
A revenge quest (or revenge story) is a common trope in fiction. From the Iliad to Kill Bill, these stories feature protagonists who are driven by an urge to get revenge (often violently) against the antagonist for some trauma that has been inflicted upon them.
For these stories to be effective, the triggering (traumatic) event often comes with enough of an emotional impact that the player/viewer/reader shares in the protagonist’s desire for cathartic revenge.
Looking at our three points from above, it’s not difficult to see why it’s so popular to have characters with motivation born out of some trauma: It is highly universal and offers us (melo-) dramatic narratives where we understand, empathize with and share the motivation and goals of the protagonist.
Does this mean that revenge-quests and similar stories are ideal for games? As always the answers is not yes or no, but rather it comes down to understanding the consequences of our design choices.
A Simple Model of Motivation
A common and simple psychological model for describing motivation it that of intrinsic vs extrinsic motivation. It is commonly used in fields such as management, education and sports and, though it might seem a bit simplistic, it readily provides some interesting insights.
Simply put, when we perform tasks and actions to gain some external reward or avoid punishment we experience external motivation.
Going to work because you want to get payed is a classical example of this.
Intrinsic motivation on the other hand is what we experience when we perform a task because we find it personally rewarding. In other words: performing an activity for its own sake rather than the desire for some external reward.
Doing your job because you enjoy the work itself (as opposed to doing it just to get payed) is a typical example of intrinsic motivation.
The In-Game Context
Motivation is complex (as is all human behavior) and it’s not really possible to describe it in terms of absolutes. Within the framework of extrinsic vs intrinsic motivation it is rare that we are 100% on one end or another of the scale. For example, when we say that we are extrinsically motivated, what we really mean is probably that we are mostly extrinsically motivated.
Tasks such as playing games can be highly complex since they often consist of so many sub-tasks. This means that our motivation for each of those tasks may vary greatly; I’m intrinsically motivated to play most games since I enjoy the act of gaming for its own sake. However, within that context, I would say my motivation to collect 10 wolf-pelts is mostly extrinsic as this will get me rewards (gold and XP).
The wolf-pelt example is not random: It’s safe to say that games with open worlds (such as roleplaying games and open-world shooters) often contain tasks where we might feel primarily extrinsically motivated. We might do “chores” because they rewards us in the long run. Compare this to a racing game where the reward loop is so compressed that we feel instant gratification throughout the entire play experience.
In occupational psychology, intrinsic motivation is often held up as being preferable. This comes from research that shows that individuals with a high degree of intrinsic motivation perform better than those with a high degree of extrinsic motivation.
For this discussion however, I think we should be careful to automatically place intrinsic motivation above extrinsic motivation. This is especially true for roleplaying- or open-world games where the reward-loops are wide enough that they contain tasks that might feel like chores but where the sum of the experience nonetheless is a fun play-experience.
To put it in another way: It’s certainly not a failure of design if your game contains sub-tasks that causes the player to experience both kinds of motivation within the context of the game. If that makes for a good game, players will feel intrinsically motivated to interact with it.
Player vs Character Motivation
Lets try to apply some of the theory we’ve discussed so far.
In the kinds of games we are discussing today players are typically either:
a) provided with an establish character (Ellie, Geralt of Rivia, Super Mario etc) that comes fleshed out both in terms of appearance, personality and backstory.
b) provided a blank character that has some backstory attached to it (such as in certain RPGs where we get to create fresh characters but with the baggage of being “the dragon born” or something in that vein).
In both cases, the game almost always provides a motivation for the character: a raison d’etre for the character’s adventuring career. In the kinds of narratives we are interested in today, this motivation is often highly intrinsic and triggered by some dramatic event.
Importantly: The more dramatic the triggering event – the more highly motivated it is implied that the game’s character will be.
Consider the Last of Us Part 2. We play most of the game as Ellie. Motivated by a burning desire for revenge, she sets out on an epic quest across the gorgeous ruined landscapes of post-apocalyptic Seattle.
It is pretty clear that the character of Ellie is written to be heavily internally motivated. She is not interested in gold or getting new loot; she just has a burning desire for revenge.
And for anyone who plays the game, her motivation and goal easily checks all of our three boxes:
We understand her motivation and goals
We empathize with her motivation and goals
We actively share her motivation and goals – we ALSO want the catharsis of revenge.
As the game moves past it’s intro, it’s hard not to partake in Ellie’s thirst for blood. The character’s motivation and the player’s motivation is alligned!
However, something happens a few hours into the game: The game world opens up. It turns out exploring the post-apocalypse is both fun and interesting. Roaming around whilst listening to the small-talk between Ellie and her travelling companion interspersed by bursts of intense action is fun. So fun in fact that it’s easy to forget why you are out there in the first place.
Let’s look at a classic RPG that I always found had a similar issue: Baldur’s Gate 2.
The first part of the game has the following quest: Imoen, a recurring character from the first game and your step sister, is kidnapped and a large part of the first game is dedicated to you gathering enough gold to rescue her.
At face value, the trope of having to rescue a loved-one in danger is certainly dramatic and universal enough that we should ideally have no problem in sharing the character’s intrinsic motivation.
Baldur’s Gate 2 is one of the best RPGs ever made. However, the first part of the game is often consider the best part of the game; with a huge and interesting game world full of cool quests and awesome characters. Many players will forget Imoen by the time they leave the city gates and they’ll put off rescuing her for as long as they can.
Using melodramatic core narratives might imbue the character with a lot of strong intrinsic motivation and the player should ideally have no problem sharing that motivation. However, the disconnect occurs once we supply the player with a game-world which is so large and appealing that the player will feel much more motivated to explore it rather resolve the games core conflict. In other words, on one hand the game is telling you to care about Ellie getting revenge (or rescuing Imoen or killing Alduin or finding a new waterchip). On the other hand it’s giving the player a world full of distractions.
To put it in another way: The game design is causing our motivation for the trivial tasks of exploration to eclipse our motivation for resolving the main-character’s grand conflict.
This is an example of a disconnect between the game’s narrative and mechanics. In other words, what we call ludonarrative dissonance.
First of all, I’m not saying you should not use highly intrinsically motivated characters as avatars in open-world games. As I said in the beginning, I’m only trying to outline some potential challenges and solutions.
I’m certainly not claiming I cracked this nut with SKALD as the game is still in development. However, I have thought about it a lot, and I’ve chose to adopt a fairly defensive posture to the problem. Here are seven of the main takeaways that I’m currently using to inform SKALD’s narrative design:
1) Good Narrative design is important
This is a no-brainer and I’m not going to belabor it beyond saying: If you’re making a narrative-heavy game of any sort you need to respect the amount of work that goes into narrative design. Don’t let the narrative take a back-seat to mechanics. Ideally: Get a narrative designer!
2) Don’t fight human nature
I’ll repeat what I said in my last article on testing in RPGs: Don’t fight human nature. If you find yourself frustrated that people are playing your game “wrong”, you’ve probably designed your game wrong.
Don’t fall into the pit-trap of trying to sanction or punish unwanted behavior. Instead try figure out why players act the way they do. Players aren’t failing to connect with your narrative because they are simpletons!
3) BE careful with DIALing up the drama
At first glance, one way of dealing with a miss-match between player and character motivations could be to turn up the level of drama and increase the stakes. Surely that will make the player care?
The pit-fall here is that in open-world games there should be room for the player to keep ignoring the core conflict. No matter how high we make the stakes for the character, if we’re not willing to punish the player for ignoring the core conflict (and I don’t think you should), we risk a greater feeling of dissonance as we try to force the player to share the characters intrinsic motivation.
If we ARE willing to railroad the player we aren’t really making an open world anymore (and that might be fine?).
Personally, this is the point that set me free: Accept that the player’s motivation might not equal the characters motivation.
That is to say: You should design your game and narrative towards this goal but it is dangerous to count on it.
You may very well try to communicate that the game really wants you to care about the character’s core conflict but what if the player simply chooses not to engage? Are they playing the game wrong?
Whenever I write out story-beats in my game I always ask myself “how can we advance the narrative at this point without breaking immersion if the character does not engage ?”
5) Try to identify what is motivating the player at each point in the game
A good way of looping the player in at each point in the game is to ask yourself (through analysis, experience and testing) what’s motivating the player at each point in the game? Is it collecting loot? Resolving sub-quests? Seeing if you can kill all NPCs in the game? Then, ask yourself what should ideally be motivating the character at that point?
You may find ways of aligning those motivations. Is you game-design causing players to become very interested in loot? Place some cool items along your main plot-line and overtly allow the player to express that they’re “in it for the money”.
But be careful: This might not work if your core premise is that the character is out for revenge against the dragon who ate their grandmother! How do you rationalize the player spending hours looting village homes instead of seeking revenge?
6) Don’t have the characters motivation compete with the players motivation
I try to make sure that the player does not need to choose between exploring the world and furthering the plot. Players are often very willing to suspend their disbelief and act “out of character” and then return to acting in-character. The problem arises if the game keeps reminding them that they are acting out of character.
This means that the core narrative should wait for the player and do so gracefully!
A typical failure to do this is when a game presents an urgent crisis and then asks the player to drop whatever they are doing and run off to resolve it. Comically the game will then wait indefinitely for the player who is free to ignore the whole deal.
7) “Opt-In” Motivation
As I’ve said, you shouldn’t take your player’s interest in the main character’s core conflict for granted. However what you might find, is that as the game progresses and the players get to stretch their legs, the player and character motivation may begin to converge. Plan for this and try to make it as seamless as possible.
I honestly think Skyrim does a pretty good job of this – especially in the early part of the game. The game does not assume the player will be interested in the main quest-line. It feels just as natural to just wander of for hours to explore. But more importantly: Once you do choose to engage, it doesn’t really feel immersion-breaking that you “opted” back in.
This post became a bit longer than I planned. I hope it still makes sense at this point.
As a solo game-developer, it helps me a lot to write stuff like this out and have you guys give feedback. So if you have comments, ideas or differing perspectives I would love to hear them!
“Roll for perception!”, “How much is your Reflex save?”, “#IF(Strength>15)#THEN(‘You successfully lift the gate!’)”
Attribute tests are a staple of the roleplaying game (RPG) genre. As a narrative, text-heavy RPG, “SKALD: Against the Black Priory “is no exception.
Even though such systems might seem trivial, I find that they require quite a bit of consideration to design and implement successfully. The following are some of my musings on the subject and hopefully this might serve as a basis for a broader discussion of the subject.
There is also a little treat for old-school RPG and Ultima fans at the end of the article so stay with me!
What do I mean by “Attribute-Tests”?
Basically, an attribute-test is a test against one of the attributes an RPG character has. This could be a test against the characters “lock-picking” skill to try and open a locked door or a test of the characters “strength” score to try and lift a chest full of gold or even checking a non-numeric character attribute (such as seeing if the character is the right class to join a guild).
For the purpose of this article, I’d also like to divide attribute-tests into two rough categories: “systemic” and “scripted”.
Systemic attribute-testsare hard-coded into the game’s sub-systems. Rolling for initiative at the start of combat, or rolling to hit an opponent are examples of this.
Scripted attribute-testsare added at the content level of the game (as opposed to in the engine itself) – often through some form of scripting language and they are often non-combat related. An example of this might be testing the characters charisma score to try and persuade an NPC during a conversation.
Note that scripted attribute-tests do not have to be dialogue-related! They can just as well be short “gamebook” style segments where the player interacts with the environment. There is however, a lot of precedence for using the dialogue system to present these interactions in modern RPGs and this is also the approach I use in SKALD.
We’ll mostly be talking about scripted attribute-tests in the rest of this article.
Why use Attribute-Tests?
Systemic attribute-tests are as old as RPGs themselves. This is because they are so closely tied to the wargame-esque style of resolving conflicts with dice that was the basis of early RPGs such as “Dungeons and Dragons”.
Scripted attribute tests are a bit less ubiquitous (especially in early CRPGs). Due to technical constraints, early CRPGs placed more emphasis on combat and less on roleplaying and dialogue-based problem solving. It wasn’t really until games like Fallout and the infinity engine games (the Baldur’s Gate series, Planescape: Torment etc) that developers really started exploring a wider use of attribute-tests to enrich the dialogue and storytelling.
In more modern CRPGs, scripted attribute-tests are less wide-spread than you would think. This is probably due to the fact that they often require more complex character development (you need non-combat skills), more storytelling using text (which might turn away certain demographics), and they are often associated with branching narratives (which are more expensive to make).
So this begs the question: Why do we include scripted attribute-tests in CRPGs at all?
They remind us of the genre’s tabletop roots by invoking the verbal interplay between the game-master and players.
They can add suspense by using random “dice-rolls” to resolve non-combat challenges.
They can add resource sinks by introducing a wider array of challenge-types for the players to overcome.
They show progression by having the players eventually finding themselves being able to do things they couldn’t before (beyond combat).
They allow for a wider range of player expression by giving the player more ways to interact with the world via their attributes (such as talking your way past enemies instead of fighting them).
They can gate content either by holding the players off until they reach a certain level of skill or by giving varying narrative experiences based on character build.
The point is that scripted attribute-tests add a bunch of interesting tools for CRPG designers. That brings us to the next point:
The following might seem pedantic but there is a surprising number of variables to tune when implementing scripted attribute tests successfully. Here are a few considerations:
Overt vs hidden tests
In any CRPG, a lot of the script logic going on under the hood will be hidden. This is a good thing since it’s not necessary for the player to know that the script discreetly checked to see if the party was carrying such and such item when entering such and such area. Games like the early Fallout games or Baldur’s Gate does this extensively and you’ll have different dialogue choices based on things like your charisma or your intelligence etc.
The advantage to this is that it hides a bit of the inner workings of the system and it makes it harder to “game” the system. Rather than worrying about how many ranks you have in a given skill, the emphasis might be placed more on having an immersive roleplaying experience.
This, however, is also the disadvantage of this approach: It robs the player of the ability to make informed decisions about how to build their character since they can never be sure about how the mechanics of the game work. Was the outcome of the conversation the result of poor dialogue choices or was it the result of a hidden charisma test?
Random vs Deterministic
When the character performs an attribute test, is it resolved through a random “dice roll” or will it always succeed or fail based on a threshold (such as in Fallout: New Vegas)?
If the test is deterministic, does the game show you (or even allow you to use) options with tests that it knows you cannot succeed?
On one hand, it does show players what they might work towards, whilst on the other hand it can look a lot like an invitation to try and “game” their character build towards certain solutions.
Randomized tests, on the other hand, might cause players to save before every test and reload until they succeed.
Does the game explicitly show the difficulty of the test? If so, how is this expressed to the player? By a form of difficulty class (“DC 15” – what does that even mean?) or a percentage chance of success?
Do you need to foreshadow the consequences of failing the test?
Going back to the solution chosen in Fallout: New Vegas (showing you both “legal” and “illegal” choices AND their difficulty), this removes a lot of the uncertainty or risk associated with the test.
On the other hand, it also makes it 100% clear what is required of the player and allows them to make well informed choices both on how to deal with the situation at hand and as to how they should develop their character.
The following is a handful of principles I’ve arrived at when working on implementing attribute tests in SKALD. This is my subjective and semi-professional (at best) opinion so take it for what it is.
Game mechanics are a language
Game mechanics are saturated with meaning and when we use them, we are “talking” to the player. Presenting the player with a dialogue option to use their Athletics skill might mean that we are saying “Hey, there is a cool reward behind this option for players who invested in athletics!” or we might be saying “You better have a decent athletics stat or the game will punish you”.
The thing is, even if we don’t explicitly include a message, players will supply their own. So in other words: It’s a good idea to figure out what you’re trying to say with your tests and then keep that message consistent.
Don’t set traps for your players
Tying in with the point above, you should never create traps for your players with your tests. This doesn’t mean that tests can’t have severe consequences for failure. It does, however mean, that if they DO have severe consequences, this should be clearly communicated throughout the game.
For instance, say your game hasn’t punished the player for attempting tests in which they have low chance of success so far. Then, suddenly you including a test where failure causes automatic player death. This is usually poor design – not because the consequence was harsh, but because the player had no way of anticipating it.
So to reiterate: keep the message consistent!
Don’t fight human nature
We don’t really get to decide how people play the game. If you include difficult tests with severe consequences, players will save-scum. If you gate cool content behind certain skill-tests, players will speculate in “gaming” that skill.
It’s usually a bad idea to try and sanction such behaviors. Instead, try to ask yourself why the players are acting the way they do.
In terms of attribute tests, the answer is often that players don’t like being punished and they HATE having things taken away or kept from them. You might need to…
Make Failure interesting
This is a big one! For narrative design in RPGs, I would say it’s a bit of a holy grail. As any tabletop RPG player will tell you, the most fun sessions are often the result of failed skill checks. How to pull this off is a big topic and I’m can only supply my personal take on it.
As a general rule, I would say that a good starting point is to avoid making failures feel like punishment. The players don’t control the roll of the dice and if a player ends up feeling like they are being punished for failing a 95% test they might (rightfully) feel unfairly treated.
One way of “improving” failures is to offer rewards whether the player succeeds or not but give a bigger reward for a success. Players love rewards and they especially hate missing out on stuff due to the roll of the dice.
Example:A player is using Diplomacy to try and get information on a subject from an informant. A failure might still yield the relevant information whereas a success will additionally have the informant give the player an interesting rumor that leads to a hidden reward.
Another approach is to consider a test as a narrative branching point where both branches (success or failure) are equally valid but play out differently.
Example: The players are trying to get into a castle and they attempt to either sneak or talk their way past the guards. If they succeed: Fine! But if they fail, instead of forcing the players to now kill their way through the whole castle, the guards might give the players an option to surrender and the players might find themselves in a cell they now need to escape from by inciting a prisoner revolt.
What techniques do you use for making failure interesting? I’d sure love to hear them!
Don’t mix tests and choices
Attribute tests are often presented in the same setting as choices (e.g. moral, tactical or thematic choices). Be careful if you overlay a moral choice onto a skill check.
Let’s say the player is interrogating a prisoner and the two choices are to either hurt the prisoner or use diplomacy to get what you need. So far so good.
The issue becomes when the writer phrases the diplomacy option as the player threatening to kill the prisoners family.
The player might have played their character as a charming witty bard up to this point but now you’re forcing the player to chose between using their favorite skill or acting out-of-character.
An example of this is occurring in the first image of this post. There we see a conflict where I’ve made it so that using diplomacy requires you to be kind of an asshole. Not good design at all.
Don’t make dump-stats
Does your game have 8 skills that are all used in attribute tests? Make sure they all get enough screen time throughout the game or it might feel like a trap to invest in one of them. In general, I think it’s better to have a handful of well utilized attributes rather than a lot of underused attributes.
I’m writing this article because it helps me to explore the subject for my own part. I certainly don’t have all the answers and if you have comments, ideas or differing perspectives I would love to hear them!
If you’re reading this, chances are you’re an Ultima fan! Well, I’ve got some great Kickstarter-news for you:
Corven – Path of Redemption is a story-driven, open world RPG inspired by the Ultima series. Richard Garriott contributed to the storyline and his alter ego “Lord British” appears in the game! Check out their Kickstarter page where you can find a trailer and a playable demo, and consider becoming a backer to make this spiritual Ultima successor happen!
That’s all for now! Have a fantastic day everyone!