Back when I had run a Kickstarter to help fund the music for Betrayed Alliance, we also had a stretch goal to revamp and update the music and visuals of Betrayed Alliance Book 1.
What’s been worked on recently
Thanks to the amazing productivity of Karl Dupere-Richer, over half of the background screens have now received a visual update (upgrade!). In fact, his productivity has been so good, I decided to take a month or so off of working on Book 2 just to focus my attention to the update of Book 1. That’s been my focus for the last half of August and most of September.
Reprogramming the rooms to work with the new visual information, streamlining the code, and adding features (like the autosave I’m using for Book 2). I’m hoping to fix that pesky “out of heap space” bug that crashes 10% or so of runs too.
While the Book 1 update is not by any means complete, I’ve worked hard enough to make the programming for the new version playable to the end.
And this is where you come in!
If you’d like to have access to the update of Book 1 as it’s in development, I’m making that available to all KS backers and all “Early Access” Patrons on Patreon. I’ve also put together a Google Doc you can edit to track any bugs, parser commands that you think should work, or any general ideas or thoughts you have about a particular room. Obviously there’s no obligation to do any of that, but if you’re interested, I’d love your help to make it the best experience possible.
So that’s been it for the last month and a half or so. Book 1’s update is coming along very nicely. Beautiful new artwork and a revamp in the coding, and maybe even a few extra features!
Hello everyone! While summer goes until later September, my “summer break” is at its end. I’m teaching a new course this year, so I’ve been spending a lot of time preparing the course materials for that. I’ve also been at work on Betrayed Alliance!
Moving towards the end of the year I’m trying to get the first part of the game up and running – all assets, coding, and puzzles.
It’s getting there, but over the summer I ran into a few programming hiccups. Being a self-taught amateur programmer, it took me a bit of time (and a lot of help) to get things sorted, and fortunately they are now all solved:
I added a “count” property for some inventory items that you can have multiples of. Sounds easy enough and it technically was. The problem came up when displaying the information about the item. I would usually draw that from a text resource using a number variable, which saves memory. But I cannot do that when the description has a variable in it, so I had to sort out how to print some and not others from text resources, but it’s all now working as it should.
The death counter in the game is a unique challenge because restoring in this program restores everything to the state “as it was” and I could change all the variables in the world, but the restore would reset them. So I have to write those to an external file. That was a challenge enough as I’ve never done that before, but the problem I ran into was that everything was breaking and I wasn’t sure where the crazy numbers were coming from. After many wasted hours and some troubleshooting with more astute coders, I realized that I was a victim of my own bad coding practices. Because I was too casual with naming a variable, I ended up using the same variable for 2 different purposes, which was why the numbers were getting bizarre. The death tracker is now working as it should.
At some point I also experienced that my “teleport” script wasn’t working correctly anymore. I use this script to change between the two main characters when they are in different rooms. I use this script to “remember” the room locations, x and y coordinates, and proper transferal of items so that they each have their own inventory, etc. The problem was the x and y coordinates weren’t working. Hours and hours I spent trying to track down the cause. At some point I realized that when the player was playing the ”male” character, it never changed that variable, so their x and y positions were never properly being updated. But, I’m happy to say this is now up and running as it should too.
Looking at inventory items by typing “look” item. Sounds easy, but I had one helluva time getting this to work without adding a hefty amount of code (which I’m really not allowed to do with the memory limitations I’m working under). But I did solve it for most items. I am still troubleshooting the issue of having two “keys” and when you say “look at key” It’s not clear which one is to be shown. So I might take the “easy” way out and remake one of the keys into a different kind of object that will essentially do the same thing, but by a different name.
I also introduced “right-click-search” in addition to “right-click-look.” This feature is toggleable in the settings, but will allow the player to “search” a thing if they are standing close to it just by clicking on it. For some people that will make things “too easy,” which is why I made it so people could turn it off. But that is another feature I’ve been working on.
I’m feeling quite good now that all of these technical issues are resolved, which lets me focus more on the implementation of room-specific coding and puzzle implementation.
What Else Have I Been Up To?
There are about 400 lines of written text now in the game, but a lot more is needed. These will be responses to parser commands as well as “right-click-looking”
More animations are making their way into the game logic
Puzzles in the opening area are now generally up-and-running, but needing polishing and troubleshooting.
The final big accomplishment I’d like to boast is the story for the game is complete. I wanted to get that completely sorted to remove any vagueness left that would impact important decisions about puzzles, areas, and maps.
Once the story was nailed down, I could also finalize the map. I’m not ready to show that off yet mostly because it’s still fairly rough. But the concept for that is now complete.
Here’s my best estimates of completion:
Backgrounds: 70% complete
Animations: 30% complete
Programming: 85% complete in terms of systems, 10% complete individual rooms
Story: 100% concept/structure, 50% details
Puzzles: 10% implemented
So, there’s a lot of work ahead of me, clearly. I’ll keep plodding ahead, one day at a time. And I really hope to have something in the way of a playable demo by year’s end…but man I am bad at forecasting that kind of thing, and should probably just stop.
Betrayed Alliance 1 Updated Visuals:
Karl Dupere-Richer has been working on artwork for Amazing Fix for a few months, but has found some time recently to help with some backgrounds for Betrayed Alliance Book 1:
As these assets come in, I work with them to make sure their priority and control colors are working properly. Some of them will require a programming overhaul as well since there will be new things to “look” at and sometimes bigger changes (like ascending and descending the stairs in the tavern which no longer requires a ladder)
Thanks for all the support! Hope to hear from your soon!
I’ve been spending basically all of my time working on programming, fixing up some systems, and animations and props for the backgrounds.
What systems am I working on?
Cut scene dialog – if you’ve even accidentally clicked a past a box in a Sierra game, you know the frustration of knowing it’s gone for good and you might have missed vital information. I’ve put together a system that allows your to go forward and backward through the dialog if you miss anything.
Character Switching – Book 2 has two main characters, so the ability to switch between them in important. It’s not completely finished yet, but the basic structure is up and running just fine allowing for each character to hold their own items and retain their positions in their rooms.
Death Log – This one is actually proving to be quite tricky, but I think I’ve mostly got a handle on it. The difficultly comes with how Sierra games save and restore. When you restore, everything is set back to the previous save “exactly as it was,” so having the game “remember” what caused the death you are restoring from was an interesting challenge.
I ended up with the idea of writing variables related deaths to an external file, then reading those variables back into the game when the player restores. Sounds easy enough, but there’s more to it I won’t get into now. The good news is, that the system now works generally as it should and is incorporated into the menubar for easy access (many thanks to the help of more skilled programmers guiding me at the SCI Programming Community forums).
The basic structure of the new battle system is now in place and the first (training) battle is complete. Future enemies will build on the foundation that’s already been established, but having the skeleton constructed now will make all the rest from here much easier to flesh out.
Props and animations
A big focus for me right now is getting things playable. A lot of backgrounds and animation work has been done and now it’s time to get some of them up and running!
Book 1 Update
Most of the work on the Book 1 Update has been done by Karl Dupéré-Richer at this point, although I have done been updating it bit by bit as his new artwork comes in and have started a log of fixes and bugs to fix for the updated release.
That being said, Karl has shifted his focus from this project to another for the time being. He has put together a few sketches for updates of a few interiors in the game and they look gorgeous already!
Besides this, there is nothing new to share concerning the Book 1 update, as my main focus is the completion of Book 2.
The Kickstarter has been successfully funded (and actually was so one the first day, which was a huge relief to my nerves!)
We’ve also funded our one (and only) stretch goal – to update some of the artwork of Book 1 and overhaul the music to give it the same treatment as Book 2 will have. This goal will be completed only after work on Book 2 has ended, as I didn’t want the stretch goal to impede the original Kickstarter project.
Summer break has come to an end and it’s back to school for both myself and my kids!
This time of year always comes with a change in routine and that always gets me anxious about whether there will be time to do things. But there always is, so I’m going to try not to worry.
Onto the update!
Current total of Backgrounds that are “basically finished” 68 of an estimated 100. Originally the plan was to have around 56 or so, the same as Book 1, but that estimate was clearly way off, most likely due to the fact that there are two playable characters, and each must have a reasonably sized chunk of forest to explore.
You might notice a couple things in some of the screenshots as well – creatures! Actual things! This last few months a friend of mine from Twitter and Discord volunteered his talent with some creatures designs. His name? Karl Dupéré-Richer. He’s also the sole artist on Amazing Fix, a hidden object game.
Here’s a few of his designs for Betrayed Alliance:
These lovely monstrosities will feature as battle opponents, environmental barriers, and perhaps even helpers on your quest. Karl is an extremely talented guy and a great follow on Twitter, as you can see from these images and I’m indebted to him for his cooperation.
Things come alive when you start integrating new characters, but even more so when animations get put in and the characters can actually do things, besides getting the “You can’t do that.” response from the text parser.
Also, have I not mentioned that I put together a proper game image for Betrayed Alliance Book 2?
I haven’t talked about it much, if at all. I’ve written a little bit of music for the game, and I scored most of Book 1, with the addition of free-to-use music to supplement what I had. While I have some talent for music, I’m not feeling at peace with what I’m producing for Book 2. If the Kickstarter I have planned for November goes well, I will be hiring someone to compose for the game using the MT-32, something I know nothing about.
At this time, there’s not much more to share, but it’s on the horizon.
The game is still mostly a pile of artwork assets, scattered story notes, and puzzle scribbles, but with each new background, animation, and implementation of code, it is moving closer from project phase to game. There’s still a TON to do before it makes that shift, but the feel of it has already shifted.
Here are the past development updates if you want to see more:
Action elements in the adventure genre tend to be the exception not the rule in modern adventure games, but the early Sierra titles, especially the hybrid Adventure/RPG series Quest for Glory and the space adventure series Space Quest used them frequently.
Also, I like them!
There’s no hiding that my Adventure saga Betrayed Alliance is heavily influenced by Quest for Glory (particularly the EGA ones) series and as such I’d always planned on having a battle system.
Today I want to look at the combat system in Quest for Glory 1 and determine what it did well and what, if anything, can be improved on.
Difficulty feels challenging, but not insurmountable
Except for the Fighter class, battling was a somewhat optional gameplay element
HUD is unobtrusive and easy to read
Combat is simple
Enemy attacks have almost no telegraphing making blocking/dodging nearly useless
Can be hard to tell why attacks aren’t landing.
From the responses I think we see that the combat was generally liked, but that they just ended up spamming the attack button as dodging/blocking was not really responsive or intuitive. The stats upgraded fast enough that the “attack-all-the-time” strategy worked and while there were perhaps better examples of combat, this one was good enough for the game it was in.
Since Quest for Glory is a stats based game, this design may be intended. The game doesn’t require any real twitch-type skill, but rather the stats do the heavy lifting, which at least one of my responders remarked as a positive quality as they don’t generally like arcade-style combat. That said, having stats for “dodge” and “parry” make it seem like these skills were designed for use, but from the responses I got most people end up ignoring them.
Takeaway for Betrayed Alliance
Combat in Betrayed Alliance Book 2 will emphasize a strategic block / attack rhythm where the player must read the opponent’s intentions visually. While there will be a few stats that can be upgraded, the game will not reward a reckless “attack at all costs” strategy. As mentioned by some commenters, better signposting of attacks as well as more frames of animation could be helpful.
“But I don’t like combat”
That said, for the many people who dislike arcade style aspects in adventure games, I am including a way to overcome enemies without always entering the combat arena. I want to give the player the freedom to dispose of their enemy obstacles in different ways.
This is not a concession by any means, but an intended gameplay element. There are two playable characters in book 2 and they have different gameplay styles. In Quest for Glory terms, one is the fighter class and the other is more like the thief. I’m building the game-world to allow the player to influence which of the two will be more likely to encounter the various enemies of the game (and how to dispatch them).
Combat in Betrayed Alliance Book 1
It’s a mess! Visually and game-design-wise. Just a mess.
The rhythm of battle in Book 1 is not bad. Enemies telegraph attacks (but also fake-outs) with enough time to respond. There is a cool down period on both blocking and attacking which forces the player to be more strategic. Successful blocking not only rewards the player with not getting hit, but also gives a chance at a counterattack which doesn’t affect the attack cooldown (and is always a guaranteed hit).
In this way the design of combat in Book 1 is pretty good and has a bit more to it that Quest for Glory 1’s combat, but there are a ton of problems with it too:
The HUD is atrocious and confusing
It’s quite hard for the player to heal after battle, discouraging it completely
There’s *almost* no reason to battle in the game at all
The ability to target 3 different areas was underdeveloped and clunky
From a design point-of-view combat in Book 1 is competent in an of itself, but as a mechanic in the overall game itself, it’s completely underdeveloped and useless. This is mainly due to the strange development of the game where the first 1/3 of the game was released as “Book 1,” a division that was not originally intended. The area in which combat was to feature more prominently is not available in Book 1 as it is the sole environment for Book 2. But due to this separation, combat in Book 1 rightly feels unimportant, because it is!
Combat in Book 2
The Combat system is being updated for Book 2, as combat will feature more prominantly. Both the aesthetic and mechanics of combat will change.
The targeting system is being scrapped as it’s too clunky and unintuitive.
The emphasis on blocking will still be operative as it was in Book 1, along with a cooldown counter for both attacking and blocking to avoid spamming either attacking or blocking.
With only two major actions (attacking and blocking) buttons could be freed up for different actions. I’m currently looking at using one for a short-term block that will also render the opponent more vulnerable, similar to the “perfect guard” in Zelda: Breath of the Wild. Just as in that game, this parry offers a reward at the cost of taking a risk: miss the parry and get hit unguarded, but if you parry it just right right, you get an open window for attack (and probably a 100% hit rate and likely a higher critical hit multiplier).
I’m also interested in having both a sword swing and a sword stab, each having greater applicability in different circumstances. We’ll have to see how these develop as I test things out.
What do you think can be done to make combat more enjoyable/challenging/fun?
I heaped myself a bunch of praise when I looked at the Overworld Structure for BA: Book 1. As much as I enjoy patting my own back, today I’ll be moving my hand to my forehead as we look at some puzzle choices.
The Squirrel Puzzle
This puzzle has three steps:
1. Activate the puzzle by giving the squirrel the acorn
2. Say “copy cat” to the squirrel and it will position itself to mirror your actions
3. Make the correct sequence of steps.
As a puzzle, it’s fine. Not earth-shatteringly good, not rip-out-your-hair-bad. The signposting to say “copy cat” is clear once you’ve heard the dialog from the soldiers watching the Whispering Caverns. The signposting for the correct sequence of steps is carved into the puzzle structure itself, which is also told to the player if they happen to “look at” the puzzle board itself.
What’s wrong with it?
The design feels arbitrary. Simply put, why is it there, other than just another obstacle for the player? And what reason is there for a squirrel?
It breaks the immersion when it’s just some random puzzle.
What’s worse is that it was designed with a story purpose, but very little made it into the game.
The puzzle leads to a hidden grove, meant to be a “special place” for the main villain (Gyre) and his wife, who had died before the events of the game. The spirit of the wife “haunts” the place playing music, which has led to the spread of the legend of the “Muse of the Mountain.”
The puzzle needing two participants was originally set up for Gyre and his wife to gain access to their secluded sanctuary. With her passing, Gyre had trained an animal to replicate the pattern so he could still gain access. I never devised a way to get this information into the game, sadly. About all that made it into the game were the rumors about the “Muse of the Mountain” which you find in an optional library book.
Why do the tiles make sounds?
From its inception it was designed to be a music-puzzle, where the player (along with the squirrel) would repeat the four chords of a song that could be heard playing if one listened near the entrance.
The woman/spirit the player finds is seen to play music and sings all of her dialog. The lore is that people can hear her singing, but Gyre cannot due to his heart being clouded with thoughts of revenge.
So what happened? I hadn’t considered the limitations of sound in SCI, particularly the ability to only play back one sound at a time. The idea was each block played a tone, but when the player and squirrel would step on two different blocks, it would play two sounds making a small chord. That didn’t work at all because it couldn’t!
A concession was made to add arrows onto the puzzle board itself and remove any correspondence to the notes and the solution. The puzzle became more of a dexterity challenge than a music puzzle in the end.
I have regrets…
While the puzzle is generally fine in a vacuum, I do regret how I poorly I translated the puzzle from design to execution. I feel it lost almost all of its story meaning, and most of its original puzzle design as well.
It wasn’t until about the last month or two before release I had (for other reasons) decided to use “SCI Audio” which would open a parallel program that plays music separately from the game program. This program did allow for multiple tones at once, but at that point, the puzzle was already in place and the release was coming too soon to go back and change things.
Yes, I have regrets, but this puzzle still has some things going for it.
It adheres to the “find the lock before the key” rule, while also allowing you to play around a bit with it (if you give the Squirrel the acorn).
While the notes no longer matter, it is generally fun to play with them.
The player will typically go through a series of trial and error efforts like “pressing down all the tiles” before leaving the puzzle or solving it. It’s generally good if the puzzle’s not so easy the player gets it straight away.
Who cares what I think?
It’s your opinion that matters, not mine. I just made the puzzle, you got to play it. So what are your impressions?