Project Atlas Update, June 2014

by Ian Langworth and Mark Logan
on 02 June 2014

We’ve received a lot of email and comments asking how Project Atlas is going, and we’ve gotten the message: we’re way overdue for an update. Our silence wasn’t deliberate, but due to the simple fact that we’re a small team with a limited amount of time. We’ve been working as hard as we can to push the game forward, and it’s time to take a quick break and let you know what we’ve been up to.

Gameplay

Our number one focus has been on making the game fun, engrossing, and endlessly replayable. We’re reexamining the familiar concepts behind RTS games, and this means we get to experiment with anything and everything. Here’s a brief summary of the progress we’ve made so far.

We think it is critical to have a lot of interaction between players in our game. After all, the purpose of multiplayer gaming is to allow players to interact with each other. Yet, we noticed that the interaction in some well-known RTS games is surprisingly limited. Games might play as long as ten minutes before having a real battle, and the outcome of that first battle often determines the outcome of the game. Compare this to first-person shooters, where you’re shooting at your opponents almost as soon as the game starts and quickly respawn after being killed. Since the main way that players interact in RTS games is in battles, we’ve been focusing on encouraging fun battles to happen throughout the game.

To that end, we’ve tried a lot of different game modes, such as king-of-the-hill, map objectives which are captured to earn points, and many different resourcing mechanics. RTS games usually make you build lightly-armored workers and send them to an area with resources, which the workers must collect and transport back to a home base. We found that that mode of resource gathering steals a lot of a player’s focus away from controlling units in battles, and it also leads to a game that can be won simply by having a larger economy than the opponent.

Our current favorite game type involves building towers on top of “nodes” with a single, sturdy worker. The towers produce resources as long as the nodes are held, and they defend themselves by shooting at enemies. This removes the tedium of managing lots of workers, provides automatic defenses that make early rushes easier to fend off, and gives players clear objectives (like destroying the opponent’s towers) throughout the game. It also means that players can’t get an insurmountable lead over the opponents by simply building towers. If they want to win, they’re going to have to fight for it!

Another challenge we’re dealing with is that, in RTS games, it tends to be very hard to recover from losing all or most of your army. By the time you’ve rebuilt your army, your opponent has made their army even larger, so you enter the next battle with a large disadvantage. This makes players afraid to attack each other. When players are afraid to attack, the game becomes very static and boring.

We’ve dealt with this by building what is essentially a respawn mechanic into our game. When you lose an army, the money you spent building the army goes back into your bank after a while. This resulted in a huge increase in the number of battles that happen during games. Unfortunately, it sometimes results in games that never end! We’re still working on perfecting the pacing and story arc so that games have a clear beginning, middle, and end.

Additionally, we’ve spent time in other areas including map design, tech trees, and units. Instead of a fixed tech tree with discrete unit factions or races, Atlas lets you pick and choose a few units from a large pool and upgrade them in-game. The units belong to “colors,” which presents you with the choice of whether to pick all of your units from the same color, or mix and match.

Playtesting

All these ideas are evaluated through twice-a-week online playtests with a private group of early playtesters. Because of our tools and the ease of publishing to the browser, we’re able to make significant changes to the game mid-week in order to test experiments — sometimes we even make changes during a playtest. We let our playtesters tell us what’s fun and what isn’t, and disagreements in the office often end with, “Let’s try it in the next test and see what our players think.”

Our playtest group is very small right now, but that’s only temporary. We’ll open up invitations as we make more progress. Make sure you’ve signed up on our email list below and you’ll be among the first to know when we open it up!

Art

We want Atlas to look great, and our art team has been doing a fantastic job of laying the foundations for producing fresh, iconic art. It’s too early for us to share any concept art — sorry! — but we’d like to give you an idea of how we are approaching this problem.

We’re tired of gritty, realistic, military themed art. We want to go with a more stylized approach with inviting environments and characters who are unique and charming without being cutesy.
The art must be supported by a compelling backstory that explains why the world of the game exists and why the characters are fighting each other.
Art has to support gameplay, not obscure or interfere with it. Readability and clarity are paramount. The visual design of a unit has to reinforce the gameplay aspects of the unit and make the unit easy to see and understand.
We work in an iterative fashion, trying lots of different experiments, until we get to the right place. This is why we regretfully can’t share any concepts right now. What we have now still might change significantly before the final game, and we don’t want anyone to get too many preconceived notions.

Performance and Engineering

Video frame rate is one of the most important factors in making players happy while playing a competitive online game. But, as you might imagine, hitting 60fps reliably in a JavaScript-based game is a difficult task. We’ve spent a lot of time on performance-related engineering, including:

Splitting our game simulation and rendering loops into different threads using WebWorkers.
Using sophisticated state-sorting in our renderer to increase GPU performance and reduce the number of WebGL calls per frame.
Optimizing key parts of the game simulation, including pathfinding and target acquisition.

Another part of making the game play and feel great is making the multiplayer networking work perfectly. That’s been a whole separate challenge involving a lot of work on the core networking code, and we’ve used various tricks to deal with the fact that we can’t easily use UDP networking.

In the coming weeks we’ll be posting some in-depth technical articles about some of these topics. If you’re interested in game engineering, please come back and check them out.

Tools

We spend a lot of time improving our tools, but only when we know or suspect that the time we invest now will have a significant payoff in the future. Sometimes the payoff is obvious, such as adding the ability for game and engine code to be reloaded in the browser while the game is running and without reloading the page. We have a lot of tricks here that we’ll share soon.

One particular tool that we’re excited about is our new map editor. For the last year we’ve been making our maps in Tiled, which is pretty great but is no longer meeting our needs as we begin to add complexity to our maps. We also want to make it easy for our community to create content for the game, so it’s important that we have fun and easy content tools for players to use.

Conclusion

The road to shipping is long, but watching Atlas get better every day makes us feel excited and challenged. We’re going to keep our blog updated so you can follow along in the journey, too.

Blog Home

The Artillery Blog