Sponsored By

Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs.

Spending Time to Save Money

This post explains our experience delaying production on art assets while prototyping and developing our core gameplay in order to save budget.

Keaton White, Blogger

September 23, 2015

7 Min Read

When it came to tackling art for City of the Shroud, we needed a plan if we were going to be successful (still waiting on results for that part). I’ve experienced (and heard countless tales of) studios, big and small, investing heavily in art assets early on and locking in content before the relevant gameplay even exists. This usually ends up limiting what’s possible with the game and costs a lot of time/budget for work that will likely need to be changed or replaced. When operating on a minimal budget, that is probably not the ideal path to success. In our case, we looked at our constraints and our experience, and chose to do things differently.

Art* is nice to look at and it can be really difficult to look at black and white squares and stock figures for months on end. I don’t fault anyone for wanting nice art, and would love more for our game. Still, when faced with constraints, I think it is a safer bet to prioritize developing the gameplay and systems before investing in artwork, which is what we are doing for City of the Shroud.

Obviously, budget constraints aren’t the best. Without the money to drop on art assets early in our game’s development, the team here at Abyssal Arts was forced to work out the vast majority of gameplay and story before we could afford to commit to hiring artists to build our game world. This gave us a clear vision of what we wanted, and by the time we were ready to bring in artists, we had scraped together the money to pay for top-notch talent, who would know how to avoid common pitfalls and save us rework.

*When I say art here, I’m referring to art assets, not necessarily concept art.

Understanding the Needs of the Gameplay

Our game is a “tactical brawler” - imagine if Final Fantasy Tactics and Street Fighter had a real-time baby and gave it a stamina system. Put into visuals, it looks something like this:

 

Our initial concept - tactical gameplay with an action feel - meant we could start out drawing on staples of tactics games like FFT and Fire Emblem. We also wanted the game to be in 3D, so we started with this grey block level:

Can you tell the characters apart?

Beautiful, ain’t she?

We then proceeded to iterate on our gameplay extensively for several months. We looked at how height would affect gameplay, what rotating the camera would mean for players, potential benefits for players who captured the high ground, and so on. In this tiny area alone, we tore down and built up our gameplay more times than I can recall. The gameplay would be too fast, too slow, too confusing, not visceral enough, etc., causing us to iterate and iterate.

To accommodate our tests, we simply moved blocks, added blocks, took them away, and made them taller or shorter. We set them up so that they changed color and provided very basic information to the player, but we stuck with our little grey cubes throughout testing our fundamentals.

Meanwhile, our total environment spend was still $0, but our little grey block world had served its purpose admirably.

Balancing Art and Gameplay

Once we had locked down a system we were confident in, we knew it was time to start seeing what would happen with the introduction of art. We still weren’t ready to hire an artist - our concepts weren’t developed enough, and while we had the narrative laid out, there wasn’t enough concept material to build something that we could guarantee wouldn’t change. Instead, we grabbed about $40 worth of Unity Asset Store assets that were vaguely in the imagery of our game world (all we could find were ruins or deserted villages).

It’s a little… dark?

Perhaps we should include a sun.

Using these assets, we were able to build a level that showed us what we were dealing with on a technical level and how we had to balance that with our gameplay (things are in the way of other things!). We adjusted the camera, playable area size versus viewable area for different aspect ratios, learned what would have a negative impact on gameplay or performance, and could then start toying with overall readability. To name just a few things.

Aside from our time, and again we’re bootstrapping, we’d only spent about $40 on environment art at this point, but we’d managed to get our gameplay to a state that is comparable to where it is today.

Making the Commitment

At this point, we started talking to a friend who worked as an art lead on the Total War series about building the first set of environment models. Our game is a tactical game, so the artistic implications are similar, and upon seeing our game screen, he immediately identified numerous elements that could be improved (surprise!).

We were now also at a point where our gameplay was fairly finalized and our needs were clear. We had more concepts to work with, though they would still require quite a bit of interpretation to turn into game assets - something an experienced freelance artist could offer. So we bit the bullet: we hired our friend to make our first environment.

In preparing to build the pieces, we discussed how we could reuse assets and generally get the most ‘bang for our buck’ - essentially so that we could build a few environments with one set and reuse assets in other sets once those were built. Working together closely (often one of the benefits of freelancers vs full studios), he built us a system that is modular, expandable, and repeatable with plenty of details to avoid visual repetition (for an indie game!).

The most important element, however, is that each piece followed the rules we had for our gameplay and our settings in Unity. The pieces dropped into our game, and once configured, were good to go. There was no fussing or late nights spent trying to make the elements work with our systems or rebuild anything - we simply built the environment following what we knew about our gameplay, and we were done (this was also made easier by our game type).

Compared to hiring someone onto the team (like we could) or building assets early and hoping that they don’t need reworking later on, the cost was very reasonable. Hiring a talented freelancer can be expensive, but constantly redoing everything as our gameplay evolved would have been far worse. In the end, our environment spend was within our tiny budget and perfectly adapted to our game.

Wrapping it Up

To give you some perspective on the length of this process, those environment pieces only went into our game a few weeks ago, and only took a few weeks to create, while Abyssal Arts celebrated its first birthday during the first week of September.  

For us, any amount is a large amount of spending, but on this we were confident because we had done extensive prep work in laying out exactly what we needed on a technical and gameplay level, and only then hired someone who knew how to build assets for our type of game and was intimately familiar with the genre. Had we tried to build the assets during grey block testing, or skipped prototyping with Asset Store assets, we would almost certainly have ended up squandering a lot of money we don’t have to waste.

Our approach with City of the Shroud has been and continues to be: experiment and test until we’re confident we can commit to the next step. It can take time, but it has saved us money, and, most importantly, forced us to focus on making the game.

Read more about:

2015Featured Blogs

About the Author(s)

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like