Weekly Content Blog #20: A Look Back

This is the twentieth weekly blog post here on Something Classic’s website. We’re also closing in on two years of development time on our main project, Shadows of Adam. How time flies!

In light of these arbitrary time markers, I thought now would be a good time to look at the earliest phase of this project. During the initial few months of this project, a variety of gameplay elements, design, and ambitions were completely different than the project as it exists today.

The Original Project

Like many projects I’ve been involved with, there was not a whole lot of structure or ambition early on. Our team was even smaller than it currently is, and our only intent was to do a fun hobbyist project to get back into working on projects together again. The initial goal of the project was to create a simple 8-bit style RPG in the style of Final Fantasy 1, including selectable character classes, a Gameboy Color inspired aesthetic (even so far as using the Gameboy’s 160×144 resolution early on), and chiptunes galore. Our target platform was to be mobile: Android and iOS.

Glitchy early menu

Glitchy early menu

As a small team of 2, we proceeded to create early prototypes in this very retro style. The original battle system was much more text based, did not feature any on-screen protagonists, and featured a bland white background much like early Pokemon games.

With these parameters in mind, the basic menus, shop system, message box system, and battle system were eventually completed. Tim, who was an old friend of Tyler’s, helped us get up and running with some basic tiles and helped coach our then-artist Matt on some pixel art skills. Our project was getting some structure in place. We frequently had Skype voice meetings in which we sketched out character profiles and began forming a basic plot line that seemingly resembled Final Fantasy 1.

Early Influences

I have always liked the idea behind the much-maligned Final Fantasy Mystic Quest: an easily digestible RPG. While that particular game arguably had a very flawed execution, some of its choices were of considerable interest to us early on.

The plan was for the game to have field items much like FF:MQ (or more famously, Zelda). These were to include bombs, a machete, and even a bow and arrow. These items would have served two purposes: clever puzzles in major dungeons, and accessing areas that were previously inaccessible.

The other key element we agreed upon early on was avoiding random encounters. All enemies must be visible on screen, and touching them initiates a battle. For some reason, this seemingly essential design choice is absent from a vast majority of retro jRPGs.

Coming Together

Very early portraits for characters.

Very early portraits for characters.

Around this time, we began writing the almighty Design Document. The Design Document was to be the holy covenant of this project, laying the precise blueprint, parameters, goals, aspirations, hopes, dreams, and plot outline of this project. Deviating from the Design Document was punishable by death. Creating the document was very, very important and helped codify a lot of project details we still adhere to today. Even if it’s no longer followed to the letter, the Design Document is the foundation for any game development project, and its importance cannot be understated.

The game as we had conceptualized it was an 8-bit style jRPG with heavy influences from Final Fantasy 1, Gameboy Pokemon entries, and Final Fantasy: Mystic Quest. What a weird combination, huh? While intriguing, we quickly found that it was not meant to be…


An intro dungeon that was later abandoned.

An intro dungeon that was later abandoned.

This early phase of the project was short-lived. Our original artist Matt left the team due to time issues, Tim became a full-fledged member, and we began narrowing our focus a bit. The extreme retro aesthetic began to be ditched in favor of a larger resolution, more detailed battle backgrounds, a (slightly) more pleasing menu skin, and actual instrumentation vs. computerized bleeps and bloops.

The character class system was axed, in favor of fully developed characters who existed in pre-defined roles. As time moved on, we also dropped the (admittedly cool) field item mechanic, in favor of more ad-hoc dungeon puzzles. The bland “save the crystals” plot line was fleshed out significantly, resulting in a much more dynamic set of characters and an interesting game world.

In continuously refining our project early on, we gained a great deal of focus that enabled us to create the project you are seeing today. At the same time, however, the scope and feel of the game had drastically changed during this shift.

Here and Now

New menu WIP

New menu WIP

While the basic gameplay systems and plot skeleton were ultimately preserved from this time period, the early phase of the game almost feels like a completely separate project in retrospect. It taught us the importance of focus and working to our strengths. Rather than heavily emulating a handful of games, we began to find our own style. What began as a low-production value, mobile minded game without much planning has evolved into something completely different. Any game is going to go through a variety of changes along its path to completion, and Shadows of Adam is no different.





Weekly Content Blog #19: Budgeting the Art Costs of an RPG Pt. 3

This is the final part of a three part series.
Part 1: Budgeting the Art Costs of an RPG Pt. 1
Part 2: Budgeting the Art Costs of an RPG Pt. 2

Welcome to the last article in this series on budgeting the art costs of an RPG, which to be fair, should have been ‘Budgeting the Pixel Art Costs of an RPG’–  but I digress. In this piece I will be fittingly talking about what it means for us  to “finalize” the art in Shadows of Adam, and what can be expected in regards to the overall art costs for various RPGs built out of pixels. You’ll find that game scope and resolution play a major factor in determining cost.


Wrapping Up Early

If you’ll recall, we were about 3/4 of the way through all of our tile needs when our tile artist, cyangmou, took a temporary hiatus. Turns out he was working hard getting a trailer ready for his own game, Tower 57 (subscribe here and here for updates). A month before its official Kickstarter launch, cyangmou graciously stepped in for Something Classic to put in his final time on the tile sets.

It’d be fair to say that we had lofty goals for each environment in Shadows of Adam. Each place was designed with specific functions and mechanics in mind, and a lot of that carries over to the aesthetics of an area out of necessity. Our original intentions were to have over the top mechanics for each area. The kind that require a lot of unique art and showy animations to keep the mechanic novel, engaging, and enjoyable. Turns out that can be really time-consuming to create. Throughout the design of each area we’ve had to make cuts to the scope of what we wanted to portray visually. There has always been a soft cap on how much time should be spent on a single tile set. So when a tile set was reaching that cap we’d often have to make choices between finishing the base tiles with animation, designing and animating a core game play element, or creating a major set piece to make sure the tile set was memorable. The choices weren’t always easy, but all were necessities in order to keep the costs within our original budget plans. Cash can be a good incentive when it comes to making tough choices about what to cut.

In the final stretch of our tile budget we had a limited amount of time to finish up all outstanding tile sets. At minimum this was two major dungeons, the world map, and polish tweaks to a few unfinished assets and environments. In addition to that we had goals for one or two more tile sets, and the editing and expansion of a few other pre-existing sets. All of which we cut in order to make sure that we could fully polish the minimum requirements instead. Cyangmou handled our needs like a champ, often working with me to make sure all of our priorities were being hit, and offering suggestions on what to focus on. His value throughout the project cannot be overstated, and at the end of the run I am happy to say we are 100% tile set complete with no regrets.


Breathing Life

With all of the tile sets done for our game, once all of the mechanics are in place, the game can be fully developed with placeholder graphics. Art no longer being a blocker means we can start exploring what our finished game actually looks like. In a big budget game this would mostly be determined in pre-production. As an indie game you’re always in pre-production, pre-production doesn’t end until you can concretely state every aspect and direction of your game. This is exactly what we’re locking down right now.

Tile sets make up a major part of Shadows of Adam’s aesthetic, but it’s still our job to breathe life into them through the rest of the art. There are character sprites, portraits, enemies, battle backgrounds, visual effects, lighting systems, and various animations that all go into creating an immersive RPG world. Which is not to mention the all important UI. In order to finish our game everything I just mentioned needs to have a set standard, and our final assets need to meet exactly that standard. Fortunately development has been strictly focused on a small sampling of all these requirements. Any time our style evolved, that sampling evolved with it, but we did not create new assets. As an example we’ve been working on this game for two years, and we only have 15 monsters designed. A third of which have been untouched quite literally for years. We still need to design about 50 monsters for our game, but a lot of cost will be saved by getting them fully polished on the first pass.


Counting Costs

Speaking of cost, we’re at a point in our project where it’s clear what the total art cost is going to be. Using our outsourcing costs and my own time converted to a dollar amount our art budget falls in the $15,000-20,000 range. Which may be a little surprising to some considering that Shadows of Adam is a game whose scope is reasonable. We’ll have about 12-18 hours of legitimate game play over 5 major dungeons. But the truth of the matter is that making an RPG is extremely costly in terms of the art resources needed to generate hours of game play. In our case it costs about $1000 to make 1 hour of game play. And this is a low resolution game with a highly-polished, but easy to make style of art. If your game is high resolution, has a hard to replicate aesthetic, or time intensive animation, the costs go up exponentially— 8bit RPG $200/hr of gameplay, 16bit $1000/hr, HD $10,000/hr. These are just indie costs for relatively small teams, a full fledged game studio would incur far greater costs than that. When you decide to tackle the art for an indie RPG know that you are going to either be paying for it out of pocket or in blood, sweat, and tears. Even a modest game like our own will have taken over 500 man-hours to create all of the art for. If you’re a one-man/woman-show doing everything on your own, the project could realistically take over 2000 of your own hours.

And on that note all of this talk of hours and working has me exhausted. I hope you learned a bit from me in this series, or at the very least got some insights into how we work at Something Classic. Next time it’s my turn to write I hope that you’ll have a demo of our game in your hands.

Weekly Content Blog #18: Lights, PFX and Concepts

Hello everyone!

Today I want to talk about some of the tasks I was working on since my last blog post on June 23 (https://www.somethingclassic.net/weekly-content-blog-15-not-invented-here/). Last time, I was working on a particle effect implementation for ‘Shadows of Adam’ so we can quickly create new visual effects cheaply to add more depth and detail to our game world, and that extra spit of polish to some of our game systems. Since then, I have primarily been focused on figuring out an adequate lighting solution that blends well with our art style (Read: Not detailed so the lighting sticks out from our art, but also not too ‘pixely’ it’s a simple shape) and that’s been quite a challenge. We’re still working on it as a team to this day, but I’ll share some concepts of methods we have tried so far. Next, I’m going to talk more particle effects and discuss in detail how they work in SoA, and what we plan on using them for. First, let’s share some lighting tests we ran:

Raycaster-lightsThe first concept test we ran was a raycaster-based lighting system. The test we ran is actually an Impact plugin created by Marc Henklein, with minor modifications. The approach here is to shoot multiple rays from a central position into the game world and create a circle (*or semi-circle, depending on our angle settings) and then fill in the circular shape with a specific color. Next, we take this shape and draw it over our dark mask, essentially punching a see-through hole in our otherwise blinding curtain. Finally, we draw the resulting image over our game layers to provide the Light/Shadow effect. Simple, and works well. However, the lights don’t look very good in that screenshot. They’re passable, but we need to do a few more passes and have the lights blend better with the game world so they look more realistic and less ridiculous.

lights-2 The next lighting method we tried is more demanding graphically, but yields much better results (As you’d expect, eh? 😉 ). Basically, we create a radial gradient in an off screen canvas element and then draw the gradient image onto our game world wherever our ‘Light’ entity exists, and finally draw a dark mask over all of our game layers to finish the effect. The end result is what appears in the screenshot to the right, and the shots below. A very quick implementation that is decently fast, and allows for many lights in a scene, but the cost of using this method is we lose control of fine-tuning how our light should look, and the resulting lights look slightly out of place in comparison to our art. We have to find the perfect balance so we can show off dynamic lighting effects, but have them blend seamlessly with our environments. It’s a tough problem and one we are still working on!


I spent the entire last blog post talking about particle effects (‘PFX’), so I won’t go over too much that wasn’t mentioned before so I don’t sound like a broken record. So today, I’m going to talk briefly about the technical details of what makes our PFX system tick.

pfx-texturesOur particle system was built to be data-driven, with every particle being enclosed in a JSON particle file. All we need to do to add a particle effect into the game world is 1.) Position an ‘Emitter’ entity and 2.) Give the ‘Emitter’ entity the name of the particle effect to use. From there, all settings are controlled directly from the particle file. The structure looks like this:

Once a particle file is loaded into the emitter, we next create an off screen canvas element. This off screen canvas will act as our renderer; instead of drawing particles directly to the visible game world, we first render all of our particle effects off screen in memory, and then only draw the resulting image into the game world. In the picture to the right, the blue square represents the border for our render space, and the red border are the boundaries for the emitter itself. By rendering our particles this way, we give ourselves some extra flexibility on how we want to control both our emitters and our particles. Since our Emitter is an entity, we can control it like we would any other interactive object in the game and tween it, animate it and position it however we want. Further, since our particle render target is its own separate image, we can animate it and tween it independently of our emitter. Below, you’ll find a real-world example of our PFX in action. In this screenshot, we are using it to create smoke from the Chimneys in the town of “Adam”
If anyone has any questions, or has an opinion on some of the images in this article, please let us know what you think in either the ‘Comments’ section or the ‘Contact-us’ option at the top of the page. We’d love to hear your opinions!

To close, I’d like to show off a sneak-peak of some of the new UI concept work Tim has been working on. It’s his turn to post next week, so a little teaser should be good :)

Weekly Content Blog #17: Jump Inside My Head And Let’s Map! (Part 2)

Welcome back to another edition of Life as Luke. When we last left off, you were flouting your father’s advice to become a plumber/electrician and instead spending all your time making maps with the Earth Maze tileset. This has led to you being courted by one Tyler Mire to become the lead level designer/mapper for Something Classic. Fierce negotiations ensue.

Being a self-centered, what’s-in-it-for-me brat pays off big. Only after Mire promises you the moon and the stars and the super-massive black hole at the center of the universe do you finally seal the deal. Then you pack a suitcase and catch the first bus to Nashville, but not before flaunting your success and telling your old man where he can shove his copper wire and plumber’s wrench. Hahah!

The Big Time
Ironically, though you are the creator of dazzling Earth Maze temples of breathtaking size and beauty, you yourself work, sleep, and live within the confines of a six by six foot cell (or cube) at Something Classic’s rickety Nashville office. As it turns out, there will be no moon or stars unless the game turns a profit. And even if that happens, the super-massive black hole you asked for in the deal will probably consume them. @#$%!

Worse yet, two Canadian programmers are responsible for implementing the puzzle elements of your brilliant level designs, and their pig-latinesque English makes every communication a nightmare. You just wanted to build beautiful levels, but now you’re mired in detailed spec sheets and test cases. You fantasize about home… Mother has made your bed with freshly laundered sheets and the refrigerator is full of Chipotle chicken burritos and…

Get a grip! You’ve got maps to make!

You sketch out five or six ideas for the underground town you’re working on and then pick the most interesting one to refine further. Since you know the Earth Maze tileset like the back of your hand, you can confidently create designs on paper that you know will be achievable with the existing tiles.

Making the Map
Again, you know the tileset well, so you have a great feel for how much space each part of your design needs. When you open the ImpactJS map editor you sketch in only two elements to start.
1) Passable ground tiles
2) Water (to define the space better)

Not too shabby! If this was the 8-bit era you’d be halfway done! But that golden era has passed. You were born too late.

With a wistful feeling in your heart and a barebones framework on your screen, you begin to lay down the basic details.

Out of the deep, jet-black darkness a world of rough earth and heavy rock emerges!

You enclose the world in a jagged frame of stone, sealing it off from the soulless scream of empty space! The first tendrils of detail creep across the hard-packed floor.

Your new world is bright and clean and new and super uncool. You need to distress the hell out of it like a pair of brand new denim jeans if you actually hope to attract people. Get out your blade scar that hard red stone!

For the coup de grace, you splash that map with some color and details. A stone pillar here. A stone pillar there. All while telling yourself that no Minecraft-esque map-making algorithm will ever replace you! Not with a map like this, no sir! You are an artist!

Well, that’s it for that map. It’s time to take a break and wait for inspiration to strike before starting the next… not! Genius is one percent inspiration and ninety-nine percent perspiration! Time to get back to work!

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 big 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!