Interview: Good Company Dev Team
As a game that has players building, automating, and optimizing robots (on the way to becoming industry tycoons), Good Company deals with invention and innovation, not to mention morality, even diving into stock trading and logistics on the road to market domination. With my thoughts on the title’s high level of polish and engaging aesthetic (even at this early point in development), I chatted with Chasing Carrots regarding their perspective on the project.
Erik Meyer: The game world involves being a robot-creating tycoon in a bright, Playmobil-like setting, so when it comes to consistency of art, consistency of time period (the 1980s), and consistency of play, how does your team work to make the experience feel seamless and intuitive?
Chasing Carrots: This is an ongoing process with continuous iterations. Some of the most important parts of a smooth gaming experience are ergonomic controls and a clear and readable user interface. Since Good Company is a business simulation game, a lot of interaction happens in UIs and menus. Our goal is to design a simple, yet engaging user interface, preferably consisting from elements players are already familiar with. We try to enhance the experience and the feel of the game with audio-visual cues. Every player action should always trigger an appropriate response.
Another key component is the game visuals. Our concept artist developed a key visual for the game in collaboration with the game designers to capture the core of the game experience. This is not only helpful for the communication with the players but is also vital for the internal establishment of the game’s vision. We print these out as posters and hang them on the studio walls as constant reminders. During development, we’re paying attention to sticking to this vision while creating assets, UI & audio. But it’s important that these visuals aren’t monolithic truths. They’re more like living ideas which also get updated, to an extent, during development. And, as the logical conclusion, one of the key visuals will surely become the cover art for the game.
EM: As a simulator, players keep busy with product crafting, job assignments, and similar tasks. While Good Company doesn’t have the same kinds of in-game goals as a title like SimCity 2000, it does require a careful use of time, given a variety of options. From a development standpoint, how many options are too many (to the point of over-stimulation or meaninglessness), and once you’ve established a core experience, what criteria do you set for additional game features?
CC: Most of our ideas for additional gameplay content come from real world problems in the production and tech industries. Some of us have worked in bigger tech companies and we are constantly making ourselves familiar with common issues that arise in those areas. We believe that modeling our game after real life systems allows the players to make decisions more intuitively. Physics based games, for instance, work the same way. The causality of interactions within physical systems is very complex. Yet, players can pick up those games very easily due to previous experiences with the real physical world.
Still, our main focus is to create a fun experience. If we feel that a gameplay concept doesn’t add to the overall experience or isn’t significant enough, it doesn’t make it into the game.
To be honest, right now (pretty early in the development) we are more worried about not giving the player enough options during the progression of the game. The technical architecture we chose for the project allows a lot of versatility in interactions between objects and thus emergent gameplay mechanics. However, the central component of our simulation are the employees whose behavioral simulation poses a bottleneck for aforementioned versatility. Every new thing an employee can interact with increases the complexity of their simulation.
That said, we prefer not to underestimate the capability of players to handle vast complex systems. The key in our game design is to slowly introduce game mechanics from the beginning. During the first few minutes of the game, the players have very little wiggle room as for what they are able to do. After that, the game will open up gradually and reveal more mechanics. And as soon as the complexity starts to feel overwhelming, we want to introduce tools which enable the player to mitigate this effect. For instance, one thing the players have to learn during the game is to stop micromanaging everything and entrust a manager with repetitive tasks they used to do themselves. We don’t think there is a hard upper limit to complexity as long as we constantly give the player means to gracefully master it.
EM: Chasing Carrots has a number of titles (Pressure Overdrive, Cosmonautica) under its belt, so as a studio, what do you bring to your work from those projects? I notice that your games all include an ability to customize, but what coding/asset/social media lessons have carried over?
CC: Creating games is a constant learning experience and we are trying our best to learn from past failures and even improve things that already work.
After the problems we encountered with the tech we used for Cosmonautica (the engine has been discontinued while another middleware component constantly changed owners), we decided to go with a wider spread and proven engine.
With Good Company, we went a step further. We try not to be so reliant on a specific technology by separating the frontend (developed in Unity) from the gameplay core (developed in the Go language).
Another big lesson we learned during the development of our games: We underestimated the importance of PR and marketing. With Good Company, we are trying to do marketing right from the start. We made a trailer and a website before there was even a game. Those are serving a twofold purpose: They are usable as early marketing materials, and they convey a clear vision of the game internally. We’re hoping to get the players involved in the game very early during its development, to get their valuable feedback and to slowly build a community.
As for technological heritage: Apart from a few snippets and classes, we didn’t take a lot of code from our previous Unity projects. So the most important thing we carried over is intangible: experience.
EM: The Chasing Carrots blog introduces team members, references goals for promotional screenshots, and points to handy dev resources; in the past, for many larger game studios, team progress has been extremely sparingly doled out, so in the world of indie projects, what do you see as key in promoting a healthy level of audience interest, and are we moving toward a time in which the internal message boards become outward facing?
CC: Nowadays, the most difficult part in making a successful game is getting as many eyes (and ears) on your product as possible. We’ve either painfully neglected this part of the job in our previous projects or failed trying. We’ve been constantly under the radar struggling to cause a blip on the screen. Even now, after learning our lessons and realizing the inconvenient truth about game marketing, we’re still learning the ropes. We want to become more approachable to our potential audience which, as we think, is only possible by showing the people and the work behind the project on a large array of channels.
However, we generally do coordinate and/or edit all communication to the outside world (like blog posts, tweets, twitch streams etc.) to a certain degree. Making all of our internal communication public wouldn’t work. It would affect our efficiency. We see internal communication metaphorically as the thought process of our team, a sandbox where we can try out things without fearing any consequences. While our output on social channels is like our team’s voice. Of course, editing and preparing material for public communication does require a good part of our resources. This might become a serious problem for a small indie studio. But it’s a necessary effort in order to be able to catch anybody’s attention.
EM: As an extension of the first question, the 1980s technological modality was pretty specific, and advances were frequent, so as you add things that didn’t actually exist as commonplace products (robots with tank treads, for instance), what guides your aesthetic?
CC: We take late 70s/mid 80s designs like those of the “memphis design group” product and interior design only as reference and inspiration, a starting point for our theme. Replicating the past is not our goal. It’s more like creating an alternative reality. We want to give the theme a little retro-futuristic twist. That’s what we conceive as a common design principle among all Chasing Carrot games.
EM: Touches like employee reports by way of a dot matrix track feed printer make for solid UI elements, but what other design considerations go into your menus and interfaces? As your team creates, what user navigation principles take center stage?
CC: The ideas for the UI are loosely based on the working materials from the 80s era. We want to recreate the feeling of being in a production environment and have to use these haptic tools like filofaxes, vintage computers, printouts, and handwritten notes. The logical structure of getting things done is also inspired by the real world. For example, if you want to order some materials: You boot up your computer, connect to an online BBS and place your order. Soon your materials will arrive on your doorstep. At the same time we are very eager to streamline the whole game experience by focusing strongly on the tasks the player wants to do in a specific moment. Other relevant actions in said moment should be easily accessible but not obtrusive.
EM: A fair amount of the game involves competition with rival companies, stock trading, marketing, and other moral decisions, so with these things in mind, what view of economics and capitalism can players expect? Is this a cutthroat world in which all competition must be crushed, or is there room for friendly rivalry and information sharing (while maintaining Intellectual Property)?
CC: As mentioned earlier, we try to follow principles we see in the real world. We don’t try to deliver a certain message about (or image of) capitalism, economies or society. We want to present the players with an interesting system in which they can have their own agenda and choose from a wider array of interesting decisions. We even toyed with ideas which might lead to players asking themselves interesting questions about economy and morals. For instance, introducing a private bank account in addition to the company’s bank account. Other companies may be contractors, customers, rivals, or a combination of those three. We tend to personify companies and give them predicates like ‘good’ or ‘evil’ because we are social creatures. The truth is, things are a bit more complicated than that. In Good Company we are trying to convey the notion of companies as complicated systems. Boiling things down to a point on a spectrum between cutthroat competition and friendly cooperation would be oversimplifying things to us.
EM: I’m curious about the co-op play you’re working toward; will you pit players against each other, or will teams unite and work toward cooperative goals? As a corollary, what challenges come from a dev point of view in allowing for multiplayer?
CC: The notion of starting a company with your friends in your parent’s garage was the initial spark for Good Company. We decided from the start that the game has multiplayer as a core feature and designed our technological base accordingly. The game doesn’t even make a distinction between multiplayer and single player sessions. The simulation part of the game can be exposed via network at any given time, turning a single player session into a multiplayer one (or vice versa). So, cooperative gameplay within a single company was our starting point for the multiplayer experience. However, we started talking about a competitive multiplayer mode recently as well. That would lead to multiple company instances within one simulation, which isn’t a problem per se (the groundwork for that has already been set). We are evaluating the implications on performance and gameplay aspects. Theoretically, any player can take any role within a company, like any other character in the game. We can imagine having competing teams of players within a simulation, or even players being fired from their teams and switching sides which would introduce an interesting social dynamic to the game. But we’re not ready to make any promises, yet.
From a technical standpoint, we identified the challenges of the multiplayer feature right from the start. We chose our tools in a way that make us less dependent on third party technology. This is a lesson we learned the hard way in past projects. We develop most of our networking code ourselves, which is challenging and takes a lot more time than using existing frameworks. But since the multiplayer is such a central part of the game, we want to be in control of as many technical factors as possible.
In case you missed it, here’s the trailer:
