This review is doomed to be a bit on the short side, if for no other reason than the fact that Game Dev Story is itself short. Beyond that, there’s no story to speak of since the game consists of managing a game developer studio, so those paragraphs I usually spend toward the beginning of reviews rambling endlessly about the narrative and characters aren’t really an option this time around. I also failed to make notes while playing, which makes things a bit more difficult. However, the fact that the game was so addictive that I couldn’t pry myself away from it to jot down notes speaks volumes about its quality.
A loving homage to gaming’s history
While there may not be an actual story to speak of, it should be mentioned that this game more or less mirrors the industry and its platforms over the past 30 years. You’ll be able to develop for the Intendro IES (Nintendo NES), the Sonny Playstatus 2 (Sony Playstation 2), and other creatively-named but instantly-recognizable systems representing the Game Gear, Nintendo DS, and everything between. This adds a certain nostalgic element to the game, and it’s undeniably fun to try and change history by making hit games for systems that never saw them in real life (like the Virtual Boy).
Of employees and stats
You start the game by hiring employees. Of course, the game kind of throws you into the deep end of the pool by not explaining what employees stats mean, but as with just about anything else, higher numbers equal better performance. All employees have four stats: programming, scenario, graphics, and sound. Programming is an all-around stat that also provides bonuses to game proposals and art. Scenario allows you to make creative games with more ease, and also contributes to the amount of research data you’re provided with. Graphics and sound are self-explanatory in that they represent that employee’s ability to improve a game’s graphics and sound (obviously).
You can’t just hire the best staff available to you, though, because you’re working within a budget and have to pay these people a yearly salary. You spend much of the game balancing your team’s abilities with your budget, then. You also have two options open for improving employees: leveling and training. Employees can be leveled up to the maximum of level 5 using research points (which I’ll get into later), though this also increases the amount you have to pay them. You can also train employees in a variety of different ways, which costs money, but increases their stats without increasing their salary.
Before developing games
While you can use your employees to work on contract jobs—which come with deadlines but don’t require any investment on your part—the big money is in developing games. These require a certain amount of money to start making, with PC games being the cheapest (but with the fewest potential users, limiting sales) and console games being more expensive (but having more users, increasing sales). There’s no way to make multiplatform games, sadly.
As your employees level up, new genres and subject matters are unlocked. Developed games can be any mixture of unlocked genres, from a racing game involving robots to a pirate-themed educational game, though certain combinations sell particularly well and are worth reusing.
Actually making those games
Games are defined by four stats: fun, creativity, graphics, and sound. Fun impacts sales, creativity impacts popularity, and graphics and sound have a lesser impact on how the game is received, but are nonetheless important. Developing a game begins with you deciding on who’s going to write the pitch, and then that character engages in an automated minigame where they add to your game’s fun and creativity (with the amount of their contribution depending on their stats). After that, all of your employees begin working on the game, which means sitting around and raising the four stats of the game. The higher their stats, the faster they do this, and the more points your game ends up having.
When your game is at 40% completion, you get to choose another of your employees (or pay an outsider) to focus on the graphics for the game. This takes place as another minigame. At 80% completion, the focus turns to sound and you choose yet another person to take part in a final minigame.
These minigames end up being a huge boost to game development compared to the slower pace of normal development, so it’s important to choose the employees best suited to the task. However, using the same person too much diminishes their ability to produce good work, so it pays to have multiple employees who can do good work during these minigames.
Research and reviews
When the game is finally finished, you start eliminating any bugs that have popped up over the course of development (or, if you want to be truly horrible, you can release the game with the bugs intact). Each bug fixed provides one research point to your pool, and this pool ends up being very important. Over the course of game development, you’ll occasionally be approached by employees to “boost” one of the four aspects of the game. Their base success rate is determined by their stats, with their chance of success anywhere from the minimum 20% to the maximum 80%, though you can make up the difference with research points should their chance of success be too low. Should they succeed, that aspect of the game will see a sizable boost. If they fail, the game’s bugs will be boosted instead. This can be a blessing in disguise, though, since fixing bugs grants you research points.
When your game is finally finished, you submit it and are immediately subjected to the review scores. While your early scores are bound to be in the 3s and 4s due to the low number of points your early team can put into the game’s fun and creativity, the sale of these low-rated games will help you fund better employees, allowing your review scores and sales to slowly climb.
Awards and conventions
Every year, an award ceremony is held where games are honored for their various accomplishments. Your goal is to win the grand prize (and with it, one million dollars) while dodging the “worst game of the year” award. However, these awards seem to be completely random, and I had plenty of critically-acclaimed games that were the number 1 bestseller and still didn’t win the grand prize. This element of randomness can be a bit frustrating since your success in the game is determined by sales and awards.
There’s also the “Gamedex” convention that you can pay to attend in order to get some publicity for your games. You can ignore it entirely, pay a little to just show up, hire some people in costumes or booth babes to drum up more attention, or go all-out and hire a celebrity—who happens to always be Game Dev Story’s mascot, Kairobot. The correlation between these events and sales isn’t something I ever noticed, to be perfectly honest, but I eventually found myself with money to burn and figured it couldn’t hurt.
If you release a game that receives high enough review scores, that game goes into the “hall of fame” and you’re able to produce a sequel. Having a product to work from already means that your game starts with extra points, making things quite a bit easier on you. In fact, my game development studio ended up pulling an Ubisoft and releasing yearly iterations of its popular franchises, which, while not exactly consumer-friendly, nevertheless translated into huge sale numbers.
If there’s any negative worth holding against the game, it’d be the random events. These range from good events like a game site covering you and earning you new fans to bad events like power failures during development that reduce your current game’s fun, creativity, graphics, and sound. While these random events do allow the game to be a bit more unpredictable than it’d be otherwise, negative things like power outages happen far too often to be believable. Plus, there’s no way to avoid them; even once you’ve sold hundreds of millions of games and have a billion dollars in the bank, the game refuses to let you buy anything to help guard against these freak power outages. This means that while these random events are initially believable bumps in the road, they eventually become unnecessary hassles.
This game looks like a Super Nintendo game, basically. Pixel art can go very wrong, but Kairosoft nailed it in this game; the characters all look very distinct, the offices (of which there are three) look interesting, and while there isn’t a great deal of art throughout the game, with much of it repeating, it still was enough to hit all the nostalgia buttons for me and win me over.
Of course, pixel art is nothing without the old-timey music. Game Dev Story may not have the chiptune bleeps and bloops you’d probably expect from a game with pixel art, nor does it sport the Super Nintendo’s downsampled choirs and strings, but it does have a distinctly midi-esque sound to it reminiscent of early DOS games.
Here’s what you should do: