Weekly Content Blog #6: Tyler’s Tunes – The Compositional Process (Curtis’ Theme)

Hi there!

Tyler (Mire) here! Today’s post will discuss the process I used to compose music for this project. I will specifically focus on the character theme for Curtis, who is a main protagonist in “Shadows of Adam”. I will show how I went from email threads with Luke (our writer/level designer), to sheet music sketches, to Finale and finally to Logic to sample and mix all the instruments. Well, let’s begin shall we?

In the past when I’ve composed location or general purpose (battle, inn, victory) music I can go off what I already know and/or use tropes that help establish those areas. When Luke and I decided it might be good to explore some character themes I knew I would need to pick his brain on how he saw the character and how the music should illuminate those qualities. Here are a few snippets of our emails

Email 1

Email 2

(Note 1: I’ve censored anything that could spoil the plot)
(Note 2: This was back when Kellan was named Josel. A fun tidbit that I’m sure Josh can talk about as he explains the progression of this project.)
(Note 3: Luke references lines of the scripts. This gives me context on where this theme will be used.)

Now that I had some ideas from Luke I could begin sketching some ideas. Generally I like to start a new piece by listening to music that will have the same spirit as the composition I’m about to write. In this case Luke shared with me several pieces that had more of a cinematic quality – a huge point of departure from the usual music I had been writing for this project. We discussed using this piece in specific scenes, so it wouldn’t necessarily need to loop. This was exciting to me, because it meant I could give the piece a more dynamic arch. The interesting result of having to write music that needs to loop and potentially repeat hundreds of times on the same map is that the dynamic arch tends to remain fairly flat in order to have evenness.

After doing a lot of listening I went to the piano and started to work on some preliminary ideas. In this stage I generally write down all the ideas I have and worry about editing later.

Sketch #1
As you see, this is an extremely rough sketch. I came up with some basic motifs and had a few suggested chord harmonies. (Also of note is the other rough sketches above Curtis’ Theme. As of today, I’ve used every page of this sketch book for misc. compositions! But I digress.) I then decided to make a second pass after spending some more time on it.

Sketch #2
Sketch 2

My second pass was a lot more fleshed out. I had a better idea of the form and arch of the piece. I even wrote a few basic orchestration notes that I’d integrate later. After this step, I’ll generally play through it more on the piano and start trying to imagine the instrumentation I would like to use. I knew that I wanted to use a large string section to give the piece weight and drama. I also imagined I could add some misc. orchestral instruments such as trumpets, trombones, french horns, crash cymbal and timpani to give it more strength and character. I then decided to add a piano as well, in case I saw the need to use it. I ended up using it for the very last bar. Now that I had this it was off to start writing the parts in Finale!

Finale is a professional music software used to compose music and create sheet music for live musicians. This is an unusual choice to use for a video game soundtrack which will be sampled and mixed in a DAW (digital audio workstation), but considering most of the music I do is for real instruments I have come to prefer using it. Most digital composers will go straight from their midi keyboards and record/program into their DAWs but I’ve always enjoyed seeing the parts on a score. As I began taking the sketch into Finale I tweak things I don’t like and make edits. The great benefit to Finale is it can now play all the parts at the same time with a decent midi representation. This gets me closer to hearing the final product then when I’m just playing on the piano.

Score 1
Score 1
This shot shows off some the string counter-point and orchestration. Seeing it on paper helps me since I’m such a visual person.

Score 2
Score 2
You can see some of the brass in this shot. I used each track as a section; the trumpets are in two part and the trombones are in three part harmony. Also at the bottom you can see the timpani and crash cymbal. They aren’t doing much, but their presence helps give some moments a bit more ‘umph’.

You may notice that I have very little in the way of dynamics in this piece. That’s because I will add that later as midi data in Logic. Once I was happy with the composition itself, I exported the score as a midi (with all instruments on their own tracks) and imported it into Logic (my DAW).

Now it’s time to set up our instruments in Logic. Knowing that I’d need a full string section I divided my string ensemble into 4 midi tracks:

-Violins (Melodic)
-Viola/Cello (Melodic)
-Viola/Cello (Sustained)
-Low Strings (Sustained)

Dealing with string patches, you must account for several different types of samples. Some are made for melodic and articulated passages, while others are best served for sustained passages. After setting all my instruments in the template I then begin mixing the piece. This involves using the volume fader and automation to set levels (dynamics), EQ, compression, reverb, and panning instruments so they all have their sonic space. For string panning I imagined that I was looking at a symphony orchestra from the audiences’ perspective. Where would they sit? The violins are usually to the listeners’ left while the violas and celli are to the right. Despite the fact that the basses usually sit to the right of the listener, I generally prefer to pan bass instruments dead center. I then decide where I want the instrument to sit in the mix as Finale sends the data with all the parts at equal volume. Once I comb through that, I then find spots where there will be louder and softer moments. Near the end there is a dramatic crescendo to a big chord, I knew I would need to automate the parts to have them get louder. The last part is adding EQ to highlight different frequencies of the instruments, compression, and reverb to give it a more cohesive sound.

The instrument template, set up with my samples:
Instrument Setup

Panning Knobs – these knobs pan the instrument to different sides of the speaker from left to right:

Automation lines – the lines represent how much DB the instrument is producing at that moment in the piece. The higher the line the louder the instrument is:

Once I was happy with the mix, instrument samples, panning, dynamics, etc… I export the file as an mp3 as we are left with our final product!

Here is the PDF of the Finale score for those interested:


I hope you enjoyed this. Stay tuned for the next post!


Weekly Content Blog #5: Budgeting the Art Costs of an RPG Pt. 1

Hey everybody, I’m Tim Wendorf, the lead artist and art director for Shadows of Adam. I first joined the project by happenstance when Tyler Mire (composer for Shadows of Adam) and I were both looking for an obscure, unpublished project I had made. Miraculously, we both posted in some forums we hadn’t frequented in nearly a decade on the same day and at close to the same time. After catching up with him, I learned that he was working on an indie RPG. The scale and scope of the project was really small, and though I was busy at the time, I committed to helping out with some art assets to get the project going. In this series I will document my involvement in the project, and explain how the aesthetics have scaled from a no-budget game without a name to the full-fledged AAA indie title it has become.

The Beginning

Originally my involvement in the project was meant to be a one time deal where I’d provide a few tile sets, establish a style, and maybe create a few other assets throughout the project’s life. The project did not have an experienced artist and had no funds to hire one. I had to create a look and feel that could easily be replicated by an amateur artist. RPGs require an ENOURMOUS amount of artwork, and if you’re not thinking about that from the get-go, it is very easy to find that your project goals have become either unattainable or unsustainable. This is true in all costs of a project, but it is especially true when it comes to the art costs of an RPG. Below is a before and after shot from my initial involvement in the project. The goal was to reasonably improve the art while still maintaining the overall aesthetic of the original concept. In all it only took me a few hours to get to this spot.

before/after world map

First Update to the World Map and Character Sprites

Courting of the Courtyard

In addition to the world map, I wanted to help establish the look of the locations and battle system in the game. Enter the courtyard; which served both as an intro to the game and the first dungeon. The game was so early in development at this point that there really wasn’t much art for me to go off of. I created the courtyard tile set with the same sort of mindfulness I went into the world map with. Simplicity and consistency were top priorities. Below are shots of the courtyard tile set and battle system in action. Again, it only took me a few hours to reach the state of each screen. Note that the battle background makes use of the same tile set. Dedicating time to unique battle backgrounds was simply not in the budget at this time.

Boss Courtyard


While working on the courtyard I became a lot more involved in the game design side of the project. I helped figure out dungeon and battle system mechanics, did the mapping, and worked on finessing what story was there. By the time I finished my work on the courtyard I was fully involved in the project, and it looked like I would be for the foreseeable future.

Adam and Beyond

Upon being fully committed to the project, I still had some reservations regarding that commitment. For one, our art budget strictly correlated to the amount of hours I was willing to put into the project. For two, if I was going to be involved to this extent,  I wanted to produce a product that I could take pride in when all was said and done. Adam is the first town in the game, and where you end up directly after the intro. My goals in creating Adam were to maintain the established style of the world map and courtyard while building a more professional standard for any future maps. I reworked the palette a bit, took more care in sprite work, and chose assets that would lend themselves well to future areas. This is what I came up with.

Adam Misty Woods 3


The second shot is from a completely separate area called Misty Woods, but you can clearly see that it is using the same tile set while having a much different feel. I had spent maybe 20 art hours on the project at this point. Which includes some not pictured enemy sprites as well as a building interior tile set. We had a little under 40 minutes of game play at this junction. Our final product goal was a game that lasted 8-12 hours. At minimum, my commitment to this project looked like it would take at least 250 man hours to finish all of the necessary art assets. No small task considering I contract full-time and have maybe 5-10 hours to commit each week. On top of that, my new dedication to the project really inspired the rest of the team members, and they were consuming the content I generated as quick as it came. In order to keep the fervor of the project alive we sought to contract out some tile set work in order to free me up for other content creation.

Outsourcing comes with its own slew of problems, and my next update will outline some of those issues and explain how outsourcing shaped Shadows of Adam. If you made it this far, thanks for reading, and stay tuned for part 2!


Weekly Content Blog #4: Project Goals and Inspiration

Hi, Josh here. I’m the other programmer for Shadows of Adam. Rather than bore everyone with more technical details, I’m going to discuss some project goals and inspirations. I will also attempt to break the world record for “most occurrences of the word jRPG in a single article.”

The RPG, Today

Let’s face it, RPGs are complicated. Both from a development and player’s perspective, RPGs are very content intensive. Playing a modern RPG is now a major commitment, with recently released popular RPG titles easily clocking in at the 100+ hour range.

Even the once linear jRPG format is beginning to shift towards an open world structure, with breathtaking scenery and choice-driven interaction adding significant amounts of playtime to an already long narrative. If you have a summer to yourself, like I did when I played through the excellent Xenoblade Chronicles, you will be rewarded greatly by indulging yourself in these modern marvels of gaming.

But conversely, if you’re working full time, and suffering from a decreasing attention span, you’ll feel like digging into the latest Final Fantasy is almost a job in and of itself. Still, sometimes you want to scratch the itch for questing, storylines, and monster-bashing all the same, in spite of a schedule constraints. Enter the indie gaming scene…

Simple, Done Well

“Simple, done well” has been the project mantra from day one. Like many indie game developers, we want to distill the essence of what makes our favorite childhood games so fun, while cutting out the anachronistic and excessive parts. From a playability standpoint, we want to create a more compact jRPG that offers immediate storytelling, as well as engaging gameplay systems that require little in terms of a learning curve. In a later post, I’ll discuss gameplay influences and decisions in more detail. But rest assured, we are cutting the common RPG filler, such as level grinding, backtracking, confusing subplots, and general lack of direction.

Proud to be an RPG

Having been a part of the game development community for awhile now, it’s been obvious that the retro jRPG format may not be appealing to most people. As a result, there is a tendency for indie jRPG’s to downplay the fact they are indeed full-blown jRPGs in a couple of ways. First, RPG developers will advertise game features in terms of what jRPG-isms they didn’t include rather than what features they actually bring to the table, e.g. “NO RANDOM BATTLES”, “NO GRINDING”, etc. The second is arguably more common: the game itself will be a self-referential parody of the jRPG format, lampshading the abundance of tropes that come with playing any jRPG. The result can be banal, or it can be used to great effect with good writing. See: Cthulhu Saves the World for an example of how to pull off the humorous side.

For Shadows of Adam, we want to play it straight. Not quite “80’s power ballad straight”, but also not a 4th-wall breaking irony explosion either. Rather than make concessions to the general public and apologize for being a jRPG, we are flying our jRPG flag high: we’re serving up airships, a fantasy world, elemental McGuffins to collect, and some scenarios that any RPG fan will find familiar and enjoy at the same time. Put simply, we want to collect as many cool parts as possible from early 90s SNES-era RPGs, while conveniently discarding the parts that were a drag.

The jRPG format is strange in that the whole is oftentimes greater than the sum of its parts. Fans of the format will oftentimes put up with questionable design choices to satiate their need for character progression and an engaging story line.

Sleepy Port Towns ho!

Wrapping it Up

Shadows of Adam was started by a team of lifelong RPG players. We know what we want and what we don’t want from an RPG at this point, and our hope is that our experience will allow us to create a lean, quality retro jRPG. Developing this game has been a joy, and playing through it will be sure to evoke past memories. Nostalgia is a powerful thing, after all. But we want to use nostalgia as a springboard, not as the endpoint. Check back next time, where I will be discussing what mechanics the game will include, as well as some classic (and not-so-classic) RPGs have been influential in developing Shadows of Adam.

Weekly Content Blog #3: Battle System and Action Queues

First boss battle

Hello from the frozen wastelands of Canadia! My name is Tyler Deren, and I am one of two programmers working on the “Shadows of Adam” project. For the past few weeks I have been hard at work re-building our old ( and very rigid ) battle system from the ground up using an entirely different approach. In this article, I am going to discuss why we decided to re-build a core component of the game, and some of the technical details to make it all work.

Ye Olde

First, let me explain why the team decided to re-write a core component of the game. Typically, when you’re working on a game project (Any project really!) of any scope or scale, re-writing or going back and fixing old work is often times a poor decision, since at that point you are spinning your wheels and not moving forward and making any progress on the game itself. We have a lot of code in Shadows of Adam that is redundant and doesn’t make much sense, but we are not re-writing it because the time spent does not justify the reward. At the end of the day, we have to weigh the decision to re-write sections of old code with new code very carefully. Our wives / girlfriends and families have only so much patience after all! ;)

So, why did we decide to re-write the most critical part of our game when we are keeping old, and often hard to use code in place? Well, let’s show some code of the old battle system…

Here is our dispatchItem function in the old battle system. What this function does is when the player selects an item during the Input phase, it dispatches and executes the associated function. If you use a Potion, we call the Heal actor function. This is fine, however the way we were determining which item was being used was to use a giant if branch checking to see which item was active. You want to add special or hidden items later? Good luck.   You don’t have to be a programmer to understand how rigid this is and how difficult it is to work with. The entire battle system uses Spaghetti code like this and giant IF-ELSE branches to control all of our actions. Further, once an action is used a timer is set. We have multiple timers for different states the battle is in. When an animation is shown, a special animation timer is set and updated. So that means we have multiple timers we have to manage, set and update to control the battle flow. Incredibly difficult to work with, and if we decide to add a new item type to the mix, what should be a simple addition ends up taking a significant amount of time for a trivial feature.

To make matters worse, EVERYTHING in the old battle system used this rigid structure. Skills were a giant heap of IF-ELSE containing the skill code, for every skill in the game. Actions the same. We also have a system where players can find “Artifacts”, which have an interesting story behind them in the game lore, what these things do is they are hidden throughout the world and allow for significant customization of every player character and can greatly change how a battle plays out. How was this system built code-wise? Pretty much IF-ELSE. So why did we decide to re-write this, if it is not obvious? Battles are a significant part of a RPG. You want them to be flexible, dynamic and most of all fun. A rigid system where we are limiting ourselves as designers will only make the game less than what it could be in the long run. So what were the goals of the new system?

  • Flexible. The key point is flexibility. We want to bend the battle system however we want as designers. We don’t want to limit ourselves nor give the players a subpar experience.
  • Ease-of-use. Our old system was a pain to work with. If we want to add new things, it should be easy! Why make our lives complicated?
  • Modular. Maybe we’ll want to push updates or new features post-release. An easy way to do that is to use a modular, plug-n-play structure.

So how do we hit all of those goals?

The Action Queue

Our new and improved battle system uses a data-driven design with a core action queue. The gist of it is you feed data (Or ‘Actions’ to execute) to the system. It is basically a code-eating monster that devours all of the data you feed it and then outputs the result you want, after a configurable time delay (Or a one-time shot, for burrito night). Everything that happens in a battle event is controlled by the action queue. You want to animate a drawing element? Create an action. You want to use an item? Action. You want to attack an enemy? That’s right, use an action. The big advantage to this system is we have full control over how we want the code to flow. We still use a timer to control game-time flow in battle, but instead of having multiple timers for different states and phases, we instead wrap a single timer around our actionQueue so we can fire off an action in a configurable duration. We can now very easily create slow-down time effects, speed-up effects and what have you, or if we want to only fire an action once we simply tell our action Queue that our action has completed via a callback function call; this causes our action queue to update immediately and start the next action.

Flow Chart

A very rough flowchart can be viewed to the right. It is very simple and you should have no problem understanding it, even if my flowchart making abilities are substandard :D.

Further, every battle is broken down into “Phases” and “States“. A phase is a child of our battle state. Currently, we have ten different battle states. These are as follows:

  1. stateSetup. This sets-up our enemies into our battle viewport and displays any starting battle actions, such as show the enemy names at start.
  2. stateFirstStrike. After our setup we then proceed to our Surprised/First Strike phase. This displays UI feedback letting the player know WHY they are being attacked before doing any actions. Very important.
  3. stateNewRound. This is the main loop of our battle states. After every round we loop back to this state. This state applies status effect damages and provides UI feedback for it. Stuff like that
  4. stateInput. The state where the player will spend the most time in. This state allows the player to navigate the UI menus and queue up actions for their party members. This state is broken down into special phases
    1. phaseActionSelect. Our main action select. This phase creates actions and displays our Action select window
    2. phaseAllySelect. This phase allows our player to select an Ally to apply either buffs or healing spells
    3. phaseItemSelect. This phase draws our item window and handles input to select an item to use in battle
    4. phaseSkillSelect. This phase is the exact same as itemSelect, except it works for skills
    5. phaseTargetSelect. This phase allows our player to select an enemy to queue up an action.
  5. stateEnemyInput. This state performs all of our AI calculations. I’ll go over this in a future article, but we essentially use finite state machines as a module that are plugged into our enemies when we want to provide AI behaviour.
  6. stateAttack. This state performs all of the actions queued by the party and enemies, and handles special cases such as counter attacks
  7. stateVictory. The party has defeated all of the enemies! Or, has completed a special battle objective
  8. stateDefeat. You lost. Loser.
  9. stateRun. The party ran away from the fight
  10. stateSpecial. A special state used for dramatic boss deaths. Screen shake, particle effects galore, stuff like that. Fun.

From there, our states loop from 3 -> 4 -> 5 -> 6. In effect, our battle system is basically an array of actions. Instead of having a giant IF-ELSE branch, we simply add new actions to our action queue via some handy helper function calls and pass along the code we want to call.


You may have noticed some “X Manager” stuff in the flow chart. Remember how we want to build a modular system as one of our new battle system design goals? Our manager classes bind our action queue with our skills, artifact effects and item code. Instead of having IF-ELSE branches, every effect, skill or artifact is in it’s own .js file. If we want to add a new skill, all we do is create a new file in the skill folder and our Skill Manager will call it when that skill is used. This greatly helps with debugging and allows us to easily find what we want to change. No more navigating massive IF-ELSE branches! Every core system uses this model now, from our Event Handler class to our Artifact effects. In the past, our event handling was done using IF-ELSE branches, like everything else (Why? I don’t know), but it was only processed on the Field Map. What if we want to create sophisticated scenes in the battle? We’d have to copy over massive amounts of code from the FieldState to the BattleState. That’s bad and annoying. So instead all of our event action commands are in their own file and are loaded, unloaded and called by our associated Event Manager. So now all we do if we want to process events in different game states is to include our Event Handler class, and it does the rest.

In closing, our battle system re-write, although far from done or polished, was a much needed change. Going forward, it will allow us to design more interesting battle encounters for the player to experience and allows Josh and I to maintain our sanity when adding new features or capability.


Here are some GIFs to end the article. GIFs are always fun :D.
Tweens! Actions! STUFF

Have a great week,


Weekly Content Blog #2: Introduction to Level Design

Today I’m supposed to talk to you about designing levels. I’d get into the theory of it all, but I’m not really a theory guy. I’m a touch and feel guy. I live on my feral instincts, like that guy with the broken-down, silver Dodge mini-van under the bridge by the river, clutching a rusty hammer on dark nights for protection against the rabid world outside.

(insert sound of howling wolves here)


Yeah, I’ve made some bad decisions in my level-designing life.  Back in ’99 I built a level called South Wall for my first computer-based RPG, Crestfallen: Inception. That level had so much wide open space you could have landed a 747 in the main hall. What you really needed was an F-22 Raptor, or anything capable of Mach 2 (at altitude), because it took about a bazillion years to get anywhere on foot. Sure, I can laugh now as I look back. But am I really better off? Are my levels better off? Maybe all that’s really happened is that I’ve put my mind in a small, agoraphobic box. Level design is tricky like that. There’s a time and a place for just about everything.

But enough about the past. What about the future?!

Tangle 4

In my future posts, I plan to take you inside both my own mind and the Impact level editor. I want to show you what goes into making a Shadows of Adam level. You’ll be a mute little angel or devil sitting on my shoulder, watching the creative process/struggle from a spectacular vantage point.

It will be fun.


Weekly Content Blog #1: Tyler’s Tunes – Main Theme


This is Tyler (Mire) here. I handle all music related tasks involving our project “Shadows of Adam”. As the composer for the project, I try to use my craft of musical composition to help express the elements of the story and characters. A good musical score can help augment emotions or even subconsciously make the player feel a certain way.

The plan for these posts is to share with you various themes throughout the development of the game, showing off different stages of the process, from rough sketch, to sheet music, to the final product. In addition I hope to show  how it connects with  Tim’s  visuals and Luke’s script.

For my first post I will share the main theme I have composed for “Shadows of Adam”. Many other pieces will be based on similar melodic and harmonic elements. First, let’s listen:

Main Theme – “Destiny Awaits!”

Now that we’ve gotten a chance to listen, let’s delve into the musical analysis of this piece. (WARNING: Music Theory ahead!)

The main motif in this piece is stated in the opening two bars:

The staple of this melodic phrase is its use of a minor 7th interval in the first bar.

This interval is wide and open, giving it a flexibility to what sorts of tonalities it can be used in. For instance, the Main Theme is in A minor but the game’s Overworld Theme is in C Major. Both open with the same minor 7th interval (with some variation). The player will subconsciously connect the two phrases as the same melody, but the major and minor switch paints the melody with a different mood. What sorts of differences do you hear in the two different keys?

Overworld Theme – “Adventure Awaits”

The last part of the Main Theme I’d like to examine is the final 2 bars. I like to call this the “Adventure Tag”. A tag is a musical device that is used to delay the end of a phrase before returning back to the tonic chord. In the Main Theme, the last section modulates to C Major and ends with these two bars:

Observe how I used the chords Ab (bVI) – Bb (bVII) – Csus (Isus) – C (I):

This bVI – bVII – Isus – I chord sequence has an adventurous sound to my ear and I used it as a cohesive harmonic motif to connect several of the musical pieces. For instance, I use the “Adventure Tag” at the end of the Adam Village theme. Adam is the home village of our heroes Kellan and Asrael and even though it’s a soft, sleepy town nestled in the woods I used this tag at the end to hint at the coming adventure of our party. Listen below:

“Adam – Home Village”

As the player plays through the game, I hope they can pick up (subconsciously) these melodic and harmonic motifs and allow them to help better tell the story.

Musically yours,