I want to take a step back with this post and talk about the game industry, and then relate that to Astrobase Command.
So how does a game get made at an established, AAA studio?
First, a decision is made to make a game at all. If a studio is planning ahead, when there is still time left on the clock for shipping the current project a small team is formed to pitch concepts and prototype the next game. It’s not efficient to have highly-paid coders sitting on their hands, but some work needs to be done in the design phase before they can be productive.
If a studio is not planning ahead, as soon as the current project doesn’t need coders anymore there is a scramble to have something for them to do (that will ultimately be thrown away).
If the studio is in really bad shape, the coders are fixing critical issues months after launch, but they get pulled off because a studio needs to always have something in the pipe to stay afloat.
Who gets to decide what that game is?
Some studios make games for licensed properties. So that’s a negotiation with the license holder. If the studio is master of its own destiny, they make what they’re good at making. They’ll look at what’s trending this year, and pick an idea that can reuse the existing technologies within the company and leverage the core competencies of the team. Like, “Cyberpunk is hot this year, and we make puzzle games. So lets make a cyberpunk puzzle game.” Or they make the sequel to their last successful game.
If the decision-makers lack either information or ability, they’ll make a mistake: “Well, MMOs are kind of like giant puzzles. We make puzzle games. How hard can an MMO be? I’ve played WoW, the design looks easy. Lets just reuse our puzzle engine as an MMO and copy WoW. But make it Cyberpunk. We’ll make millions!” Maybe they buy the rights to insert your favorite game from 1994, and then beat it with a hammer just enough to make it fit what they were already planning to do.
Then, looking at the budget and the team-size and other larger strategy factors, they’ll set a time-frame. It will either be a realistic one, or not. An experienced company knows exactly how long it takes to make the kinds of games they make.
What’s interesting is that this is pressure not to innovate.
Innovation means risk to the schedule, because innovation is something new. A risk to the schedule is a risk to the revenue projections which might put the jobs of hundreds of developers with spouses and families in jeopardy.
When you have a studio with hundreds of people who have experience making a certain kind of game, and the technology is made to do that, and the tools are made to do that, and the Producers are all comfortable with planning and tracking the work that goes into that, that is what’s getting made.
And the more you make that thing (whether it’s a gritty FPS or linear Action/Adventure) the more you lock yourself in to making that thing in the future. Because you want the developers to work in familiar territory and you want to make games that your technology is good at making.
You can see the problem.
Where am I going with this?
We started Jellyfish because we wanted to try a new way of going forward. Start with an idea; one that comes from gamers who also happen to be game developers. Iterate and improve it.
Engage the community from the start because the players are the people we’re making Astrobase Command for. Not license holders. Not some theoretical person called “the market.” Organize the people and the schedule and the budget around the idea, and not the other way around. This is the power of an indie studio.
Building your Astrobase in the game is just like developing a game.
In both cases, people are the most important resource and part of success is recognizing this. As your crew performs their duties, the associated skills get increased. You want to put your crew where they are competent. But if that’s all you do, your people might improve but your Astrobase won’t.
For example, if all you’ve been using is nuclear reactors, and you just invented an anti-matter reactor nobody will be good at operating it. You will have plenty of opportunity as your Astrobase progresses to innovate. To design and manufacture unique equipment, and modules; discover new mission types, and new ways of operating. But innovation comes with the price of uncertainty. This is the risk v reward equation of developing a video game, and making your Astrobase in this game.
If your best people have downtime and you’re not using them you are still paying for them. They need crew quarters. They’ll interact with other personnel, and if their morale is low from being under-utilized they could sow dissent in the ranks. This happens with coders all the time in the real world (ask Adam!). So always be planning a module or two ahead, as your people grow your Astrobase needs to grow with them.
And obviously, if you put officers in charge who aren’t qualified for their job and/or have toxic personalities, your Astrobase will limp along at best and fail spectacularly in a blaze of mismanagement and bad decision-making at worst.
So inexperienced players of Astrobase Command will start with naive plans and mismanage people and will race to keep the station from falling apart. More experienced players might fail to innovate, falling into the trap of doing only what they’re good at. Their Astrobase may stagnate and eventually there will be a crisis the crew can’t handle.
It’s up to you to try something new — develop your Astrobase like we’re developing Astrobase Command!
