I’m Amir, one of the creators of DragonRuby Game Toolkit. I’m hoping that the contents of this page helps you out in your game dev journey.
I really do give a shit about indie game devs that are starting out, and really want you to ship a game. If you need specific advice (or just need to vent), I’m a chat message away on the DragonRuby Discord.
I’ve been doing full time indie development for seven years now and have released multiple commercial titles with gross revenue over $1M+ (each title generating at least $20k over its lifetime). Hopefully, this level of "success" gives at least a little bit of weight to my advice.
I started my game dev journey back in 2013. I quit my corporate job 'cause I was really burned out (I wanted to make things for myself as opposed to some random enterprise). I ended up porting a web-based incremental game - called A Dark Room - to iOS.
I spent about seven months developing the mobile version; initially porting the default experience over, and then enhancing it with additional narrative components and “visuals” (I fixed a ton of pacing and mechanical issues too). After releasing ADR, it just kind of sat in the RPG section of the App Store for six months and barely made any sales.
On April 14, 2014, 11:00 pm (six months after release and eleven months after the web version had its day in the limelight), the mobile version went viral and hit the number one spot in the App Store. A Dark Room amassed over 10,000 paid downloads per day, for over twenty days straight. This lucky break allowed me to continue my indie journey.
Over the past seven years, I’ve released four commercial indie titles (all have done very well with each game having 20k+ downloads, and hundreds of ratings with a 4.5+ star average). I also managed to get access to console SDKs and released A Dark Room to the Nintendo Switch. Throughout that journey, I also created a commercial game engine - called DragonRuby Game Toolkit - that encapsulates everything I've learned as an indie. Alrighty, enough about my background, let's get to lesson one.
When thinking about what game to build (your “pitch” for the game), put an emphasis on the overall spirit of the game that you hope to convey, and the emotional response that you want to evoke from the players; as opposed to the specifics of the game mechanics (which can change and be fickle).
Your convictions and ideals matter. Your identity as an indie matters. It’s the solitary marketing edge you have over AAA companies (you are a real human being with a face and a name…and those who play your games, by extension, should know you).
Play to your strengths with laser focus. Do not be a generic game dev. You control the spirit of the game, it is an extension of yourself, and this can and should be used to your advantage. The big name companies can't do this, so here is your chance to use your individuality to your benefit in a way you could never could if you were simply working for a large company. Don't think of being a small Indie as a weakness, as it is your greatest strength.
When thinking of a game to build, imagine that you’ve shipped your dream game. What does the perfect 5 star review look like for your game? Imagine someone has downloaded your game and has become a super fan of yours. They leave you a glowing 5 star review. What does this review say?
Thinking of the 5 star review first, forces you think about how the game feels as opposed to worrying about specific game mechanics (which are fickle and can change over time).
These are actual reviews people have left for my games. The definition of being a successful game dev is when the “perfect 5 star review” you envisioned, becomes reality:
Hope ★★★★★
I have waited to write a review until now. I started way back with A Dark Room. Finding the world mysterious, frustrating, yet oddly satisfying and enlightening, I looked up who made that spectacular game, discovering Amirali Rajan and his games. The ensign came next. Getting through that game was significantly more difficult and took way more time and dedication to get through. The ideas surrounding those two games are extremely unique and satisfying, the best experience and thing to come out of owning a smart phone to date. That was 4 or 5 years ago, I’m not sure. When A Noble Circle came out, I was intrigued. Completely different style, extremely difficult. I went through and beat it though, loving the story and waiting for each update. This must have been a year or two ago. Tonight, I checked back and saw a new update, with a new ending. The message is awe-inspiring, deep, life changing, motivational, introspective, and truly touching. Amirali Rajan deserves the world for what he has communicated through his games and the obvious love, passion, and effort that has been conveyed. I discovered Hope many months before, and I have grown up with it thanks to this man, finally relayed my experience. Amir, if you read this, let me know how I can help continue your passion and support you through a monetary donation because you deserve more than any money-sucking impersonal game that Supercell or any other company produces. This work is truly incredible.
Speechless ★★★★★
I feel unworthy to give this work of art a review. The creations of Amir give me pause.. this one particularly brought me to tears. The beginnings of these “games” are always fraught with questions and strange curiosities and thoughts. Its not until about halfway through you realize that you are violently invested both mentally and emotionally trying to make sense of these unfathomably deep yet simple worlds. By the end, the curtain rises, you are greeted by the creator and you feel a cool and unnerving sense of accomplishment and wonder. I really have nothing left to say. This is a thing of art, and it is good. Thank you.
These reviews are not intended to simply be shameless plugs for my games (side note: added benefit), but rather to highlight the emotional response I was able to garner. When I start work on my games, I begin with the abstract: the emotion, the feeling, the vibe, and go from there. Remember, your game is your art.
Many people measure success only through money, but in reality it's a bad metric (and yes I'm well aware that my introduction contained "$1M"... I wanted you to keep reading ^_^). The real definition of success is shipping a game, built with a specific intent, and having that intent conveyed flawlessly.
So think about what you want your game to say to a player (and by extension what you want a player to say about your game), as opposed to trying to reach some arbitrary dollar amount. Shoot for getting one, single, perfect, 5 star review.
Build a large game not all at once, but through smaller experiences that you can separately monetize. These smaller experiences can then be composed together to create the game of your dreams. As an exercise, see if you can take your favorite game of all time and split it up into "sub games" that can be sold independently.
Everyone is inspired by past games that they have played. Follow the inspiration. Build the game of your dreams. But do it one tiny piece at a time. Here are the steps I use when envisioning my games.
One of my favorite games of all time is Final Fantasy Tactics, so let's use that as a concrete example.
There are so many things I could remove from that game and still have this be my favorite. I kept removing things (using the steps above) until I reached a point where removing anything more would have ruined the game (for me). Here are a few things I realized about my “core” Final Fantasy Tactics experience:
As an indie, I don’t have the resources to build the entirety of Final Fantasy Tactics. But, I can build a FFT style experience: where there are only two classes; a few weapons; and an emphasis on world building.
Given this “core” description, I can build smaller games that actually have a chance of shipping (aside: these are complete, standalone experiences, and shouldn't be confused with DLCs).
Here are some example games I could build that could be composed together later into Final Fantasy Tactics.
With each game I build, I try to address an aspect of the larger game that is "high risk" or beyond my current skillset. These smaller games allow me to explore and make mistakes in a constrained space. When all is said and done, I have code assets that can be leveraged for future games, and a shipped artifact that I could charge for (not to mention that this is a good way to start growing a fan base).
So, try this partitioning technique out. Hope it works for you as well as it has worked for me.
For the love of all that is good, ship something and do it quickly. Don't be a dev that spends years on a project that never sees the light of day (it sucks to be in that kind of development phase with no end in sight).
Don’t try to compete with AAA companies or try to capture large, generic markets. Build meaningful/fulfilling games for smaller, hyper niche communities. Build many small games that each generate “small” amounts of revenue (as opposed to toiling away for years on a single title).
As an indie, you have limited resources, limited (zero) marketing budget, and limited capital (this definitely stacks the deck against you from a revenue standpoint). But there's good news, your expenses are small too. You can afford to build games where revenue potential is "only" $5,000 to $10,000 for a given property.
Large AAA companies like EA (even indie shops with team sizes larger than 8 people), will not go after these niche experiences. It’s just not worth the development costs.
There is a Reddit community called r/Emuwarflashbacks which is dedicated to The Great Emu War. An excerpt from Wikipedia:
The Emu War [...] was a nuisance wildlife management military operation undertaken in Australia over the latter part of 1932 to address public concern over the number of emus said to be running amok in the Campion district of Western Australia. The unsuccessful attempts to curb the population of emus [...] employed soldiers armed with Lewis guns—leading the media to adopt the name "Emu War" when referring to the incident. While a number of the birds were killed, the emu population persisted and continued to cause crop destruction.
This is a game that’s worth building if you are passionate about The Great Emu. Especially because r/Emuwarflashbacks has 82,000+ members.
NOTE: Before talking about money, I think it’s important to state that revenue is the by-product, not the goal. You’d have to build a game that captured the spirit of the Great Emu War, and you’d have to be a genuine member of the community. So yea, don’t be a predatory-asshat-sleeze-ball (community members will see right through it).
Okay, let's do some math:
So, think deeply about the games you yourself love, the niche communities you want to be a part of, and how you can bring those two worlds together. If you're able to make even a few small games per year (remember Lesson 2), over a long enough timeline, you could find that the revenue from all your titles might let you quit your day job.
Ship a prototype that resembles The DVD Logo scene from The Office (except add the ability to pause the bouncing by pressing space on the keyboard). It should be cross platform and render at 720p. When I say cross platform, I mean really cross platform (PC, Mac, Linux, Web, iOS, Android). This is harder than you think.
This small step matters. You need to exercise the "ship a game" muscle. I want you to be able to reply with "Yes!" when someone asks "Have you ever shipped a cross-platform game?". This quote by Steve Jobs is poignant:
"Real artists ship."
I'll say it again to emphasize its importance:
"Real. Artists. Ship."
When an aspiring game dev asks me "How do I get started as a game dev?", I tell them to build the following game and ship it:
50x50 pixels in
size - at the center of the screen that has a resolution of
1280x720. x and
y direction at a rate of 1 pixel per
simulation tick. The speed of your box simulation
should be 60 hertz (60 "ticks" per second).
1280x720
canvas. space key, the box should stop
moving. When you press the space key again, the box
should resume moving in the direction it was going.
Here is the source code for "The Bouncing DVD Screensaver From The Office" written in DragonRuby Game Toolkit. Take the time to read through it. Every line is commented.
The implementation of the game is one file, and ~70 proud lines of code. It's important to emphasize the word "proud" because this is something I wouldn't be embarrassed to show someone else. This implementation isn't an attempt to write as few lines as possible or trying to be "clever" in any way. The code is sane and readable.
If you don't have the engine locally, you can use DragonRuby's Online Sandbox to see it in action (and even change the source).
I've refrained from talking about other game engines, until now. Look at the source code for this game. If you currently have experience with another game engine, try to implement the same game in your engine of choice. Then ask yourself if the solution is better or worse than DragonRuby Game Toolkit? Ask yourself these questions as you are building thing the game:
Be sensitive to what pains the engine of your choice puts you through to build the simplest of 2D game and ask yourself if it's acceptable. What could the engine have done better?
I'm an indie game dev just like you. I built DragonRuby Game Toolkit because I wanted an engine that understood the struggles of an indie game dev and supported my path to success. I wanted engine that didn't just sell the dream of becoming an indie dev via training videos and asset stores, but actually helped my dreams become a reality. I wanted to an engine that removed all the pain of building and deploying for modern systems, so I can concentrate on creation. One that is simple to get started with and yet has the power to release to consoles.
After seven years, we have an engine that provides the solutions us indies need. That engine is DragonRuby. Carry the fire.
I could write a novel on using "best practices" to your advantage in the workplace. After all, every corporate culture strives for its workers to follow guidelines and industry standards. And it’s true, blindly following best practices and adhering to industry standards is a great way to get a job working (overworking) on someone else’s dream game.
If that is what you want, then just ignore my advice and use industry standard game engines and best practices. That is certainly the safe option, but safe is not necessarily fulfilling and rarely the most fun. If you want to have a fighting chance of making a living off of your own game ideas, throw out that conventional wisdom, and learn to treat “best practices” as simply “the current meta”, and break out of those constraints. Bend those rules, examine, and dissect the best practices. Think of “off-meta” solutions to get the edge you need to survive and make it as an indie.
To put it another way; it’s not enough to be as productive as everyone else. You have to find ways to beat the averages. “Best practices” is a complete misnomer. It’s more accurate to call them “averaged practices”, or ”generic practices”. Don’t be generic.
What I'm about to elaborate on is a hard pill to swallow. It may directly challenge your identity as an indie, and devalue all the countless hours you've spent learning an "industry standard" game engine.
The official term for this uncomfortable feeling is cognitive dissonance. But here’s the thing, uncomfortable is good. To grow and challenge the status quo, you have to make yourself uncomfortable. Average is comfortable, but success as an indie is never going to come from following generic practices, and by extension, putting out a comfortable/generic product. As indies, we don’t have that luxury, we have to beat the averages.
If people from the industry were telling me I have to do this or that, I would run straight in the opposite direction. In order to find if there aren't any other options elsewhere. - Yoko Taro, Director of Nier: Automata
There are many examples of off-meta solutions throughout history. Here are a few examples that will hopefully encourage you to take the path less traveled.
Super Smash Brothers Melee's competitive community has had "off-meta upheavals" throughout history. There's a 3 hour documentary series about the game's history if you want all the details.
To save some time, here are three notable competitors that have had an off-meta rise to greatness:
It's important to keep in mind that Melee has been the same game since November of 2001. When competitive play started taking off, the "best practices" was to always use Sheik, Fox, Falco, and Marth. Players would look down on anyone who used a character other than these four.
Axe, Hungrybox, Amsa (among others) proved the masses wrong. They were part of the "best practices upheaval". They prospered and gained a massive "off-meta head start" over the competition. Everyone continued to dismiss what they saw, they didn't like the cognitive dissonance they were feeling. Eventually, these players had to accept a new reality, and then find ways to catch up.
In 2001, the "best" characters of Melee were only Fox, Falco, Sheik, and Marth. By 2013 the competitive ranks now include Jiggly Puff, Pikachu, Peach, Captain Falcon, and Ice Climbers.
League of Legends is another game where off-meta techniques forced a fundamental change to the game's landscape. The "best practice" was to have the team split into a 2-1-2 formation across the map's three primary paths. But players like Diamond Prox challenged this notion. He employed an off-meta approach that later became a key role in the team.
Again, everyone else saw this off-meta approach and dismissed it. And yet again, these players had to later face reality, and realize that they had been left in the dust.
In both of these examples, it's important to observe that these individuals who employed off-meta solutions had deep knowledge of what was considered "best". With that knowledge (and the drive to beat the averages), they came out on top. This same idea can be correlated to great writers. They have mastery over the rules of grammar, but they don't always adhere to them. Great writers know when and where to break these rules, and from that comes things of beauty.
Building a commercial game engine is a non-trivial endeavor. I had eighteen years of software development experience under my belt (gaining a deep understanding of best practices), and only after that foundation did I have the insight on how to break the rules. Here are just a few of the best practices, industry standards, and status quos that DragonRuby challenges:
The list goes one. But the general theme is the same. DragonRuby Game Toolkit provides off-meta solutions so that time is never wasted, and cognitive overhead is removed. That's how I beat the averages.
At this point, you have two ways to deal with some potential cognitive dissonance. One way is to dismiss these bullet points and continue doing what you've always done. The other way is to push through the uncomfortable feelings, and see what's on the other side. Ask yourself if you want to be part of an upheaval, or a witness to it.
The tricky part of this lesson is that there isn't a prescribed path to beating the averages and challenging best practices. I had to find my own way, and only started to considered off-meta solutions because of an essay I read back in 2010. I'd encourage you to read it too. The realization that best practices were anything but, occurred because of this passage:
In a big company, you can do what all the other big companies are doing. But a startup can't do what all the other startups do. I don't think a lot of people realize this, even in startups.
The average big company grows at about ten percent a year. So if you're running a big company and you do everything the way the average big company does it, you can expect to do as well as the average big company-- that is, to grow about ten percent a year.
The same thing will happen if you're running a startup, of course. If you do everything the way the average startup does it, you should expect average performance. The problem here is, average performance means that you'll go out of business. The survival rate for startups is way less than fifty percent. So if you're running a startup, you had better be doing something odd. If not, you're in trouble.
Think hard about the things you accept as "best" and see if you can find ways of challenging those ideas. At the least, I hope DragonRuby Game Toolkit helps you beat some of the "averages" that currently exist in game development.