Browsed by
Category: General

Weekly Content Blog #33: What’s new?

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,


    Weekly Content Blog #31: U and I can make a good “UI”

    Weekly Content Blog #31: U and I can make a good “UI”

    Hi everyone!

    This is Tyler from Something Classic HQ, located in a bunker somewhere in the mountains of South America. This month has been exciting as we are finalizing our design choices on our new Battle UI. As the game’s composer, I have also seen myself evolve into a sort of “all purpose” guy for the team. I do minor map making, scene design, and lots of micro edits. This has led me to do some battle system testing and UI adjustment.

    The game’s battle system has gone through a lot of changes as the game’s scope evolved. Originally when it was a two person team, Josh whipped up a quick and easy turn based battle system. This system ran smoothly, worked well, but lacked a lot of options.

    First Battle Design

    Somewhere along the way we decided to update graphics and add more options to the battle system, such as counters and flashier attack animations.

    Battle 2

    Eventually after months of fierce debate, chairs thrown through windows, and decisive arm wrestling matches we decided to completely redo the battle system from the bottom up to allow more flexibility, smoother UI, and easier customization.

    Battle Current

    We also moved towards a % based AP system. This system sets each character with a finite pool of AP which does not change. Skills and Magic have fixed % costs, but the skills scale throughout the game. No Fire 1, Fire 2, Fire 3 – but rather a dynamic set of unique skills with morph and grow with your character. This opens up many possibilities for the player to customize how your characters grow. Possibilities we will share in a later post.

    In general though, a good UI design must balance:
    1. Functionality
    2. Ease of use
    3. Visual aesthetics

    We can all think of our favorite menus that do all of the above. Older retro rpg games are known for their clunky UIs. Final Fantasy 1, Pokemon and Earthbound are the most notable examples. The games that stand out to me as having exceptional UI design are Chrono Trigger, Final Fantasy 7, and Super Mario RPG. What do you guys think?

    I’ll leave with a great article written by Pat Holleman, who runs The Game Design Forum, an incredible resource for any potential game makers. This is his article discussing UI and Menu Designs.

    Thanks for reading this and stay tuned for next week where we will reveal our final character, Talon!

    Weekly Content Blog #23: Post-processing

    Weekly Content Blog #23: Post-processing

    So after going over your level design budget trying to figure out how those darn attractive tiles connect to each other, you finally figure it out and have a level. Congratulations! Your game is complete and now you can release and retire to a Nepalese Monk Monastery. Wait, what do you mean the level is bare and has none of that extra juice?


    You let out a loud groan of despair and shake your fist at the user who ruined your retirement plans. As you return to the lowly confines of your office, you plan how you’re going to make the level built by Luke the Wondrous the most amazing level yet seen in the game. You’re young, idealistic and invincible. What can you add that suits your greatness? Which type of effect can be found littered throughout every triple A game? That’s right, post-processing effects.


    Nothing can bring you down now, for you possess the power of post-processing effects! Now let’s see them say there is nothing to do! Now let’s see if they can find all the secret effects littered throughout the level to unlock the secret super badazz effect boss that can only be beaten with the power of love.

    Shadows of Adam is using two methods to handle post-processing effects; the first, and main method, is using WebGL to render advanced effects in real-time that require full image awareness. Our second, and fallback/OMGNOWEBGL, method is to use native canvas API capabilities to either fake the desired result through hackery, or imitate the effect exactly, but with a noticeable performance hit. Our planned minimum hardware specifications for release is a AMD E3-350 CPU with a AMD Radeon HD 6310 video card; This is pretty low-end hardware, and is primarily found in cheap notebooks or media/playback machines, so hopefully the vast majority of the players will not have any problem playing the game with all of the post-processing effects firing off at it’s highest quality setting.

    I initially had a lengthy article planned about how these effects work in our game, but this post is already a few hours behind schedule and I’ve gone and borked the entire game:

    and I may be using a tiny bit too much VRAM

    So I’ll leave a bunch of images at the bottom, along with a GIF, and use the time-tested excuse of “It’s a feature” and see myself out….




    Okay fine, I’ll fix it. Only because you, the reader, are awesome and deserve a product that works.

    Weekly Content Blog #16: The Role of the Composer

    Weekly Content Blog #16: The Role of the Composer

    Hi everyone!

    Today I want to talk generally about my role as composer in Something Classic, and how my role has evolved to take on other tasks. (Truth in reporting: because of my busy schedule I hadn’t the time to sit down and do another analysis of one of my tunes, but I hope to next time!)

    First a little background. I had been in cohorts with Josh on several past projects during our Rpgmaker days. When we reconnected October 1st 2013, I had just had my first rehearsal with the Americano band, The Mavericks (more on that later).  After some brief chatting we decided we wanted another go on a project. This time we were going to definitely finish it because Josh had the brilliant idea of making this an all 8bit game. He would do all the graphics (the low quality would make it easier to generate mass resources) and I would do chip tune compositions. I was so excited, that in the same night I sat down and churned out our Battle Theme.

    Time went on and with the addition of Tim, we got a nice graphical update. With that, came the transition from 8bit to 16bit.  This left me with a peculiar problem. I had already composed about 8 chip tunes pieces (Dradora, Battle, Victory, Adam, and more) and didn’t have the real technology (or tech chops) to advance the score to the level it needed to be. I was frustrated at the situation but decided it’d be best to redo everything I had already done and start writing future compositions with a more updated sound. The problem was I had no DAW (digital audio workstation) as my background as a composer came from writing for live musicians and my own band. Since I was doing pretty well with The Mavericks I decided to drop a good amount of money to get a Mac Book Pro and Logic Pro X. With these tools I was ready to explore this new adventure for myself.

    Right around this time we were starting to get some momentum with the addition of Tim (Luke would come in the next few months). I had just gotten on the road for a longer run of North America with The Mavericks. But now armed with my laptop, Logic Pro, a small midi keyboard, and my sketch pad and pencil I was able to compose on the road. I ended up writing about 95% of the score at that point. I remember finding pianos in hotel rooms, dressing rooms and back stage at venues. It was a very productive and creative period, as the environment was constantly changing around me. I recall writing the ZaknNik theme on the bus while driving through a rain storm and writing the Dojo Theme on a ferry ride in eastern Canada.

    At this point only Josh had access to our scene and map editor, which eventually became a bit of a bottleneck as he only had so much time. Eventually Tim decided to jump on map making, which was a good move on all accounts. He also started learning some of the code syntax. I was a bit resistant, since my role as composer was pretty established. However, after having written the majority of the music I was stuck with not much to do to aid our project. I reluctantly got the map and scene editor installed and committed to learning how to use them. This ended up being a great idea.  As of today I have created most of the scenes, something I really love to do. This speaks to the reality of working on larger scale projects with smaller teams. Of course you need some specialty to get good quality out of certain aspects, but having some cross pollination is important to keep the project moving. For instance, when the others are busy I can spend time creating alpha versions of new scenes, polishing and clarifying scenes we’ve already done and even small map fixes. Overall I’ve found this a fun job. As music can help tell the story, the same is true with crafting a well paced scene.

    This leads me to a next broader point about art creation: the need for both clarity and honesty. Both are extremely important in obtaining a satisfying project. This also ties into our game team’s over arching philosophy “Simple, done well.” Hopefully I can expand on this in a future post.

    Well I hope this article was interesting and not too self indulgent. Next time I will try and get back to my regular “Tyler’s Tunes” series. Thanks for reading!


    Weekly Content Blog #15: “Not Invented here”

    Weekly Content Blog #15: “Not Invented here”

    Particle effects play a huge role in modern video games. Not only do they look fabulous and really add that extra juice to a scene, they are trivial to build… at least on paper. The tricky part about a particle engine is optimizing the creation and destruction of the particle objects, in addition to making those particle objects render fast within your rendering pipeline. The requirements Tim had for a particle engine were pretty standard (Basically, everything the Starling game engine could do. See an example here: I am also going to try presenting this post mostly in images (And GIFs) to show the progress from the beginning to the final product with some short spiel, so beware! Lots of images and GIFs!

    step1 The first step was to flesh out our emitter and particle classes. It obviously doesn’t look like much, and chances are the thumbnail appears only as a black box. (Click the thumbnail to enlarge it). The performance at this stage was incredibly poor; we achieved a meager 300 particles per 3.00ms. If we want to hit a frames-per-second rate of 60FPS, then we need to cram collision detection, drawing, particles, scene composition, pathfinding and entity processing in sixteen milliseconds. Having to allocate 1.00ms per 100 particles of our 16ms budget isn’t good enough. So the next step is to add an object-pool. If you’re not familiar with object pooling, what we do is create a large ‘pool’ of objects and then recycle these objects for our particles. Whenever we draw a new particle to the screen, we request a blank particle object from our initiated pool of particles, set the desired attributes and push it to our draw list. The advantage this has is then we do not have to create a new Particle class everytime a new particle is created. Constantly creating and destroying the same thing repeatedly is both expensive and wasteful. Once a particle is destroyed, instead of marking it for memory clean-up, we maintain a reference to it and add it back into our object pool.

    Another bland looking thumbnail image. It will get better, I promise! With our object pool in place, our particle engine now performs at 1,000 particles per 3.00ms. Compared to some powerful particle engines that can push out millions of particles with ease, ours is terrible. But 1,000/3ms is good enough for our needs. Further optimization can be done down the line when we get closer to release. The next step is to be able to support multiple particle textures, so we can have a special fire texture that turns into a special smoke texture when the particle is destroyed. So let’s do that now…

    (Click image to view the GIF) Now we can support multiple textures. But I look at what is finished compared to the requested features list and I groan. There is still lots of work to go, and we want to get this game finished. So what options do I have? Instead of maintaining a “not-invented here” mentality, let’s open Google and see what I can find…Well, hello Proton.


    After discovering Proton and diving into the examples and some of the source, I ask myself an interesting question: “This does almost everything we need, is fast, looks fantastic and is easy to implement. Why am I re-inventing the wheel?” Less than thirty minutes after setting myself on Proton, I had it integrated with our game engine and had some simple but cool looking effects being rendered.


    I greatly respect developers who build their own engines from the ground-up, it is a monstrous undertaking but choke full of rewards. But I’m of the opinion where if you’re not a successful developer with a large runway of cash saved up, you should drop the idea of building your own engine and use middleware; unless of course your goal is to create an awesome engine. But if your goal is to develop a game, pick an engine and create that game. There are no “best engines”, pick one and use it. Work around its flaws and keep pushing forward.

    Trying to build everything yourself will only add to your development time, and although it is greatly rewarding if you can pull it off, the time expense in order to develop all of these engines and components can push your small project into an area where it becomes significantly harder to break-even or even make a profit. If you want to develop for the long term, you have to find a balance. Of course, we all have different goals. Some people are not motivated by economic rewards, and are happy in knowing that they completed something of substance. But if you are starting out as a small developer, drop the “not created here” mentality and instead focus on creating the game you want to make. Don’t waste time picking the “best and greatest” engine, choose one that you understand and clicks and work around the flaws; even the biggest game engines will have its quirks.