Something Classic Games

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

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,

Tyler