The Atari Project: Part 01

Introduction

The new Atari VCS 800!!! Isn’t it beautiful?!? When it was first announced, I was super excited. I haven’t put in my pre-order yet, but it’s only a matter of time. And when I do put in that order, it means that the VCS will be the FIRST system that I’ll buy on launch day. I have no idea what games will be available on it, and I don’t care. I just need to own one!!!

I didn’t grow up a fan of Atari. The old 2600 was a bit before my time. My first video game system was the original Nintendo. Atari games looked like old, out of date artifacts compared to the flashy 8-bit graphics of my beloved NES. I have vague memories of a 2600 at the day care I used to visit after school. Playing generically named games like Bowling, and Basketball on a second hand tv at the back of a community center. That was my introduction to Atari. Atari games were something weird and old. They weren’t proper video games.

It wasn’t until much later when I became obsessed with the history of video games that I began to fall in love with Atari. The rise of fall of that company from the first Pong cabinets, through to the collapse of the video game market in 1983 is a fascinating tale, full of geniuses, rebels, and outlaws who built the first golden age of videogames. I can’t wait until they make a film adaptation of the history of Atari, cause it’s a great story.

Once I became a programmer I started to understand the technical challenges that are involved in developing for the 2600. When I was a kid, I just judged Atari games by what they lacked in comparison to the games I was used to on the way more powerful NES. As a developer I came appreciate the games for quality of gameplay that they were able to create with such limited resources. It’s all the more amazing considering the tiny size of the development teams that produced those games. Often a single developer was in charge of creating everything, from designing the graphics, to implementing the gameplay, to crafting the story that appeared in the manual. Innovative and artistic! They are the inspiration behind my “one-man-army”, indie developer mindset. They are the pioneering developers who blazed the trail that I follow, and built the industry that I work in.

So out of my respect for the work of those original pioneering women and men, and out of my nostalgia for the original system that the new VCS is patterned off of, I knew I would be buying one. But then I realized what an amazing opportunity the launch of this system provided for me. I could go beyond just being a simple fanboy. I could make a game and release it for the new VCS 800. I can go beyond idolizing those Atari developers. I can become one!

So I’m developing a game to launch EXCLUSIVELY for the new Atari VCS 800. This blog series is where I’m going to very publicly track the development of my game. My goal is to be very transparent and thorough in my examination of my development process in the hopes that it can serve as inspiration, and guidance for other developers who come across it. My own little chapter of video game history for someone to discover one day!

Welcome to the Atari Project!

I have two main goals with is blog series:

1. Lay out all of my development plans and processes.

The purpose of my first goal is so that I can analyze, iterate, and improve upon my game development process. I want to improve, and the part of the way you improve is by examining your current skills and techniques. Hopefully that process of examination will produce some good examples that readers will be able to learn from. I want to be as transparent and open as possible so that people who are motivated can learn as much as they want by digging around my documentation. I want this to be a valuable resource, and for that to happen I need to invest the time and energy to make it valuable.

Each post will focus on a facet of the game’s development. From the story and art design, to game engines and gameplay mechanics, to code implementation and testing, to scheduling and agile development, to promotion and marketing, to release and distribution. My plan is to cover every topic in detail, which means there will be a lot of ground to cover. Each post will have one major topic, and we’ll dive into the full details of that how I’m designing and executing that element.

2. Maintain a history of the development of the game.

The purpose of the second goal is to make sure that this doesn’t just stay a purely intellectual exercise. I want to make sure I actually follow through and create this game, and one method of motivation that I’m using is public accountability. So in addition to the deep dive into a facet of the game’s development, each post will also include a general update of the game’s development. More of a day by day account of what’s happening with work on the project. Like an agile scrum update of the game’s development.

I don’t think there’s much value in listing the current statuses of a bunch of in-progress tasks for an idea that I haven’t even introduced yet, so the updates on the current work on the project will start on the next post. The only update I will give right now is to say that development on the project has already begun. But instead of focusing on that, I want to spend the rest of this post introducing the big picture of the current game idea.

The Lost Atari Metroidvania

When I decided I wanted to make a game for the new Atari system, I sat down and started brainstorming what kind of game I wanted to make. After playing around with a few concepts, I hit upon an idea that really excited me. A 2d Metroidvania done in the style of the Atari 2600. A game that plays like Hollow Knight but looks like Pitfall. I want the art style to evoke the idea that this is a lost Atari 2600 game, but with gameplay that feels, controls, and contains all the conveniences of modern games. ‘Evocative‘ is the key word here. I’m being inspired by the art and imagery of the Atari. I’m not forcing myself into only using certain colors, or restricting my sprites to certain pixel ratios in order to accurately re-create graphics that could have existed on original Atari hardware. I’m interested in applying the idea of “Atari Style Graphics” as an artistic limitation, rather than a technical one.

Metroidvanias are not small games, and I am aware that setting out to build one is not an easy task. It’s hard to do at all, and it’s even harder to do well. There are three pillars that I see as fundamental to the success of any Metroidvania:

1. The Gameplay
2. The Map
3. The Bosses

As with any game, there are obviously a lot of other elements that need to be implemented well in order for the game to be successful, but I think those three pillars are what most people use to judge a Metroidvania, and they are your points of differentiation in the market. So let’s finish the introduction to the project by taking a look at what early plans I have in place for these three pillars.

Pillar 1: Gameplay

One of the keys to having a successful platformer is having a responsive game engine that feels good to play. I’m building the game in Unity, and I’m using More Mountain’s Corgi Engine as the game engine. I’ve used the Corgi Engine before in previous projects and I’m really happy with it. Not only does engine feel great to play, it’s code base is super well documented and easy to work with and expand on. The engine comes pre-loaded with a bunch of features you want when developing a Metroidvania such as: controlling cameras, generating transitions between rooms within scenes, gameplay mechanics like portals and moving platforms, and a whole host of other elements that make it perfect to use as the engine for this project.

Like most Metroidvania’s, my gameplay cycle will revolve around exploration and acquiring abilities. Your exploring will be hindered by monsters and traps dispersed throughout the map, and abilities will be guarded by powerful boss monsters. The Corgi Engine comes with a bunch of pre-built player abilities, which can be toggled to act as the basis for the player progression system.

Initially the player will start out with nothing. They will only be able to single jump, and will not be able to attack. They will have to explore the world and avoid enemies until they eventually find a melee weapon that they will be able to equip and use to fight against the monsters. I’m not sure what type of weapon it will be yet. My inner Castlevania fan wants it to be some kind of whip. A key thing to note is that while it’s expected that you’ll pick up the weapon and use it throughout the game, I also want to design the game in such a way that it can be completed without picking up the weapon. Even if it is a super difficult path, I want there to be a pacifist route through the game.

Pillar 2: Map

This is part of a Metroidvania’s design that I cannot emphasize the importance of enough. The layout of your map is crucial! You want your players to love your map. You want it to feel natural to play and explore. You do not want your players to get lost and frustrated. You want to encourage your players to explore all you’ve designed, and reward their efforts for traversing it.

When I first entertained the idea of trying to do a Metroidvania, I knew designing the map was going to be one of my biggest challenges. To see if I was up to the challenge of designing something interesting, I decided to test myself. I gave myself a weekend to brainstorm the idea, and try to get a rough design of a map. If at the end of that weekend, I felt like I had enough, or felt confident that I would be able to design the map, then I would move forward with the development.

On the Saturday evening I sat down and I started building a mind map of all my ideas for the game. Using Diagrams.net I sketched out basic ideas for the ability progression, and some rough ideas for boss designs. Whatever ideas I had, I dumped down into diagrams. Then I started using some of the basic shapes and began to lay out the foundations for the world map. What was supposed to be a couple of hours of brainstorming turned into a whole night. Before I knew what happened it was 3 A.M. and I had the first draft of a map for my entire world. It isn’t perfect, and it’s still going through iteration and improvement. But there was no question I felt I had enough to go on. I decided to commit to the project.

Since then I’ve been working on developing the level layout for the first of the 8 biomes. I’m still using diagrams.net as the tool for level layout. I’m finding it to be a really great tool to visualize and flexibly layout a level. My only concern is how I am going to translate the map from the diagram into a level in Unity. I haven’t been using any consistent scales or ratios in laying out the diagram. I’ve just been eyeballing to rough out where I want platforms. There won’t be any metrics in the diagram that I will be able to translate directly to game object or tile placement in the Unity world. At this point I think I will just have to recreate everything in the diagram by hand. I also haven’t been designing the map with divisions into rooms in mind. Overall there are a lot of areas to improve on the map development pipeline.

One of the things I’m looking at to potentially help speed up map design, is developing a Metroidvania map generator based on the wave function collapse algorithm. I’ve done a basic implementation of the WFC in the past, and I’ve seen it used successfully to generate Legend of Zelda map content. I’m not necessarily interested in shipping a procedural level generation engine as part of the game, but a WFC tool could be super helpful in designing the maps. I could use the tool to generate a ton of content, which I could then curate and pick the best parts from to fill in the map. That could save a lot of time compared to laying out every element by hand. But would building the WFC tool cost more time than I would save using it?

Pillar 3: Bosses

This is the pillar that I have the least fleshed out so far in my current plan. The goal is to have 8 bosses to cover the 8 biomes, and then a final last boss for a total of 9 boss encounters. Each boss fight will be a unique encounter against a unique boss enemy. The boss will attack based on some pre-set patterns, with the patterns getting more difficult, or another wrinkle added to the attacks when the boss is at low health. I’m not looking to re-invent the wheel. I just want solid encounters that are challenging and feel good to play through.

So far I have concepts for two bosses, one of which is the planned boss for the first area. Since I have everything I need for the first level, I’m just moving ahead and flagging this as an issue to invest some brain energy in later. While I think I’m okay leaving this a little undecided at this point, I’d like to have more of a solution outlined before I’ll feel fully comfortable leaving it for later. As I mentioned earlier, this is a pillar on which you build differentiation for your game in this genre, and right now my plan for bosses lacks originality. I’m scheduling a brainstorm session for this in the near future.

That Still Leaves A Lot Of Stuff…

Yep. That still leaves a WHOLE lot of stuff up in the air. Stuff I’ll start tackling one by one in the subsequent blog posts. Like any large, complex project, this has a lot of moving parts and it’s impossible to cover everything all at once.

I’m really excited about this project, but I’m also totally terrified of it. It’s a huge undertaking. Odds are that I will end up failing. The most likely outcome is that the project never gets completed. That makes writing this blog seems like a really bad idea. I’m basically documenting my own failure and delusion.

But at the same time this blog is the best idea! Because even if I do fail, and this is just a document of what went wrong, at least people can learn from it. I am committed to sharing whatever I learn. The game may never get completed, but these blog posts will!