Category: News

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

---

For the past 2 years, I have been working on a little game called Skirmish Line, inspired by the classic flash game: Mud and Blood 2. This is my first commercial title and my first foray into the indie games scene as a mostly solo developer. I wanted to take the time to write down my thoughts while they are still fresh, and I hope these notes will help other aspiring developers.

Before I begin, I should say that I’m not very keen on the idea that you will be successful by simply avoiding mistakes. Very often, I find making mistakes is what lets us grow. So rather than labeling failures in the project as mistakes, I will call them observations. They are things you should look out for and think about but are sometimes unavoidable. Live and learn. Don’t be afraid to dive into something and experience it yourself.

I graduated from college in 2015 with twin degrees in Economics and Applied Mathematics. For most of my college career, I was preparing myself for graduate school in Economics, having developed an interest in the field. But during my final year of college, I changed my mind. While my primary focus had been to get into graduate school and conduct research, I was also a modder on the side, working on the now defunct persistency mod for Company of Heroes, Operation Market Garden (OMGMod), as a designer and balancer. We had just released a major update for the mod, and one of my fellow modder suggested we try making games for a living. In truth, I felt a much greater sense of accomplishment working on OMGMod than I ever did with any research paper or regression analysis.

So I gave in to the siren song of gamedev and formed a small team with my modding friend, and he brought on a few of his friends. Our first and only project was Rocketman, a mobile Unity game about directing the eponymous hero, Rocketman, into space while evading asteroids and other obstacles. There were 5 of us, and I was responsible for the game’s UI while sound effects, art, and programming was handled by the other four. This project did not go well.

There were probably a lot of reasons why Rocketman failed. For starters, we had no version control, which meant it was a huge pain whenever we merged our project builds. Ideas were discussed, agreed upon, but never implemented. But more importantly, the motivation for the project petered out after a couple of months. We talked less and less about the project until it became clear to me that it was going nowhere.

Starting Over Again

I was determined and very stubborn, so I wanted to give game development another shot. So after ranting about the project to a friend, who was a freelancer programmer, and he suggested to me that we tried working on a game together. I had the idea of making a mobile version of the popular flash game, Mud and Blood 2, and this would later become Skirmish Line. My friend built a working prototype, and we contracted Clark, the artist who worked on Rocketman.

I would love to say that the project went off without a hitch. But even at the start, there were problems. My friend was an experienced programmer, having worked on e-commerce websites and other projects for a living, and I had a semester of Java programming, along with some high level programming for various software suites like Matlab or Stata. We had a sort of verbal agreement that I would serve primarily as the designer and handle the UI while he focused on the programming. As with most projects, the initial stages are very heavy on the programming, and my friend felt that I wasn’t doing my fair share of the work and pushed me to try some of the programming. So I wrote a few classes and methods, at a painfully slow rate, encountering basic errors such as null reference errors, which I simply did not understand at the time.

Observation #1

When partnering up in small teams, try to have either similar skill levels when working in the same field, e.g. be about as competent a programmer as the other programmers, or have a demonstrable skill the other partner does not have, such as programming vs art. In this particular case, my strength was in designing and balancing a game, which isn’t something that is really demonstrable until a project matures. Dedicated designers are really a luxury of big studios, where multiple projects can be run, allowing designers to be busy while the core programming is done on a newer project.

After a few weeks, I began modifying existing code, which triggered a second conflict with my partner. Most programmers have their own idea of organization and ideas for the codebase. So when you have multiple programmers, ideas will start clashing. My partner was not happy about the modification of his code but kept quiet about it until I brought the subject up.

Observation #2

Establish common ground for how to handle the code base. Style is important, and coders can be very protective of their work. Spend some time before you begin coding in earnest to establish procedures.

After our disputes over modifying code, I avoided touching code written by my partner. Rather, I would either ask my partner to do the modifications or reference written notes. Compounding this inefficiency was the implementation of features or mechanics that were not agreed on or discussed. The truth is, the programmer dictates what actually goes into a project. And my partner had begun implementing things we didn’t discuss. Eventually this sparkled another disagreement, as the project’s design began diverging.

Observation #3

Programming is an integral part of a game’s design. In theory, you can separate the ideas, but in practice, the way code is structured is a hard constraint on design. It is my personal belief that you cannot realistically have a programmer not be a designer. 

After a little less than 2 months of development, my partner stopping working on the project to continue work on his personal project, unrelated to game development. Taking a brief aside, it’s worth discussing that game development involves people, and people have eccentricities. For instance, my partner on the project insists on using an encryption program whenever we pass potentially sensitive information. This meant every time we wanted to share certain info, such as our address or bank account numbers over Steam, we would need to write the information down, encrypt it, send the key over, then decrypt it, a process I felt was unnecessary but I had nonetheless agreed to do. But by far, the biggest issue was my partner’s habit of avoiding confrontation. In every disagreement we have had up to this point, my partner’s response to a disagreement had been to be quiet about it or to ostensibly agree, only to disagree later. This was a reoccurring issue over the course of the project. The sudden break was my partner’s response to the culmination of disagreements we have had, although he would not confirm it until 3 months later.

Over these 3 months, I would continue development on my own, implementing features while learning C# and Unity. During this period, I developed my core understanding for syntax and how to navigate through Unity.

Observation #4

Do not be afraid of learning how to program. It takes time and a lot of effort, but it is a skill like any other. There are plenty of resources online that can help.

My partner returned mid-April. During this period we discussed the issues we had before: the differences in programming skill, the disagreements on designing the game, and his sudden and extended absence. At this point, my partner was heavily invested on his personal project and wanted to concentrate on that. He agreed to work on the project nonetheless, asking me to reserve certain tasks for him. After about a week of work, he disappeared again then returned for another week of work at the onset of June, before leaving the project for another 4 months until October. We kept limited communication during this period, as we researched and prepared the paperwork for a company.

We officially formed a LLC in late August of 2016. Up to this point, I had been financing the project out of my own pockets, with the promise that my partner would provide his share of the capital, something I overlooked as we had been operating on a shoestring budget for the game. After the formation of the company, my partner contributed about 75% of his share of the capital (to match my contributions to date), again with the promise that he would pay the remaining 25% later. He also insisted that I no longer add any more money onto the project, as that would require him to contribute more to maintain our equal capital contributions later on, and he had no desires to put anymore money into the company.

We had a couple of major disagreements over where to take the project. My partner wanted to release the game on mobile devices while I felt it was more prudent to attempt a release on PC/Mac/Linux first. My partner also wanted to release the game as soon as possible, while releasing subsequent versions later after assessing marketability and gauging feedback. Again, I disagreed, as I felt that it would be poor business practice and that a string of poor releases would damage the potential marketability of the game in the future. I felt that we could lead up to proper full release by getting feedback through smaller distribution platforms such as gamejolt or itch.io.

In both of our initial discussions on these subject matters, my partner had ostensibly agreed to my positions. After months without touching the project itself, I asked my partner to contribute to the codebase once more, as the project was being bottlenecked by tasks assigned to him. At this point, my partner unveiled his true opinion on the project, his frustrations over the business plan and our earlier disagreements over the design of the game. I offered a buyout for his share of the company, offering to cover his capital contribution, along with a premium for his work. My partner refused the offer, instead we attempted once again to talk through our issues.

It is the start of October 2016 by this point. My partner worked again for a few days, before returning to his personal project. He would not return to working on the project until late December. At this point, there was a clear pattern. Roughly a week of work followed by months of absence. My partner did not care for the project, but he did not want to part with the idea of the company either. I was getting burned out on the project myself, partly from having worked on the project for nearly a year and from the disagreements with my partner.

Between December 2016 and January 2017, my partner paid the remaining 25% of the capital contribution and worked again for a little less than 2 weeks. At this point, I wanted to share a working alpha of the game with the Mud and Blood community. This was a very anxious period for me, as I was afraid that the community would respond negatively to our game. We discussed possibly avoiding the community altogether, but ultimately I felt that it was better to approach the community itself than to let them approach us. In truth, I don’t know what my partner’s opinion on the matter was at this point. While he seemed to agree, I could no longer trust his opinion, as it seemed so inconsistent.

Sharing the game was the single best decision we ever made. The community was very responsive and provided us with a very motivated group of playtesters. For the next few months, from mid-January until July, I was the most productive I had ever been with the project. By this point, I had a decent understanding of how to program, and the constant feedback was integral to the game’s development. During these 7 months, I also made the decision to do my partner’s share of the work, as he was absent for its development during this entire period, and I felt that I could no longer wait on his behalf.

Observation #5

Player feedback is absolutely vital. This is what truly dictates the path of development. Design documents can only get you so far. In addition, there is a huge motivational factor when you watch people play your games.

By February, I ran into another problem: the bank account was nearing empty. Development had expended nearly the entire $5000 in capital we had set aside. As my partner had stated that he would no longer contribute any money back in August of 2016, I was unable to raise another round of funding. At this point, I made the decision to finance the rest of the project on my own. The plan was to put in additional contributions but to continue to treat royalty payments as a 50/50 split later on.

At some point during March, I was confiding to a friend about the situation in the company. About a week later, my partner found out through our mutual friend. The secret was out, and my partner was not happy. Yet, he could not be mad either, as he was going to get his split of the revenue regardless, only that he felt it was a betrayal of trust. He stipulated that I no longer add funds to the company account, and that future development would depend on incoming revenue.

By July, I had become very unhappy with the way the company was proceeding. With dwindling funds and an inability to add more, I made the choice to offer another buyout offer. My partner was very resistant to the idea, demanding a premium of $5000 plus a reimbursement of his capital contribution, amounting to $7300, of which I was willing to pay at the time. Nonetheless, my partner asked me to reconsider, and I reluctantly agreed. In return, he would match the contributions I had put in since, another $1100, which helped funded us through the rest of the summer.

For the first time in 2017 since January, my partner worked on the project again, for about 3 weeks, from late July to mid-August. Our plan was to release the game in Steam Early Access during the summer, before the rush of triple A game releases in the fall. Here, we disagreed again where to release the game. My partner was afraid of pirating and did not want to release on DRM-free platforms such as itch.io, where the executable can simply be repackaged and downloaded. I took the stance that pirating was impossible to stop, and that we were limiting our potential market. But I nonetheless agreed to release on Steam only.

Content development slowed during the summer, as we had very limited funds to add new content. We concentrated our efforts to getting the game ready for Steam, adding key bindings, Steam achievements, and fixing bugs. We also made the decision to stop releasing public alphas to the Mud and Blood community, as there was a fear that people would simply download the free alpha available instead of buying the game.

I eventually found out that Unity games did not abid by Steam DRM. Yet my partner was insistent on releasing on Steam only, citing a custom built DRM system that would at least require Steam to be online before the game would launch, and that he would implement this system himself. To this date, this custom DRM has not been implemented.

Preparing the Steam store page took longer than expected. Our greatest setback was the lack of a trailer. After checking with various trailer makers, none were within our budget. We ultimately settled on having a friend of mine, a former shoutcaster for OMGMod, produce a trailer for us. Unfortunately, this delayed our release until late October.

Observation #6

Your trailer on the Steam store page is the single most important element when it comes to marketability by a massive margin. For the vast, vast majority of customers, this is what determines if they will buy your game or not.

We spent about a month sitting on the Coming Soon list on Steam. During this time, we accumulated a little over 1000 wishlist additions. We understood that the initial release window is typically the single most important date for a game. We wanted to get as many sales and reviews as possible, in order to boost us up on the Top Sellers list. While the timing was unfortunate, given that fall through winter are some of the worst months for releasing an indie game, we simply did not have the money to continue development.

Observation #7

Having a proper Steam store page up, including a very good trailer and clear descriptions of everything, can build up a decent following. It is essentially free exposure. On the other hand, you can lose potential customers if your store page is bad, as certain users may simply tag your game as “Not Interested.”

Skirmish Line released on October 17 on Steam Early Access to a spectacularly underwhelming reception. We never made it to Top Sellers list, although I had already expected this to be the case. The game was not ready in my opinion. We needed more time, more money, and more exposure.

Of our 5 user reviews during October, 3 were positive and 2 were negative. While this wasn’t shovelware reviews type bad, it wasn’t good either, not for something I’ve spent so much time and energy on. Particularly demanding was this review, which has since amounted to 176 thumbs up and remains the most helpful review on Steam:

I spent the next few weeks working to address the problems with the game. In particular, the game became too easy after a recent round of untested changes. As we had no playtesting since the summer, various bugs and issues came up. In retrospect, we should have continued to work with the Mud and Blood community. The decision to simply tease what little content we could afford to entice community members to purchase the game ultimately had no noticeable effects on getting Skirmish Line on the Top Sellers list.

Observation #8

Playtest every change. Games are complex systems, where a few variables can completely change the gameplay and feel of the experience. Accumulated changes without playtesting can result in dramatically different playing experiences than intended.

By the end of November, I was able to convince my partner to use the revenue from sales from October to finance further development. In particular, we had reserved $800 for an annual LLC fee, and I was able to convince him that the revenue over the next few months would cover the fee when it became due. Although my partner had initially wanted to recoup the capital contribution first before any further development, we agreed on a system where I would estimate the price of the next content patch before ordering them from our artist, Clark. We were able to keep costs low through clever re-use of existing assets, which allowed my artists to produce new content by remixing old sprites with new ones. Thanks to our working relationship, Clark was also willing to accept payments later than would be accepted by many other contractors.

Observation #9

Working closely with the same contractor can be beneficial. In addition to building up trust, you can develop a very efficient pipeline for getting assets out.

It has been roughly 5 months since Skirmish Line’s Early Access release. In that time, the reviews have improved from 3 positive and 2 negative reviews to 21 positive and 3 negative reviews, sitting at a comfortable 87%.

I don’t quite know how Steam’s algorithms work, but I speculate that if a game gets below a certain amount of user reviews, it gets buried with the so called “fake games.” In this metric, I think Skirmish Line has passed, which was the bare minimum bar I had hoped to achieve.

My partner has not worked on the game since August 2017 and has agreed to a new buyout offer of $9200. Taking into account all the revenue earned, this would have me at a net loss of roughly $3400, which combined with the required annual LLC fee of 2017, would amount to a net loss of $4200. I am hoping the revenue over the next few months will pay off this loss while funding development.

Observation #10

Choose your team members and partners very carefully when it comes to developing a game. This is a decision can stick for months and years.

I seldom talk to my partner anymore, and our friendship has suffered for it. The total development cost of the game has reached about $8000, a relatively low cost of production, given that $1600 were paid for California LLC alone. My partner has made a profit of $5700 from the buyout offer.

I’d like to leave some positive notes.

Working on a shoe string budget gives you a real constraint to work against. While I felt that a hard budget constraint hurt Skirmish Line’s Early Access release overall, it nonetheless encouraged finding ways to cut down on expenses.

You will learn so many skills as a solo or mostly solo indie developer. In addition to programming, I directed the voice acting for the game, made countless image edits to get things just right, acted as a community manager, wrote articles on the wiki, and just improved my ability to learn new things overall.

While admittedly I have become reluctant to work on collaborations since, I am very fortunate to have worked with other very awesome people. Clark is a fantastic artist and conducts his work in a very professional manner. The voice actors I worked were super enthusiastic. And for all the loyal fans of Skirmish Line, I thank each and everyone for their bug reports, wiki contributions, localization efforts, and encouraging words.

Originally, I had intended to provide more details about Skirmish Line, but the merits and faults of the game deserves its own post, which I shall leave for a proper post-mortem.

“I have had such a superb time creating this project. I can barely sleep. I get up early and can’t wait to put new things into the game. I love making games and that is almost all I do now.”

David Brevik, creator of Diablo and Diablo II, has been away for games for some time due to his work as CEO of Gazillion Entertainment — work that came to an end in 2016 when he left the company.

“After I left being the CEO at Gazillion I knew I wanted to get back to making the games,” Brevik says. “When you are the boss of a company with 100+ people you don’t have time to make games, instead you run a company and can give some feedback on the products. It was important to me to get my hands dirty again and start making a product. That is my passion.”

The developer has returned to his Stygian action-RPG roots with It Lurks Below, a survival game that draws from his past works with Diablo, but also draws from many different elements that allow the developer to head into some uncharted territory for himself. All alone, as well, as Brevik (operating under the name of Graybeard Games) has decided to tackle the entire game solo, putting years of development experience to work in crafting something for himself after years of guiding a company to do it.

“Being the sole developer on a project has been a very unique experience,” says Brevik. “I didn’t really set out to be the sole developer. I thought I would make a small (five-ish) person team to make a game, but in the end, I decided to push my limits and try doing it all.”

Diab-Below

It Lurks Below is Brevik’s new project, drawing from some interesting elements the developer has seen in survival games, games that feature random generation, and horror as well, mixing discovery and a personal touch that makes the game the player’s own. Brevik is mixing and mingling all these influences with his past experience creating games like Diablo.

“I didn’t really set out to be the sole developer…but in the end, I decided to push my limits and try doing it all.”

Players are tasked with creating their own character from several different classes, then setting out to dig their way down to a colossal, sprawling dungeon, battling through its randomly-generated halls using randomly-generated tools, striving to survive and thrive despite the difficult odds. If players wish to live long in this world, they may also wish to make a few return trips to their base to regroup and fashion some helpful things that will help them return to fight refreshed and rearmed.

These survival elements mark new territory for Brevik, and were part of what the developer really wanted in his new project.

“I think the thing that drew me in the most was the play experiences I had while playing other survival games like Don’t Starve, Rim World, and Terraria,” Brevik says. “I really enjoyed trying to create a base, growing food, and in some cases, building a community. When I started thinking about creating a new game, I knew that I wanted to take a lot of my previous experience and add something new and interesting to it, so crossing it with these survival aspects seemed like a fun fit.”

These elements turned out to be a comfortable fit with the developer’s love of the RPG loop he’d used with Diablo.

“After getting the prototype working, I put in some of the new survival mechanics to my well-established RPG loop I’ve used many times and it worked even better than I thought it would,” says Brevik. “I think that breaking up the action with a return to your base and taking the time to farm, harvest, and do other activities is an important respite to the constant exploration and action of the netherworld. It creates a unique balance that has a relaxing, soothing effect on the game.”

Diablo’s horror-inspired mood, with its gloomy world and dungeons filled with frightening monsters, would also be reflected in the developer’s new work.

“The ambient sound is creepy. The monster grunts and calls are scary. It is dark, and you can’t see. These are all done on purpose. I love horror. I watch horror movies, play horror games and I’m most captivated when a game has that unsettling feeling,” says Brevik.

“What makes a game interesting to me is when the monsters are in the dark. When they come out of that dark spot and surprise you.”

“What makes a game interesting to me is when the monsters are in the dark. When they come out of that dark spot and surprise you. When you can’t see what you are up against until it is right upon you. It is important to me to have a horror element because the monsters and your overall task should be scary. This is a terrifying adventure you are on and you are up against demons. It isn’t meant to be a light-hearted romp through grassy fields.”

It’s especially interesting to see how Brevik is building upon the character class system in It Lurks Below, drawing from his wealth of experience within the action-RPG genre. 

“The way the classes work is a bit of a cross between several different games I’ve worked on in the past,” Brevik explains. “First, your skills are items that you can activate or use. I call them ancient items. When you choose a class, you are given one of these ancient items every five levels through level 25 (5 total). Each one of these items has an upgrade feature that allows the skill to become more powerful. You are given points when you level up to increase the rank of these ancient items. This is like Diablo II in that you have points to spend in your skill tree, but in this case, you use the points to upgrade items.” 

Devs should note that Brevik seems to prize flexibility within this class structure, going so far as to design special items which can give players access to skills outside their chosen class. 

“It is a bit like the original Diablo in that these ancient items can be found in the game and can come from any class,” he explains. “This allows you to create a hybrid class using different skills from other classes. But with limited skill points, there are only a few of these items that you can max out, so you need to choose wisely. Because of this strange system, it will be very difficult to refund skill points and it will also be difficult to guarantee a specific build because sometimes you might find a great item for your kit and sometimes you won’t. I may change this system before the game is done, but it is how it works currently.” 

The bottomless appeal of random caverns

Brevik is also building upon the Diablo formula and hoping to create something wholly new with It Lurks Below, through the use of random generation for everything within the game. Players can never know what items or locations they will come across in their journey, creating a new game for the player each time they choose to march through the game’s creepy caves.

“I’ve designed the game so that there are many ways to play; from different classes to a randomly generated world and items to skills that are found,” says Brevik. “This encourages people to play over and over and to keep it fresh, having a randomly generated experience is the best way to go. There are surprises around every corner and it is different each time I play. It creates incredible replayability and new challenges each time you start. If you enjoy the game, it will be incredible value because you can play hundreds of hours.” 

Making this into a compelling experience will always be a challenge, according to the developer, but it’s one he’s been working to overcome (and enjoying doing so along the way). “You can create interesting experiences out of randomly generated levels, but they won’t be as interesting as hand-crafted experiences. However, it is much more entertaining to me to have new experiences each time you play instead of the same experience over and over.” says Brevik.

“I’ve always enjoyed making randomly generated worlds and items and this seemed like a fun new challenge.” he continues. “I had not done much random level generation from the side instead of top-down. I knew that I wanted to create organic cave-like structures and I ended up doing quite a bit of research on how others have achieved that look in the past.”

“Random elements have always been important to me because it creates a unique experience that is mine. It makes the game feel like something that no one else will experience in the same way.”

Making that cave-like structure was only a part of what Brevik wished to do with the game, creating a believable base upon which he could iterate to find a satisfying world. “Once I got the look of the cave-like structure going, it took several iterations to make it play well and after about six months I think I finally achieved it.”

“At first, I just created a tunnel from the surface down to a dungeon below the surface. The dungeon wrapped back and forth and ended with a boss room. In the end, it wasn’t that exciting because there was no sense of discovery,” says Brevik.

“Once I removed the tunnel and made you discover the dungeon by digging down, it became a lot more interesting. That said, there were lots of empty sections and it wasn’t very fun just exploring and digging down. Finally, I put in random themed rooms into the layer between the dungeon and the surface and it really became fun. Putting in interesting rooms to find, explore, and interact with made all the difference.” 

Upon creating a solid feel for his cave system, it took some time before Brevik had that feeling of discovery in place in his dungeons, keeping them from feeling about lines of linear corridors that all fed into a boss room. This would keep the game from feeling predictable in its generation, preserving that sense of always exploring new places and finding new surprises while wandering these places.

This builds upon the randomness of the items to create a whole new experience each time the player wanders through It Lurks Below, which was important for the developer to preserve. It has always been a passion for Brevik, as it conveys a sense of ownership on the adventure. It’s your story in your world using your character, creating a connection between the player and game that linear, specifically-designed games cannot always capture to the same extent.

“Random elements have always been important to me because it creates a unique experience that is mine,” he says. It makes the game feel like something that no one else will experience in the same way. The game becomes personal. This is my experience and no one else will have this same experience.”

“This is the sort of game that I make, and I love doing it”

It Lurks Below offers a chance for Brevik to explore his old development styles as well as some fun new territory, allowing him to get his hands dirty with code again, something he clearly relishes at the moment.

“It does build upon my earlier work in many ways,” acknowledges Brevik. “It is a cross between something new and something familiar. I am still using random item generation, random works, creepy atmosphere, and many other elements. That is because that is what interests me as a game player and as a developer. This is what I love to explore and build my fantasy worlds from.” 

And it’s not all sickly sunshine and wilted roses, to be working alone on this dark dungeon-crawler after being on teams or in control of huge studios. Brevik says it can be lonely work, though his enthusiasm for the project keeps him going.

“At first, I found it incredibly lonely. I was used to making games with a big team. It was strange not to work with other to make something new and wonderful or bounce ideas off each other,” he says. “I still miss that some days, but as the project starts to blossom, I was so genuinely happy and excited that I looked forward to creating every day. I was having too much fun to be lonely.”

Random elements have always been important to me because it creates a unique experience that is mine. It makes the game feel like something that no one else will experience in the same way.

“I think the hardest part was not getting any feedback from people. I’m at home in my office making a game all by myself for a year and it’s hard to tell what you have. Am I crazy? Is this any good? Am I making a huge mistake?”

It can also be difficult to go forward without having another developer or co-worker to bounce ideas off of, something other solo devs may appreciate all too well.

“I think the hardest part was not getting any feedback from people. I’m at home in my office making a game all by myself for a year and it’s hard to tell what you have,” Brevik says. “Am I crazy? Is this any good? Am I making a huge mistake? I’ve always believed in my talent, but you enter periods of self-doubt. You think: ‘People want to play games from someone who makes great games. I don’t make great games. I can’t do this by myself!’ It was such a relief to see the positive initial reaction to the product. It can silence many of those doubts. Well… most of them anyhow.”

While Brevik may endure doubts and loneliness at points, the ability to create a familiar game while also building on it in new ways that change the shape of the games he loves to create, can invigorate and excite Brevik, keeping him going as he prepares to take players into menacing dungeons filled with demonic beasts once more.

“I guess it is similar to being a writer. Most writers stick to a genre or style of book that they write. Some authors write fantasy or romance or mystery, but rarely do they write a wide-variety. They become known for a style of book,” concludes Brevik. 

“For me, I am an action-RPG developer. This is the sort of game that I make, and I love doing it.”

Epic Games’ Fortnite has had one hell of a year.

2017 saw Fortnite rise from hidden gem to household name, as popular among celebrities and sports stars as it is in playerbase numbers. This February it reached a staggering 3.4 million concurrent users, beating out genre trendsetter PlayerUnknown’s Battlegrounds for the first time in series history.

After a lukewarm reception to the game’s original, cooperative survival mode, last March saw the first playable release of Fortnite: Battle Royale, a player-vs-player deathmatch survival game. One hundred players drop from the Battle Bus onto a lush, vibrant island of rolling hills, sandy beaches, and tight clusters of buildings dotted throughout the map to battle it out for last person standing.

Inextricable from Fortnite’s popularity is its unique building mechanics. Everything destructible in Fortnite: Battle Royale drops materials, which can be crafted on-the-fly into walls, floors, and staircases. In pitched gunfights, players can throw up hasty constructions to act as impromptu cover, or elaborate towers and fortresses to wait out the tense endgame.

Both Battle Royale and the earlier, cooperative Save The World mode have not yet reached release, but are both available to play in early access using Epic’s launcher as development continues. Recently, Gamasutra sat down with Eric Williamson (Design Lead) and Zack Estep (Producer) to discuss how Fortnite: Battle Royale came to be what it is, and how the team brought it to life.

How did you arrive at the building blocks that went into Fortnite Battle Royale? Were there any assets or designs that you wanted to implement but didn’t, or couldn’t?

Eric Williamson: So there’s a couple parts of my answer for this. First and foremost, when we started Battle Royale, we had this tremendous starting place from the Save The World campaign that we could use as our sandbox to build on top of.

“We didn’t want it to feel like it was going to be a huge commitment when you hit the play button. We had to evaluate a lot of gameplay systems and other things under that lens to determine ‘does this make sense?'”

We wanted to create Battle Royale in a relatively quick timeframe. One of the things that we intentionally said upfront was that no one’s on the team’s allowed to say “what if”.

What we meant by that was that because our timeline was so short, and we wanted to create a playable version immediately, it wasn’t “hey we could do all these crazy things” it was “what can we do, and how can we get it done as quickly as possible.” It wasn’t pie-in-the-sky land. Naturally, that meant that lots of ideas we had didn’t really get fully explored.

As we continue to update and iterate on the game, we’re adding new items, new systems, new consumables, etc. Those are some of those ideas that we had way back of like, “hey what if we wanted to do something like that?”

You mentioned how you were building off of the base of the STW mode, and obviously you had something of a crunched timeline. What was the process of converting that into a battle royale mode, in a design sense?

Eric Williamson: Where Battle Royale is at now, there are a lot of decisions that appear deliberate or may seem obvious, but during the initial development period were still sort of questions. For example, the decision to go with a more natural flowing terrain is a little bit different than Save The World.

Our weapons and weapon tuning as well as the details of our weapons systems—some of that progression isn’t present in Battle Royale. There are a lot of traps that are available in Save The World, and we have a very small subsection of that. It was a deliberate but also time-constrained decision-making process of what we should do and what made the most sense.

Were there any things you were specifically looking for or avoiding when taking design assets into Battle Royale?

Eric Williamson: One of the targets that we had very early on was that matches needed to be a reasonable duration: 18-25 minutes or somewhere in that ballpark. We didn’t want it to feel like it was going to be a huge commitment when you hit the play button. We had to evaluate a lot of gameplay systems and other things under that lens to determine “does this make sense?”

For example, Save The World has a crafting system that allows you to create things. We considered some parts of that early on, but we felt like if the matches were going to be relatively short, how much time did you want to spend crafting something, rather than scavenging and finding things and engaging in combat?

We had to be very selective about what types of gameplay that fit in a longer experience that Save The World provides, but doesn’t fit in a shorter and more digestible match that Battle Royale provides.

Zack Estep: One of the tenets we had were to make sure stuff was very relatable, across the board. Everything should make sense when you pick it up, or when you utilize it, or through exploring the world. We didn’t want anything that required several sessions of you experiencing that thing before you could mentally grasp it.

It was a lot of easily mentally-mappable content like that—easy to pick up, harder to master.

Fortnite is a huge game on Twitch, and people are talking about competitive Battle Royale. Was that a part of your design process or were you more focused on casual players?

Eric Williamson: It’s a silly thing to say, but we were so focused on fun and making the experience enjoyable above all else that those are kind of happy accidents along the way. It’s great we have that exposure on Twitch and that people are picking up the game as they are, but the core for us was focusing on the fun, and making sure it puts a smile on your face.

In comparison to other BR games, Fortnite is the most prominent with a building element. In your design process, did you think that building would change a player’s approach to the game?

Eric Williamson: Very early on in our prototypes it was really a little unclear how players would use building. In our internal playtests, players felt initially like “why would I build a base if the storm’s going to close in and I can’t use it?”

Over time that’s evolved into “I can build cover very quickly,” or “I can build a base very quickly” and it’s considered a throwaway base—when you’re done with it you move on, you go to the next place.

“Being able to build as a player means that combat isn’t just a couple shots…it’s this conversation that occurs over sometimes even a couple minutes.”

We certainly hoped that building would be a core component of the mode, but until we were in the first month or two of being in early access, we weren’t quite sure how that would evolve and if the top tier players would use it as much as we had hoped they would.

You watch some of these amazing videos of the best builders out there, and you see the dialogue or conversation that they have when they’re fighting somebody else. The strategy they use in how to approach that engagement is really incredible.

Being able to build as a player means that combat isn’t just a couple shots and someone’s dead, it’s this conversation that occurs over sometimes even a couple minutes, and in some ways it’s like watching an artist try to paint with a building paintbrush. It’s really quite incredible to watch.

In a recent update you introduced an alternative style of building, the turbo building mode.

Eric Williamson: Yes, it allows players to build much faster by not requiring a separate click for each building piece.

Zack Estep: Yes, we enabled turbo building, auto material switch, and allowing you to build with less restrictions all with Season 3, that was all done recently.

Less restrictions?

Zack Estep: Previously you were put into a position where if there were obstructions in your way you first had to destroy them. Now with the same logic that you can build through hills and mountains, you can build through trees, rocks, and some other obstructions.

You cannot build through pre-existing structures, but we’ve rolled back some of the logic there for the building system.

Another thing announced recently was the 20-player team mode. After the fifty-on-fifty mode, what made you want to look into a smaller team?

Eric Williamson: We think that limited time modes are a really good way to keep things fresh. We’ve done a couple different limited-time modes so far—Fifty-vs-fifty was our first one, we’ve done a rocket launcher and grenade only mode, we did a sniper rifle mode, we did a stealth mode… it’s a real fun way to do something that isn’t permanent but it’s fun, and it keeps things fresh.

We saw this as a natural evolution from the fifty-vs-fifty to something you can organize a little bit more with other players. It doesn’t mean fifty-vs-fifty is gone (we’re still thinking on how we can iterate on fifty-vs-fifty and make it as good as possible) but there’s no reason not to have fifty-vs-fifty, teams of twenty, and potentially other things like that.

Do you think that’ll effectively change the meta of playing? Do you see a shift in meta when they’re playing in twenty-person teams rather than four-man squads?

Eric Williamson: Certainly, when you have a larger team there are more things that you can do. One of my favorite experiences in fifty-vs-fifty was hearing about someone who decided to be the medic, and all they did was carry around bandages and revive people and not engage in combat—that’s something that’s really cool and doesn’t occur (or is much less likely to occur) in squads. It’s really fun to see that sort of emergent behavior happen.