Weekly Content Blog #37: Every New Beginning Comes From Some Other Beginning’s End

Sometimes as a member of a team you make compromises. And sometimes you and everyone else on the team later comes to regret it.

In late 2013, when I was creating a complete script for Shadows of Adam, the very first dungeon of the game was already mostly finished, cutscenes and all. My script was a significant departure from the original ideas, but no one really wanted to make major changes to the first dungeon, so I did my best to meld the new ideas into the context of that dungeon and the existing scenes.

The result was not great. In fact, I had the sinking feeling that what we had was borderline terrible, and overtime this feeling became stronger and stronger.

Other members of the team felt it too. The beginning of the game just didn’t work! The team began to discuss small changes that might help, but I was now convinced that a full face-lift was required.

Finally, I fired off this e-mail:

Hey Tyler, I read through your ideas, and I do agree that some mention of the [REDACTED] at the beginning might be warranted. 

However, as I’ve thought more about the intro, I feel like we should take it a lot farther.  Honestly, I think we should seriously consider doing some major re-work on it.  I’m probably super biased in this, but I would sacrifice [REDACTED] to have a better beginning.  It’s a hugely important part and we really need to impress and get people on board. 
In the current opening, all the characters and their purposes are so weakly defined and the [REDACTED] is just there…  It’s too chaotic and confusing to be satisfying.  There is very little character development.  We don’t come to understand the relationships and motivations till afterwards.  So we are really hurting with the current opening. It should be a major launchpad from which we blast off, but it  feels like a mini-tramp.
I’d really like to better establish the characters and give the first dungeon much more intrigue.  Also, I’d like to establish the [REDACTED] as a force to be reckoned with.  Give it some umph!  Blast off!
Below I have sketched out what I believe would be a much stronger opening that would not require a massive overhaul of the rest of the story.

This led to the creation of a new beginning with a new dungeon: the Tangle. It’s a beginning the whole team is proud of and we can wait to show it off in the demo. For now, you can see a brief preview here.

Till next time.


Weekly Content Blog #34: Talon Character Teaser

Greetings! It’s time again for another character teaser card, this time for the fourth and final playable character: Talon. Talon is a bit of a know-it-all, but beneath his confident exterior is a character filled with jealousy. He acts as a Gambler in battle, which combines skillsets found in thief and ninja character classes in traditional RPGs.




Weekly Content Blog #33: What’s new?

Wow, hard to believe we’re already at Week 33! Initially, this Development Blog was to record all of the week-to-week changes as production continued, and note any new additions (Or subtractions) of the core content and features of the game as time went on. Instead, this development log evolved to be more than that. We delved into musical influences of past composers who influenced the sound of Shadows of Adam, we have a three-part series about budgeting the art costs of an RPG, we have an article taking a look at some of the retro flaws afflicting some classics, we have level design articles and we even have some boring technical articles. Looking through our post history, I noticed we don’t have many articles where we talk about what we actually worked on between posts, so I am dedicating this week “Development Log” towards a changelog of what changed since my last post on September 22, 2015, and quite a lot has changed!

New Menu Skin

The old item menu

The old item menu


We wanted the ability to change window skins (ala Final Fantasy window colors), and unfortunately the old menu skins were simply a single image texture that had text aligned to match the image. This doesn’t give us any flexibility at all, and makes it impossible to add any movement animations to individual windows since it’s all one big image! Well, that was all fixed! We introduced Scale9 image support and completely re-worked the UI so we can add multiple different window colors, and have it be an option should the player wish it. I think it looks nicer, and it’s easier to work with as well! Still some alignment issues to do, but nothing major :)

Area Text Enhancement


(Image is a GIF) You know in -some- classic RPGs when you enter a new area, a helpful box appears telling you the area name? We always had that simple feature in, but the area box had to be called using our scene system before it would appear. As such, it was only being used during certain puzzles. We improved this functionality so the area intro actually acts as an area intro, but only fires off once. You want to always be told which area you’re in, and don’t want to talk to the nearest town guard? I’m sure I can make an option for that.

Named (string) IDs instead of numerical IDs

I still find it hard to believe this ‘developer sanity’ feature wasn’t pushed more heavily by the team. Basically, we were using numerical IDs instead of named IDs for EVERYTHING. You want to add a treasure chest to a map? You have to go into the item data files, find the name of the item or piece of equipment you want to give the player, collect it’s ID and then attach that number to the chest object. Oh, what’s that you say? You can collect the item continuously and the chest never goes into it’s ‘Opened’ state? Wellll, for that you have to go into our ‘Treasure IDs’ worksheet on Google Sheets, assign a ‘treasure switch ID’ to your chest in the sheet (To prevent someone from using the same ID) and then assign that number to the chest. BOOM! Your treasure chest is now working! With a named ID, now you just reference the name of the equipment by it’s name, give it a opened state name and BOOM done. No more going back and forth spending coveted development time searching for the ID of the “Basic Armor”, or navigating development folders trying to find the treasure chest switch ID list. Now, it’s all automatic.

Why we never did this sooner? We’re stubborn here in SC land 😉

Quest Flow Engine


I can’t believe it took us this long to get this feature in. Our ‘de-facto’ way of handling quest flow for the game is by using boolean switches. Nothing wrong with that, right? Well, our switches (and variables) in the game suffered from the same problem mentioned above. It was all numeric numbers, and was not stored in a human readable way like an actual WORD. You meet a witch in the woods? She turns switch 113 to 1. If switch 113 is 1, then a new monster spawns and turns switch 127 to 1 and 114 to 0. These numbers mean nothing to me (And I’m one of the developers!) Now, with our named IDs, it is very easy to manage our quest flow. Our ‘Quest Flow Engine’ consists of two parts:

  • 1.) The controller
  • 2.) The trigger
  • The Controller is a special object that can be activated by any other game object. All it does is control the state of the game. If your quest flow looks like: ‘talk to Bob’ THEN ‘innkeeper lets you into the secret room’, then once the player talks to Bob, the ‘Bob’ game object tells the controller “Hey, the player talked to me! Set the “Talked_To_Bob” state to true!”
    The trigger is made up of two parts: The condition and the logic. A single trigger can have any number of conditions or logic associated with it. If the Controller has the power over the game state, the trigger has the power over the properties and states of each game object. So using the prior example, the trigger could be waiting for the “Talked_To_Bob” condition to be met, and once met, fires off some logic which updates the ‘Innkeeper’ NPC to allow the player entry into the back rooms.

    Joypad Support + Control key rebinding

    Joypad support was in for awhile, but we never really talked about it. Shadows of Adam supports any Gamepad that uses the XInput API. The standard gamepad using this API is the Xbox 360 controller. If you have an older gamepad that uses DirectInput instead of XInput, we don’t support it natively, but you -may- be able to use additional software to convert the DirectInput signals into XInput signals. Further, we’ve also added in key re-binding. This is a must-have feature in my opinion. There is no way every single player of your game will enjoy the default key bindings, so having the option to re-bind goes a long way!

    Skill Leveling

    Each character has seven core skills, with the exception of Asrael who has eight. We wanted to avoid the level-up mechanic found in classic jRPGs where a party member learns a more powerful version of an already learned skill (Fire 1, Fire 2, Fire 3, etc), so at the end of the game the skill list is populated with a large amount of identical skills of varying strength. Instead, we decided to use a character MP pool, with each skill taking a certain percentage of the characters available pool and a base percentage is recovered each round. Each skill becomes more powerful as a character gains higher attribute points, and the cost of casting a skill remains mostly fixed. I say ‘mostly’ because we wanted the player to be able to customize the builds as each hero becomes more powerful. So we took a page from Super Mario RPG. Every time a hero levels up, the player can choose a single level-up bonus. These bonuses can be a stat boost, a reduction in the cost to cast a skill, and once in a while; a Skill Levelup, which changes the functionality of a single skill to make it much more effective and useful. Every skill can be upgraded three times, but the final “Ultimate” version of the skill may require more than just an option select 😉

    That’s it for this week, I hope you enjoyed this post :). If you have any suggestions on what you would like to see us write about, let us know either in the comments below or on one of our social media accounts, and we’ll see what we can do 😀

    See you next week,