Preface
What am I reading? This article is mainly intended for people who are interested in game (and/or software) development. The idea is the combine general good advice for development that we we either knew from before or picked up along the way, and how they were implemented into our game project. It’s not intended as any commercial “success story” (spoiler alert), but how we achived the very rewarding task of completing what we set out to do. As both in my own history and that of fellow developers I met throughout the years, I learned that completing a project where you yourself set all the boundaries is many times more difficult than any client work.
This article is written to stand on it’s own legs. The best way to take as much as you can from reading this is to play our game, it’s 100% free and about 2-3 hours of game time and then read the article. (Click here to Download it from Steam)
Introduction
How it all began. The year 2020 will be rememberd for many things. Most things bad, but for me and Marcus we’ll always be able to also remember seeing our game “Beyond DAWN” live on Steam, and after a nervous download later the game launched and played as expected. It marked the end of a long journey as well as instantly beginning a new one.
The journey started as I was just outside my office on a cold day in the spring of 2018, Marcus wrote me a message asking if I’d like to develop a game with him, just like that. With anyone else I wouldn’t have thought much about it but if you know him, saying yes will not just an excuse to have beers and mess around with some prototype. As I agreed I was well aware that this was a commitment to really finish something, exactly what that wasn’t clear, but it was a commitment.
Starting out
Where to begin? There’s nothing quite as daunting and exciting at the same time as looking at that empty paper or code editor…And when creating a game you have to stare both of them in the face. For anyone like myself, being a software developer as my profession. It’s almost impossible not to have developed (or tried at least) a game at some point as a way to learn the craft. And it’s an invaluable lesson to have learned the difference between developing the engine and developing the gameplay, as well as the effort required to do both. This was one of the big fears I brought up in our early conversations, that it would just never get made because of the time required it would take just to do the behind the scenes work. That’s when Marcus brought up the idea of using a game maker engine, a choice that both lowers the ceiling of the finished product, but on the other hand builds you a floor to stand on. So we decided to go with Rpg Maker MV (the latest version available at the time).
Further conversation immediately went into technology, how could you “max” this engine we’re working in and what kind of effects we could apply to combat and adventuring sections. It’s very easy to get stuck in an imaginary future full of explosions, complicated mechanics and revolutionary new gameplay ideas. What we agreed upon was to not to set a restriction on ourselves but to focus on building a game that would never rely on any single technical feature, and unless you are experienced enough to know from the beginning what is possible and how much work it will take to create a ground breaking feature, don’t bet your entire game on it.
Scoping
Drawing boundaries. It takes a lot to set limits on your passion project and it took a lot to sit down and actually set limits on what were set out to produce. Especially when creating something with a partner, it’s very hard to say words as “that takes too much time”, “that’s too complicated” and so on, without sounding negative and killing the creative energy that surrounds any startup project. A good approach to this is rather to first try to find some boundaries of what you are setting out to do by asking ourselves some simple questions.
Who is going to play this game? This might seem obvious, but in order for anyone to play a game, the game needs to be finished. And this is the key part of choosing your intended audience. Can you actually finish a game built to sell millions of copies? If the answer is no, ask yourself if you’d rather be the only person in the world to play it, but to play a finished game – or having an impossibly ambitious game half finished and retired somewhere on your hard drive. And the answer to that is not obvious, there are plenty situation where getting that killer feature to work is enough on it’s own and if it does work, you can use it for your next game or collaborate with someone who will create the things you are less interested in.
Some people will say that if you aim for the stars, you can land on the moon. But ask yourself, how many people have landed on the moon by randomly aiming for the stars?
For ourselves, we simply wanted to get some people to play it who we didn’t have to personally ask to play it. Wheter it was 10 people or 1000 people was not important, and for someone who has not developed a game or software application it might seem humble, however it’s anything but.
Why should your audience play the game? If we for the sake of simplicity divide games into 3 major components: Graphics, Mechanics and Story. Ask yourself, how many games you love get an A+ on more than one of those boxes? And on the other side of the coin, how many games did you enjoy that hade none of them? Most likely your answer is very few. So the question to solve really is what you can make that will stand out?
When confronted by this, the first thing we did was to at our own skillsets. On the plus side I had at the time around 15 years of experience developing software (though not games), and Marcus had lots of experience writing and producing music. But most importantly, we both have had a passion for storytelling, me with a number of failed and uncompleted movie screenplays and Marcus as a Dungeon Master in Dungeons and Dragons.
I think the reason why Marcus thought of me to begin with was my development experience, and the techonoly was the obvious route to go, but in the end our analysis was that the ceiling is so high when it comes to gameplay mechanics that to stand out in that aspect was not feasable.
Marcus has more experience in music as I have in development, but we deemed it not enough of a key compontent to alone be the selling feature. Furthermore, neither of us has the art skills to create some (on their own) game selling graphics…
So story it was, Marcus had already created a solid outline for the characters and basic interactions between them. But we still needed that hook that could capture the interest of a person just by explaining it. More about that in a later chapter.
At what point is the game finished? Compared to a movie or a novel, this is a much bigger question in a computer game. A big question for a Roleplaying game is always, how long does the game has to be to tell the story you want to tell, and what kind of quality can you maintain throughout that journey.
Our solution was to not put pressure on ourselves to conclude the story in our first game. We wanted to have at least one our of gameplay, including one town and one dungeon both at high quality. We also choose not to write the story in a traiditonal novel form. We instead created some key dramatic moments we wanted to reach and developed the story and the game continuosly.
The downside to this approach is definetly speed of development, it’s much faster to create a game where you know exactly where you are going, but this approach worked well for us as we were learning the game maker tool and having the flexibility to alter the story as we found our ways in the technical aspects it allowed us to work around dead ends in having written events that perhaps we couldn’t have programmed into the game.
Writing the story
Writing a game is different… Compared to other genres, RPGs have the greatest emphasis on story. But the main difference between writing a traditional script and an RPG is that the players needs to feel they are themselves writing their own story within the overarching plot. But all the basic rules of drama applies to a game just as any other media, and it’s very helpful to read about dramatic writing before starting the game writing process.
The major components as we divided the story into was: Setting and concept, plot, dialouge and character interaction. I don’t think there’s any wrong part to begin, in our case the base plot came first and quite naturally as we brainstormed som characters and interesting events and adventures that we could put them through. And I think that a good baseline for the plot is that it can work independently of the setting, which we chose to sci fi/steampunk just because it appealed to us.
Going back to the “why”, or more accurate “how” we were going to find our audience. The story needed that one thing that could spark interest and first get the player to commit to making the download. And secondly, to invest enough time with the game to get deep enough into the story that they’ll want to see it though.
This idea can literally come out of nowwhere, but it’s huge misconception that it’s something that just has to find you. My experience from this is that the more you actively think about it, and the more you write down. Even an idea that you know won’t make it is worth to write down, because a spark for much better idea can be waiting there. The story of Beyond DAWN came to me when watching a history documentary, the dates where changing back and forth between C.E and B.C.E and there was something there that caught my imagination. I started thinking about those people living before year 0, how the years were counting down to something that had yet to happen but everyone is unaware of it. And I thought, what if if they were aware, how it would it change their thinking.
At the time the Fridays for future movement was exploding in popularity and without involving any opinion on the subject, the conversation was very similar to counting down to a year when it will be too late to save the earth.
From there I very quickly wrote my concept into the already existing framework of the story and pitched it to Marcus who liked and added his own ideas into it.
So the only hard part was yet to come: telling other people about it… This is extra hard when you are older and having a “respectable job” as you might think people will find it funny or immature that you are working on this kind of project. As a general rule though, and if you take anything from this chapter with you I hope it’s this : Almost everyone have something creative they dream of realising, and when they find out you are actually doing that, you will be encouraged by the response.
It’s actually a very good test of your concept to see if you can tell someone about it in no more than a couple minutes and see if they understand the concept enough to ask questions to ellaborate what you just said, or if they ask for clarification. If you can explain your story like this in direct communication, it’s very good sign that you can explain it through indirect communication when marketing the game.
Prototyping and Demo making
Cutting a slice. Making a demo of any software is a much bigger task than peole give it credit for. It’s something inherently logical for anyone who has never been tasked with actually creating one that a 10 times smaller product can be down with 10 times less effort. If you are developing a game for the first time and you are thinking about it, know that this is not the case. Have a long think about what you gain and how much effort you will put into it.
At worst, a demo becomes a side project which will continue to live on after it’s first release as to keep your audience patiently waiting for the real release and this can become a huge strain on production. It can also become a graveyard of early design mistakes and bugs you made as you were experimenting in the initial stages. That why it’s never a bad idea to completely start over once the demo is completed and launched. Another one of these somewhat illogical timewards is that it will never take as long time to remake something properly that you once made while feeling out the process. Most of the time the product will be twice as good and take half the time.
The obvious benefit to having one is that people will be able to test a limited version of the game, you can raise some publicity etc. But – this is in general not the main benefit but instead the icing on the cake. The main benefit for us was to learn the tool we were working in. Had we already been experienced with it, the benefit would be very small….Because
Evaluation and feedback
Getting people to play your game is hard work. It might seem like a nice proposition to get to play a game that a friend or family member has made, at least that we were thinking. We created the demo (Which now remains in the trials part of the finished product). We uploaded to dropbox, made a list of 30-40 people we knew were into games, created a closed facebook group for the discussion that were soon to follow.
We sent out the links and a message to the group, and….nothing.
We figured the installation was too much, so we made a browser based version you could play on the website…nothing
Some personal persuasion then, one on one conversation with close friends…Technically something as some people did play. But most gave up at the slightest bug/obstacle, so still…nothing.
And just in case one person in particular is this, we did in the end get one piece of solid feedback, you know who you are and thank you!
Now this is a limited sample and you can get lucky or have more motivated testers than us, but the point of this is to say that do not expect too much. There is nothing more discouraging than presenting something you’re proud up to the world and getting nothing back.
So in order not to get into a negative spiral, make sure the demo has a value in itself. That you get to test mechanics, get a sample of how much dialouge is needed, what kind of art assets you will need, etc. There is a lot to be gained by the demo that’s outside only feedback from others.
Completing the game
The big push. The demo is done and it’s time to move on towards proper completion. This is the part where it’s most crucial to have a plan on where you begin and end, and what comes in between. Know fully well though that this is the part where you will get the best ideas, and you will want to add “just one more feature”.
Let’s be very clear, some of these new ideas will be the best ones you have, and not to add anything outside the plan is a huge mistake. But of course, adding so many features that you get stuck in development purgatory (that is not being able to move towards completion because you’re adding as many features as you are completing) or going so far off script that your story doesn’t make sense anymore.
Of course there is no simple “one fits all” solution to this situation. The way I approach this situation in any development project is to think of the Minimum viable product (MVP), if you are not familiar with this this concept I recommend you to read up on it. But the way we approached it here was to focus completely on implementing enough features to make the game be both playable and enjoyable, but leaving space open to add more features – but only once the MVP has been completed.
For us, this included among other things, three complete reworkings of the games maps. No one plans to rework something three times, but it happens very often in software development. All that needs to happen is that you raise the level of one little section significantly and suddenly, all your other work that you recently were quite proud of – looks unacceptable.
This is when the scope of the game is so important – had we set out to make a 10 hour game instead of a 2 hour game, we might be tweaking the graphics to this day or knowing we had to settle for less.
Bug testing and tweaking
If ‘this’, then ‘…what?’. Another huge misconeption about development is that you spend a majority of your time developing (shocking…). Rather, most of us spend it debugging. And I would even call it a more important skill than doing the development is to be able to solve the bugs. Accept the fact that they will happen, they will be hard to find, and you will not have fun working on them.
So, what can be done to spend as little time as possible with bugs?
- Limit using code you don’t understand and 3’d party applications.
– We all do it, but the impact of using that finished code snippet or a plugin that does exactly what you want is not always known when you include it. They are often made to do exactly one thing that works with the core engine, but not with each other. So the more you stack in your project, the more likely it is that they will clash with each other. - Ask for help, but know how to do it.
There are lots of groups and forums where you can interact with people who can help you solve your issue. And you’d be surprised just how much effort a complete stranger can put into helping you. But, you have to put in the effort as well. And that means including in your question all the information needed for them to see the full picture. - Test often and diligently. This is extremely important if you are starting out, never let a new feature to go untested! If you have a bug and catch it – when you caused it five seconds ago you will not struggle to realise what you did to cause it. If you find it a week later, you will have no clue where to start.
Releasing to the public
Hello world! First of all I would recommend having a plan for this long before the game is reaching completion. The amount required to put it on a platform should not be underistimated, and if you spend your last drop of energy developing the game it will be very hard to reload and start wrestling with the Steam games portal. The second aspect is for yourself to deterime when the game is actually finished.
When is it finished? Having pre-defined the paramaters for a finished product (such a minimum viable product) is a huge help, but one thing to know (and this goes for all software) is that you will never feel that the game is 100% completed. There will always be graphics that can be improved, battles that can be balanced, (non game breaking) bugs to fixed. And don’t feel bad about tweaking the “very last thing” for the 100th time. But, you do need to release it, and when you do you will find another 100 “last things” to fix. So don’t postpone it. Our approach was to release but also don’t make a big deal about it, we snuck it onto the Steam store and managed to get a few players who contributed some very valuable feedback and bug reports that were crucial to be fixed before any proper reviewer played the game.
Marketing
Getting noticed. Being two humble scandinavians, this part is and was more difficult than any technical challenge. But you do need to tell people about your game at some point. And again it has two major parts. How do you present the game and what do you present?
Marketing materials – This is another part of the project that often gets neglected, but it absolutely needs to be done. Some by necessity, for example if you publish in the Steam store, you need to create a number of graphics to even get to publish the store page. But doing this one by one is not a great idea, it will often become a scattered mix of styles and colors.
What I would recommend is to have atleast the following (not ordered in importance).
1. logo for the game, with the game title perfectly readable.
2. main graphic, not a screenshot for the game but something that represents the theme, if you struggle with creating one – consider using stock image.
3. trailer showcasing the game, it’s just a fact we need to realise with the selection of games that are out there that no one will bother to download and install your game blindly. However watching a video of one or two minutes showing the game is something everyone can invest.
4. Platform to communicate with your audience from. There are a lot of choices here, the easy choices are a website, a facebook page, a instagram account. The right choice(s) will need to be adjusted to your needs. We settled on going with Instagram and website.
1. Instagram – If you have a lot of good looking graphics and don’t intend to write long texts.
2. Facebook – If you see your audinece in the facebook demographic (30+ age group) and is your content “like friendly”.
3. Website – Do you have the need to be able to post many different types of information/media and can see yourself getting good SEO points.
(Note/Disclosure: I’m a web developer by profession so for us it wasn’t a big step to take to build this website, but even if you are not already experienced in building websites, there’s nothing wrong with starting out using a engine to create it (Such as wordpress.com or wix.com).
Now, chances are you are reading this because you are making a game in a game creator engine yourself, and we need to face the fact that our games will all look fairly similar to the untrained eye, and something that looks like “everything else” won’t draw much interest. I think this question has many solutions, but our was to go very story and concept heavy, it’s impossible to know if that was the best choice, but whatever route you go to, commit to it!
Spreading the word. Unlike back in the days when it was easy to know where to go but near impossible to get noticed by the game related magazines, tv shows etc. Today games are everywhere and much closer to us “normal people” but also they have a lot more selection in what to cover, but do try some one on one communication with websites, youtube channels etc that could be interested in your game. But don’t get discouraged with non-answers, it’s hard to get noticed.
Now what?
If no one will do it for you, pat yourself on the back. If you reached this far you have done more than a majority of all game developer hopefuls. The big question will usually if you should continue your game (to a sequel, or a remaster) or start a brand new one. My only suggestion is that you do something that will force you to learn as much as your did while making the previous game. Not only because learning is always good but it’s hard to stay motivated when doing similar work that you know already.
I thank you for reading this and I would love to know what you think.
/ Fredrik
