“Complex”

Every one of the 80 or so collectible dragon in Spyro the Dragon’s remaster is uniquely modeled and animated. They each appear for about 10 seconds on screen. It’s a fact that these dragons are entirely pointless to the overall game and that the amount of work that went into them borders on reckless.

Recently Marina and I have tossed around the term ‘complexity’ when it comes to making Anodyne 2.

Complexity is easiest to explain on the level of visual art. It’s the trap for beginner game developers, especially those attuned to visual art but not other aspects of design. It happens when any of the following get too big for the artist to handle.

• Number of art assets in the game (characters, enemies, environment objects)
• Number of animations per art asset
• Art style

If there’s too many art assets or animations, each asset takes longer to revise, and overall art production takes longer. Risks a revision. Art style being elaborate just makes that worse. Imagine hand-painted or pixeled backgrounds. The iteration takes a very long time. This is why if you see a game with an extremely complicated art style and a tiny team, you can bet that it is probably not coming out soon, or if it does, its design might suffer given the difficulty of revisions or iterating.

This applies to game design, too. For every thing the player can do, you’ve gotta somehow fit that into your game. That’s something to think about. If it needs to be clearly communicated, is it? More playtesting. More bugs. It also creates tasks for the programmer. Or, it creates art to make or music and sound to make.

It also applies to writing. Too many main characters? Now you have even more plot arcs to write, more cutscenes to make, more balancing to do with where you read them in the game. Oops, now the programmer has to code all these things too! More chances for bugs. More things to tweak. Good luck! You’ll need it. Have fun remembering all this alongside the 100,000 other things in the game.

Now, is it worth working 10 years on a game? I don’t think so.

My game Even the Ocean is a textbook example of this happening, stretching out a game’s development to 3.5 years. By not properly setting a good scope for the game within pre-production, we waffled around, resulting in numerous design, writing, and art revisions. The game was also too big – too many cutscenes, maps, levels, mechanics. If the game was drastically shorter or scoped down, these revisions wouldn’t have been as numerous or time consuming.

I think we’ve recognized this while working on Anodyne 2. I think, inevitably, some things will be and have been more complex than I think necessary. Some steps we’ve taken:

• No dynamic music (less music and debugging to do.)
• No autosaving (less bugs related to saving in weird places or at weird times.)
• No baked lighting (less time spent making art in areas)
• Very simple combat (simplifies the possibility space for 2D mechanics)
• Reusable boss patterns (reduces programming time)
• No collectibles outside those that advance the main game (reduces design, testing, coding, writing time)
• Removing extra supplementary cutscenes we used to have planned (reduces writing, coding, etc)
• Some level design tricks which I can’t talk about yet (reduces art time as well as design time and code and everything really)
• Using Unity, saving tons of time on tools programming
• Use of ‘fade text’ to simplify and reduce cutscenes and animations. This is the use of fading partially to black and displaying text on top, describing a cutscene, rather than actually programming and animating what the text describes.
• Few custom shaders (less coding!)
• Very simple models and textures (quicker art!)
• Relatively loose main story (after the first hour), meaning the player less often must be guided by hand-crafted cutscenes (less coding, writing, etc!)
• Few main characters, reducing complexity of the script (easier writing!)
• Minimal platforming mechanics in 3D, due to the difficulty of debugging 3D physics and camera mechanics. (less coding!)
• Many NPCs share animations or only have a simple bob. (less art!)
• Little need for optimization thanks to most Unity scenes being small/separate. (less coding and bugfixing!)

Of course, the game is still ridiculously complicated and stressful to work on! Even with all these simplifications! Part of it is inherent to the genre we picked – a story-driven adventure in 3D and 2D, which often requires lots of unique assets.

But imagine if I had all of the above to worry about, too.

Anodyne 2 wouldn’t be coming out next year, that’s for sure.

Remember, your game doesn’t need to be complex to be good. Your ideal version of your game is not necessarily the minimum it needs to be good.

Also, a lot of this matters less if your game is much shorter. Keep in mind complexity mainly becomes a problem based on how long your game is. Also, this advice probably applies most to games that could be called similar to Anodyne, Even the Ocean, Anodyne 2, All Our Asias. I don’t know how to make an elaborate roguelike game.

A lot of what I’ve outlined above falls into a ‘lo-fi’ production ethos – trying to find shortcuts where possible and work within your capabilities. Trying to work commercially, like with Anodyne 2, does make things harder as we have to make some compromises (like putting in extra polish in parts because it helps with marketing the game). But…

I hope we can deliver Anodyne 2 on time! I’m always worried about it… but at least, this time, I’m thinking about these things.