Moondrop is a small indie game studio located in Hamar, Norway, focused on making games that are interesting, beautiful and respectful towards players. Two full-time developers, Stig-Owe Sandvik (designer/artist) and Andreas Fuglesang (CEO/programmer), determination, experimental methods and compulsive behavior are key ingredients when Moondrop makes games.
“What should have been a short project with combat mechanics and no story ended up as an atmospheric story-based puzzle game that took a bit more than 4 years to make”, the developers recall as they share the story of their game Amphora.
A Clear Idea of What We Wanted To Do
We were three guys freshly out of college, with very clear ideas of what we wanted to do. We knew we wanted to make games that were not exploitive towards the players, but would make their life more fun instead. We chose to focus on gameplay, though we also value originality and harmonic beautiful audiovisuals. With Amphora we thought we were making a small-ish game in terms of timescale on production, but after all we learned to never underestimate circumstances that are over your head.
A Game for Different Stages of Player Involvement
We don’t want to reveal too much of the storyline, since we’d like the players to figure out as much as possible on their own. Against conventional wisdom, the player is not who the primary story is about. The player guides the story, and is still the most important aspect of it, because without them time stands still. But since our main mechanic makes the player a very powerful being, and very different from the other inhabitants of the world, we found it difficult to make the player avatar an equal participant in the story, and so the focus is on the more common characters that don’t have any special powers.
The story focuses on a girl whom the player witnesses growing up. This is symbolical, as the player also “grows” while playing, understanding what the game is about and what they can and cannot do. There was also a goal to let players enjoy the game on several different layers, based on how involved they are. One can enjoy Amphora by just experiencing nice visuals and soundscape, but if they want more, they can discover a story unfolding, or the real story underneath, or uncover deeper meanings — but we don’t force or require players to dive into that, leaving the choice up to them.
Without A Single Word
We decided that a text-based story or tutorial wasn’t something we wanted to delve into. Both because it would be another element we’d have to create and use resources on, but also because we felt text is too often used as a crutch in games.
It was also a part-experiment to see how far we could push a game to teach something without telling the player straight up what to do. Doing this gave us many headaches when designing levels, but in the end we managed to construct something that performed what we wanted. Now we just provide a few icons to teach the controls and the rest is up to the player to figure out. We want the player to play, not read text or see long tutorial videos.
Not All Users See The Story, But Most Do Enjoy
So the Amphora story is told completely through the visuals and gameplay without a single word. It’s risky, since a couple of playtesters did not pick up on any of the overarching story. Later we made some things more obvious because of this. Still, a small fraction of players anyway didn’t get a coherent story out of the game, and one did not see any story at all. These players still said they were impressed with the game and enjoyed themselves, so we decided not to do major changes to how the story was told.
Making the tutorial was quite difficult, since part of players would never try to experiment. If they just tried to press anything they’d notice the interactivity, but instead they sat there staring at the screen. It took some very careful observation of the players’ reactions to get this right without them ending up completely confused, but we feel we managed to get this aspect mostly right. We will use these learnings in other games, as they seem to make the tutorial phase more enjoyable for the majority of players.
Mechanics, Design and Playtesting
The main mechanics is about lifting and drawing cords that can be attached to almost everything in the scenes. One issue was that this mechanic made the player very powerful, and therefore we struggled quite a lot to design puzzles that wouldn’t be trivial. Had we known how difficult this would become, we’d probably have taken steps earlier to either change the goal of the game, or even make the mechanics different. The game was planned to be longer, but the difficulty of designing as well as aiming for the highest quality restricted it.
We decided quite early in development that we would structure the game in singular limited scenes. This was part-technological - to avoid optimizations to make the engine run huge levels, but also a choice to be able to more rapidly iterate, rearrange and scrap scenes. We found that naming each scene something topical made discussion and editing easier, even if the names were never exposed to the players.
We did early playtesting standing behind people’s backs, which might have made them perform worse than if they were playing the game at home, since they might feel like they are being judged. It’s been time-consuming for us as well, but for me it turned out easier to read what was going through their mind as they were actually playing, than watching recordings afterwards.
Have you ever walked into a room and forgotten why you went there? Don’t worry you’re not turning demented, it’s a common psychological phenomenon involving how our ancestors needed to think differently when they entered different environments. We’ve encountered a similar thing a lot with playtesters of Amphora. We wanted each scene to be unique, both visually and thematically, but it resulted in players suddenly forgetting the mechanics they had already used several times. For this reason the game became a bit easier and more straightforward than we planned - any small detail that could confuse players would confuse them.
A Team Member: Not Just Work Capacity, But Also Knowledge
Our biggest setback was when one of the teammates had to leave us. With him we lost a lot of knowledge that took much of our time to regain (by learning it ourselves). He was also our CEO at the time (as well as graphics programmer), so two important roles had to be filled. This pushed the team to being one artist/designer and one CEO/programmer, meaning almost double workload for both. Losing a team member means not only losing their capacity to work, but their knowledge as well.
We took up the burden of finishing the game, since we didn’t find anyone to replace our former team member. Our programmer did learn what that guy knew, but the time it took made us postpone the release for almost a year. This was great for the company as a whole, but the time lost made us reach the boundaries of budget.
Pragmatic Approach To Pretty Art
One of the more constant aspects of our game has been the art style. It was one of the reasons why we picked this project. And since silhouettes require less details and still look good, it would be possible to accomplish the project with just one part-time artist. That made the effects and colors ever more important as to not make the game look cheap, so we invested some extra time on image effects and particles etc. We got a lot of amazing feedback on our art, people seemed impressed, and so we were really happy with how that choice turned out.
We are also proud of our smoke effect, which was both a blessing and a curse. It made effects easy to create, has a great unified style, but also came at a great cost of rendering lots of pixels with many dynamic textures. And its limitations made it difficult to work with and ended up taking a lot of time.
Good Audio On A Budget Turns Award-Winning
Not having a huge budget for audio, we commissioned a friend, Paal B. Solhaug, to do the music and let him retain most of the rights for it. We may have had him set to work a bit too early as we only had a few concept images and a not-so-clear description of the game. Even though he felt he didn’t have enough to work with, we were happy with the tunes he made, and they helped us set the vibe of the game.
As for sounds and ambience, a guy found us by pure chance when his teacher asked the students if they could make sounds for our project. One of them, Kristian Brastein, had the vision for the game that we were after, and ended up being a great addition to the project after he finished school.
Their efforts were praised not just within our team: Amphora won the Best Game Audio award at Indie Prize at Casual Connect Amsterdam 2015.
Remaking An Engine With A Working Prototype
When our team was graduating from school, our main skills were Flash and C++ development. We wanted more out of the game than what Flash could offer, so naturally went ahead and began writing our own engine in C++. Using some third-party libraries we managed to get an early version of the game up and running, though that’s when we noticed the downsides of our choices. After a year of feeling this effect we ended with the worst possible outcome: having to rewrite the engine and discard the pieces that didn’t work with our vision. It was a difficult decision that we agonized over for some time, but in the end it turned out the right thing and recognizing this was crucial for the continuation of the project.
Rewriting the engine while already having a working prototype meant that we knew exactly what was required of the engine when starting anew. This made the engine more robust in a way that supported the game better and enabled us to continue development much more smoothly from that point onwards. It made us realize the importance of what a more complete prototype could do for the success of making good tech choices, and how to know exactly the requirements of an editor for the game.
We decided on making an in-game editor, which may or may not have been a good idea. It was great that we could easily switch between the working game and tweaking every setting of a scene, but the editor suffered from not being a priority and had issues that never got resolved.
A game is in essence a sophisticated way to display data that is interactive, but we made the engine data-driven way too late to understand the importance of this. An important discovery was when we made the decision to buy/use RUBE. This was by far the greatest tool that closed the gap between the tech and how the designer wanted to create the entities. It enabled the artistic feel of the movement of the characters and eased the development of content.
We have chosen to not use our own engine any time soon. We will continue making stylish games that focus on new types of gameplay, but will heavily reduce development time by using third-party tools and make our process more streamlined.
The team is currently busy making their next game Degrees of Separation. It will have some of the same design aesthetics as Amphora, but less experiential, as the concept this time is based on a working prototype. Amphora is available on Steam, Humble Store and Glyph and will soon be available on Mac.
Comments
