Where We’re Going

It’s been a while since we hit feature complete. That shifted game development into a different phase: making everything work. This is both a matter of finding and fixing bugs, and balancing and tuning the economic game and the overall story to make sure things are fun. There’s usually not a lot of interesting things to say, which is partly why there hasn’t been a development blog post in a while. We found bugs, we fixed bugs. Day after day.

We did notice that two of the story themes could intertwine a bit more, so Robin Laws wrote two scenes to deal with that, and another three that deal with individual leaders. Those are now coded.

We invited a small number of outside playtesters to give their feedback, and have been trying to improve and clarify things based on that.

It’s possible to win the game without encountering bugs: one playtester said, “I’m embarrassed to report I haven’t found an obvious bug yet. Did complete a play in easy.” But there still are a lot of issues we need to fix. They may show up only when you get two scenes in a particular order, or have a specific combination of advisors, or choose a play style. Any one player won’t see them, but they need to be fixed. It’s hard to know how many of these there are. And analyzing them can be tricky. Did someone run out of cows because the game is broken, or because they made poor decisions, or because the user interface let them trade away more than they intended?

Between QA and playtesters, we’re still finding enough issues that I don’t think the game is high enough quality to ship in the near future. And a few areas aren’t completely tested (such as making sure every achievement can actually be earned).

the goose peopleThere’s another complication to figuring out a ship date: we’re moving. After five years in Philadelphia, A Sharp will be returning to the Pacific Northwest next month. (We’re heading to Tacoma, mostly for family reasons.) Coordinating this and physically moving across the United States is going to take a fair amount of time.

Without a reliable completion date, and with relocation thrown in, it doesn’t make sense to try to release the game this year. (“This year” would realistically mean “before the Christmas holidays,” so there are only 2 months left anyway.)

So we are moving our guess at a release date to 2018. We want to make sure the game is done right, and we want to have some lead time to start marketing.

I’m disappointed that we aren’t done yet, but I think the project is in good shape. As a complex bit of software that’s in alpha, the number of bugs feels reasonable. And one playtester wrote, “I have been spending waaaaay too much time playing this game. I am every bit as addicted to it as I was to KoDP the first time it was released, and I thought I was over that kind of behavior.”

Feature Complete

On Monday I decided it was reasonable to consider the game to have hit the Feature Complete milestone.

Watercolors In Progress

In software this is sometimes also called “Alpha.” It means that everything we plan to include in the game is complete, at least to a reasonable level of quality. There are still known bugs, and some of the art is still being worked on. (All of it is at least inked, however — see the example work in progress.)

In terms of the project, it means we can invite a small number of external playtesters to try the game and give feedback. The emphasis is on small, because there are after all known bugs, and there are likely to be confusing bits. It doesn’t help if a dozen people tell me that an icon is unclear. Better to hear that from one or two and then iterate.

It turned out that one of the important bugs we found was actually in our bug reporting. The game now does a better job of capturing information about an issue, so playtesters don’t have to jump through hoops to do so.

We’re also starting to get data on how the game is actually played. This has led to some minor tuning, and will surely result in more. We’ll also learn if systems work well, or if anything else would help.

Meanwhile, the QA team is continuing to make sure all the game situations have been exercised and make sense. (We recently had a discussion about whether one scene should be dropped entirely because of changes that had been made since it was written.)

At some point, we’ll have all the art complete, changes made, and bugs fixed. That will put us at the “Beta” milestone and we’ll look for more playtesters. (Don’t ask now! I’m not sure exactly what we’ll be looking for at that point.)

And I still can’t figure out a release date. That will depend on how alpha testing goes. But we are definitely progressing.

Find Once, Fix Everywhere

Just got a bug report from QA that a scene threw up an error. It was pretty easy to see that it couldn’t find a friendly clan to visit you.

That turned out to have happened because of using the debug tools to have everyone feuding (to make it easy to test resolving feuds). This is an unlikely situation, but it’s certainly possible to get a lot of clans to hate you, if you play the right (wrong?) way. So it’s a valid bug, and I fixed it.

Given how many scenes are in the game, I figure any bug is probably somewhere else as well. So figured I should go back to our automated tests and run them in their nonstandard configurations. I don’t usually do this, partly because they’re mutually exclusive, but also because some of them can take a long time (in fact, as I type this I’m running one … that just finished in just under 26 minutes).

But sure enough, enabling TEST_ALL_FEUDING found several scenes that would have trouble. It also gave a lot of false positives, since the brute force testing ignores scene conditions. (Scenes almost always have conditions that prevent them from being randomly chosen when they’re not appropriate.)

So today I’ve been dealing with that, and also TEST_NO_CHIEF, TEST_NO_GOODS, TEST_NO_RING, TEST_NO_WARRIORS, TEST_ALL_HATE, and TEST_Q_BRANCHES.

July Status Update

Six Age has a lot of art, and it’s almost all complete. I just sent out the final assignment today. We may still do a little reworking of illustrations and UI assets, but technically what’s there now could ship.

The music is in similar shape. We’ve been trying to track down some bugs (are they in the underlying engine? my code? the music itself? the operating system?).

QA is still pushing to get all scenes and events exhaustively tested. Bugs range from typos, to logic flaws, to “after a failed, interrupted cattle raid, the news after a heroic combat doesn’t show up at the right time.” (That’s not quite how it was reported, it took much of a day to figure out the first part.)

We’re also playing the game. It’s quite possible to win and to lose. Unlike when we did KoDP, I’m capturing data so I can see what went wrong (or right) — a recent loss was an event that turned out to be much harsher than we expected. There’s a lot of randomness in the game, but I’m trying to tune it so one unlucky break (or one bad decision) won’t sink you.

Not yet. Sorry to interrupt, but I know you were going to ask if you could beta test. There are still a few last features I want to get finished. (In theory I could drop difficulty level, but it’s on the list to go in.) And there is no point sending it out with known bugs. At some point we will be looking for outside testers, but it will still be a while.

Time to Face the Music

We’ve been working with Stan LePard (who did the music for King of Dragon Pass) on music and sound effects for some time, but it was only this week that he delivered them all in a form that’s playable with our sound engine (Wwise).

The file was 715 MB, which dwarfs the rest of the game. But that was before doing any audio compression, and it looks like audio will take no more than about 100 MB.

I had recently made sure that every interactive scene had music, and hooked up some of the user interface sounds. But there were a lot that weren’t in, particularly related to transitions and combat. So this week has been a scramble to play the appropriate sound and find audio bugs.

According to QA,

I get so annoyed when I’m away from my phone long enough while writing a bug that the phone switches off and the music stops. I’m like, where’d the pretty music go?!

We’re still experimenting with compression levels and formats (both for sound quality and performance). I have been so busy making it work that I really haven’t had a chance to listen critically with headphones on, but I hope to do that soon.

Difficulty Level

When I started seriously thinking about Six Ages, I decided I didn’t want to have difficulty levels.

This is partly because King of Dragon Pass didn’t do a particularly good job with them. The hardest setting was certainly harder than the easiest one, but I think calling the easiest one “Easy” was a mistake. The game itself wasn’t particularly easy, and if a player thought they were experienced at similar games, they might try a harder setting and become frustrated. (I changed the labels to begin at “Normal” as part of the version 2.0 reworking, to clarify this.) And the effects of the settings weren’t explained. In general, King of Dragon Pass stays immersive and doesn’t mention game terms, but this is before play begins.

Even if they had been explained, it’s one more thing to decide before you get to the meat of the game.

So my plan was to focus on tuning the game, and make sure that was right.

Then I asked Ken Rolston to give some feedback on the latest Six Ages build. One of his key items was that he missed KoDP’s difficulty options at the beginning of a new game.

We had a short discussion about this, since Ken said, “when working with Raphael van Lierop on The Long Dark, the single most important thing I worked on was persuading Raphael to add difficulty levels.” I’m pretty sure Ken made many other contributions, but at the very least I needed to reconsider my design.

Certainly difficulty levels are a simple way to accommodate players of different skill. They also hint at replayability (your future self after winning is likely to be at a different skill level, so you might want to try a more challenging level). And while Ken didn’t say this, if he missed difficulty levels, other players might as well. Starting players off with even a minor disappointment isn’t the best experience!

So I will be adding three levels of difficulty: Normal (since this is how I expect people will play), Hard, and Harsh.

I haven’t figured out exactly what these mean, but the basic idea is that Hard will make careful resource management more important, and Harsh may feel like all Glorantha is against you. The game system has a lot of difficulty levers, including

  • starting resources
  • likelihood of raiding
  • level of external threats (e.g. Undead and Chaos in KoDP)
  • harvest quality
  • various parameters for adaptive difficulty

I want to show an explanation of the chosen difficulty, so I mocked up a couple UI designs. Now that it’s in the game, I may further tweak the intro (because it is indeed one more choice, and takes up space on a screen that may make other items less prominent).

And I’ll start adjusting things to see how big a difference it makes.

Leveraging QA

giving a potRight now, the game is undergoing internal testing while being finished. Most of the bugs are easy to deal with: fix a typo, clarify something that’s unclear, fix a logic error, or make sure advice and recommendation match.

One that came in today had to deal with being unable to proceed after having decided to give gifts, when your clan had no goods to give. The specific script was

[ChooseYesNo("Do you take a gift?")]
yes: {
    w = ChooseGoods(“What do you give to them?”)
    TransferGoods(otherClan, w)
}

Normally players who have no wealth wouldn’t be choosing to gift, and it wouldn’t be a problem. But of course part of QA’s job is to test the boundaries.

It would be easy enough to fix this scene, but this has the potential to be a wider problem. ChooseGoods is used fairly often. Any of those situations had the potential of failing, too. One answer to that is to do a code sweep, searching for all occurrences, and making sure they are conditioned. But that’s a manual step, which means it can be prone to error (especially if there are lots of places).

Another is to have the computer do this. We already have a unit test that exhaustively runs scenes. So I set goods to 0 in this test, and found six other problem scenes.

So human QA gives the best results, but automation can give decent testing over the entire game, and it’s easier to set up certain conditions (usually a clan doesn’t stay at 0 goods long, since crafters and traders are continually making more).

Logo Development

When I talked to a marketing consultant, she advised that I needed a logo as soon as possible. For a variety of reasons, I didn’t follow up on that for over a year.

Last month I met with Pixel Parlor, a local design studio. I showed some of the art from the game and discussed my overall goals (e.g. it’s unlikely that we’ll have a physical box, which drove the King of Dragon Pass logo). In the meeting they asked me two questions I didn’t have an answer for: what were some logos I liked? And what were competitive games?

It turned out that was an interesting search. There are an awful lot of clichéd logos for fantasy computer games! So I broadened my search to include paper & dice RPGs and board games. For digital games, I thought the Monkey Island and Legend of Zelda series worked well. I liked the current Dungeons & Dragons logo, with the draconic ampersand (though it doesn’t work as well as D&D, since the three glyphs smudge together without enough contrast). The Fate logo also stood out. And the Scythe boardgame had a good logo.

As for competitive games, since Six Ages will be similar to King of Dragon Pass, there’s really nothing else like it. I suspect it will appeal to people who also like Sunless Sea, 80 Days, Sorcery, Banner Saga, Out There, and Reigns. But I also wouldn’t say they’re competition.

Pixel Parlor presented six design approaches. Here’s a representative subset:



I ran the designs by the Six Ages team and Chaosium (licensor of the setting). There was no clear consensus, so I asked Pixel Parlor to iterate on the two favorites. Here’s a couple examples from round 2:

Again I asked what the team thought. Again there wasn’t a definite favorite. I zoomed out to see all the logos at the same time. When they were small, it seemed like the carved style font was the most recognizable at small sizes. Which would be important in say a Steam listing.

I didn’t really like the E that looked like a greek Σ, however. So I asked for another set of variations. Again there wasn’t a clear winner, but I finally picked the one that wasn’t likely to be confused for a game about ancient Greece.

Hopefully this will prove distinctive and help suggest what the game is about (one of the artists noted that the lettering reminded him of the Gloranthan runes). At any rate, it’s nice seeing in the game.

Update: I just noticed that Pixel Parlor also wrote about this.

QA Makes the Game Too

The official role of QA (Quality Assurance) in software projects is to assure quality — that is, the software works as designed, and the design is reasonable. They find bugs.

But in a game, they do more. QA plays the game more than anyone, and has the best sense of how it works. Is it fun? Is it too hard or too easy? Does the UI work? What’s missing?

In King of Dragon Pass, the “heroic combat” concept came about because Rob Heinsoo felt something was lacking. (He ended up writing most of these scenes, too.)

I just finished implementing a suggestion from Liana Kerr:

I feel like there’s not a lot of connection between your opening questionnaire and your clan management. I have no emotional connection to the fact that we know the secrets of [redacted], because it’s never referenced again.

Well, it now is. And while a few questions don’t get an explicit mention later, I just made sure that every answer from two questions shows up in at least one scene. (The others are at least mentioned implicitly, like your ancestral enemy, or give bonuses in scenes.)

Earlier, she suggested

Raid adviceAdvice about raiding-related promises currently shows up in the War screen, but if you go to the Raid screen, it doesn’t. As a player I’d be more likely to expect to see it in the Raid screen and would entirely miss it in the War screen.

and

One problem I’ve always had with KoDP is that someone dies and I immediately forget who they were — that is, I just see the name and I don’t necessarily connect it with the face that I’ve been looking at for several years. It may be a little different with Six Ages, since the UI is a little different with the ring members’ names underneath their pictures … Two suggestions: …

and so on. More good ideas that got implemented.

For that matter, it’s not just QA that can influence the game. Much of the current combat feedback is based on a suggestion by Jan Pospíšil.

Not every team suggestion ends up in the game. Some are still on the backlog of possible tasks. But more input makes for a higher quality game.

No Kicking While Down

Back in May, I wrote

By the way, the @help/@hurt idea is not implemented at the moment. I’m not sure if it will be, but the flexible tagging system makes it easy to add at any time.

This was indeed easy to add, and it was in fact handled mostly with script tags.

furrows inundatedThe basic idea behind these tags is that we want to avoid death spirals. If you lose a lot of cattle due to disease, the game won’t feel as fun if you then have a large herd mysteriously disappear. You’ll end up in a hole you won’t be able to dig out of. The occasional flood is fine, but if it happens when you are short of food, it’s just kicking you when you’re down.

Of course, mysterious disappearances and floods need to occur, so they can happen more often when you are able to recover. (This may still set back your plans for cattle trading or gifting, of course.)

One issue with implementing this adaptive difficulty is figuring out what constitutes a bad or good situation. The game takes a number of factors into account (herds, wealth, military, and even issues like curses or magical bounties). And scenes have to be tagged. Some were designed to be helpful or harmful, but many are more of a grey area.

It’s worth noting that we don’t actually force or prevent anything, just alter the odds for picking scenes randomly. You can think of this process loosely as “pick a card, any card” each season, where cards are returned to the deck after several years pass. If times are bad, we essentially put multiple copies of the favorable scenes into the deck, and replace and reshuffle if a disaster is pulled.

As in King of Dragon Pass, we also do something similar for the yearly omens. Maybe an ancient economy experiences crop failure about once very seven harvests, but two in a row seems like a bit much to hit the player with. The goal is to give them challenges, not an accurate simulation of widespread famine.

I added this feature only recently. It required going through all the scenes and determining which would be reasonable to use to help the player, or to make less common in bad times, and adding the right tag. The determination of good and bad times was already used to give advice, and needed only a little tweaking for the new use.

Since this is only just in the game, it hasn’t been tuned. So I’m also tracking the values in the metrics we capture.

Hopefully all this will keep the game challenging but not too frustrating.