#DevlogsGame Development TutorialsBecoming a #GamedevWhat's up!

Art is the biggest barrier to completing and shipping a game

WeeRPG - Creating an indie-sized ARPG

Art is the biggest barrier to completing and shipping a game. 

In my experience developing indie titles, art is one of the biggest barriers to completing and shipping a game. For my first article for IndieWatch, I decided to share some behind-the-scenes information about how my current game started. I also explore how I scope ideas to something I can ship.

 

This is a recent progress gif of my current game, which has the working title of WeeRPG
This is a recent progress gif of my current game, which has the working title of WeeRPG

A Content Problem

I’ve worked on a variety of 2D shipped indie titles and a ton of game jams. I primarily work with a friend named Victor (Vic from here on out), who created the open-source FlatRedBall game engine and we share an obsession for two things:

  1. Perfecting and optimizing our tooling for insanely fast workflow.
  2. Figuring out the perfect game size and process to ship with a tiny indie team.

Most of the games I have shipped are built with very small teams. One game was primarily a solo effort, several other games were teams of 2-4 people. As we have released games and improved our tooling, the bottleneck for development velocity has consistently moved from code to content.

In other words, art is the biggest barrier to successfully completing and shipping a game.

My current game is an ARPG – a game genre I have wanted to make for years. But a key factor in shipping a game is understanding how big it is or could be in terms of effort. And an ARPG was always too big to make by myself. Let’s assume the game is 2D with a top down perspective (think original Zelda games) and movement can happen in 8 directions. Further, assume you can flip the horizontal movement sprites so you must animate up, up right, right, down right, down – 5 total. Here are the frames needed:

  1. Walking in four directions: 20 frames (4 each direction)
  2. Rolling/dodging: 10 frames (2 each direction)
  3. Basic attack: 20 frames (4 each direction)
  4. Death animation: 6 frames (directionless)

So that’s 56 animation frames to create for basic movement. But then you need to create animations for every piece of armor you want. And for every weapon. And for every NPC. And, you also must create all of the overworld tiles, dungeon tiles, special attack animations, etc.

This was always the point that I abandoned the idea of making an ARPG. It was simply too much art and I don’t enjoy frame animation in the first place.

Just Make the Sprite Wiggle

In October, 2020 my gamedev partner and I were about to ship Kosmo Squad, a pixely, twin-stick shooter in the vein of geometry wars. We built the game start-to-finish in two months and we were on a high because it came together so effortlessly and we were proud of what we made. I began thinking about what I wanted to build next and I was really feeling the ARPG vibe. So I started to really focus on the content problem.

In 2017, Vic did a one-month game jam game called TownRaiser with a few other people. I came in late to the game because they needed art and with only a month we had zero time for animation. I created character art and told the developer to “just make the sprite wiggle and bounce on top of a shadow like a kid playing with an action figure”. He did a perfect job and the result looked great (for a game-jam game). Here’s a gif:

(see the full video here)

I was thinking about TownRaiser and how two sprites, a character and a shadow, came to life with just a bit of programmatic motion. And that got an idea started. What if I expanded that “just make the sprite wiggle” concept but used a stack of sprites? I drew the idea out on paper:

A few days later I had a handful of sprites created and was experimenting with state-based animation in a program called Gum – which is intended for UI creation in FlatRedBall… not entities! But the result looked cute:

I dove in and within a few weeks I had procedurally-animated weapons working pretty well too:

Ultimately we had to improve and optimize the engine and UI system itself to handle entities that were created and animated in a UI-editing program but animations and entity design came together at least 3x faster than previous games!

Conclusions

WeeRPG has now been in development for a couple months. It’s the biggest, fastest game I have built. In just two months I have four player local coop. Players can fight through dungeons, earn random loot, equip gear in an inventory screen, and fight a variety of baddies. I’ve already created the art for more than 45 weapons, 10 suits of armor, and 8 enemy types. The game is moving to a shippable state at an extremely good velocity.

This process and practice of thinking of scope and content load first is the result of years of failing to ship games because they got too big and myself or my team burned out. I strongly recommend all indies develop a really good sense of exactly what you can do, how fast you can do it, and then scope your game towards that.

WeeRPG - Title Screen

Ship the game you can build until you can ship the game you want to build.

Catch me on twitter for random gamedev tips, progress updates, and more!

 

 

Join us!


How about writing your own piece for IndieWatch?


Justin

Justin Johnson is a Senior Program Manager at Microsoft by day and an indie gamedev by night. Justin has worked on multiple released indie titles including The Incredible Baron, Masteroid, Kosmo Squad, Super Refreshmen, and more. He's been a contributor to the FlatRedBall game engine, tools, and community for a decade.

Leave a Reply

Your email address will not be published.

Back to top button

Adblocker Detected

Please, consider turning off your Adblocker so you can enjoy IndieWatch and contribute to our site's existence. We need to display ads so we can keep our gears smooth and running. Thanks for you cooperation!