Developers of The Flame in the Flood have talked about their newly released game The Flame in the Flood, which features some amazing art, great music and unprecedented level of rendomness.
The Flame in the Flood is a recently released roguelike game, developed by a small indie team The Molasses Flood. This company was formed by some former developers form Irrational Games, who were working on the latest Bioshock Infinite. In the interview with 80.lv the developers talked about the production of the game and the main challenges of the game development.
About The Molasses Flood
We decided to group up and work on z something after the downsizing of Irrational, where most of us worked on Bioshock Infinite. Prior to this studio, we all mostly worked on large scale triple A games like Bioshock and Halo. We pretty much found ourselves without jobs in a town where no one was hiring, so we decided the time was right to start our own thing.
About The Flame in the Flood
the-flame-in-the-flood-80lv-interview-_5
The game itself is a survival rogue-lite, in which you travel a procedurally generated river by raft while attempting to survive a harsh wilderness. It has an original soundtrack written by Chuck Ragan and features a bunch of musicians with whom he regularly performs. The gameplay is inspired by real world survival, so the threats are natural and based on things you’d actually encounter in the wilderness.
As far as our inspirations, we’ve looked at a lot of media outside of games. Our biggest two references were probably Beast of the Southen Wild, and Alone in the Wilderness. The latter is an older documentary about a man who went into the Alaskan wilderness and ended up staying for decades. We also pull inspiration in bits and pieces from a ton of other sources, far too many to even name or remember.
The Flame in the Flood is currently available for PC and Mac on Steam Early Access, and will be coming as a console exclusive to Xbox One, although we don’t yet have a date for it to announce yet. Keep an eye on our twitter and facebook pages, as we’ll be making a lot of noise once we’ve got a date and approach our final release.
Finding the Gameplay Balance
the-flame-in-the-flood-80lv-interview-_2
The vision for the game has drifted a little bit, but has remained very consistent with our initial vision, much more so than anything I’ve worked on before. Balancing river and explore time has really been a season to taste type approach. We just have a bunch of numbers we can fiddle with that control how often you’ll see a dock, how wide the river is, that sort of thing. Once we got all that in place, we just started fiddling until it felt like a nice balance. We did some very early prototyping, really rough mock ups of small areas that didn’t include procedural generation, but they were all very rapid, done in a day or two. We didn’t spend a long time making sophisticated art tests or anything, just rough sketches that we took into production.
Working With the Community
photo-original (2)
Now that we’re in early access, we’re getting even more attention and feedback. Initially, everyone loves the art and music. Those draw people in. Once we went into early access we did get a number of people talking about the difficulty, specifically the ramp up from when you start. I think the game we initially launched is good once you understand the systems, but it feels too rough early on.
We’ve mostly been getting feedback from our Steam discussions and watching streams at this point. As far as implementing features, some people have called out and we’re already preparing to deploy them, others we may identify as something that needs to be addressed, but maybe not in the way suggested. We just look at what people say, and it either becomes a bug or a task in our database, or we collate similar issues into a bucket of items we need to discuss.
Randomness in Gameplay
the-flame-in-the-flood-80lv-interview-_3
To make the game, we use a mix of hand created and programmatically assembled pieces. The river is made up of a bunch of small building blocks, and the code assembles it based on the biome and a bunch of rules governing things like how much it can curve at any point, and how close any one shore can be to another. The explore locations are similar. There are essentially blank pieces of terrain, and any combination of decorative pieces can appear on it, depending on the location.
Level Design
the-flame-in-the-flood-80lv-interview-_1
The biggest principle for exploration and on foot spaces in Flame in the Flood is that we want to really constrain the scope of each one. With randomly generated spaces, landmarking and navigation can become confusing pretty easily, and we have a pretty tight camera, so we try to keep the spaces small enough that you can quickly learn them. We want players to be able to learn the problem space pretty quickly, so they can make informed decisions about what to grab, leave, and avoid.
About Unreal Engine 4 & Blueprints
We’ve found the Unreal Engine to be extremely powerful for what we need to do. I wouldn’t say it makes it easy, since I don’t think making a game is ever easy, but it is powerful. We’ve used the Blueprint system for prototyping extensively, and are shipping a ton of gameplay that exists entirely in Blueprint. We only end up moving things to code when we hit a level of complexity where it seems like maintaining the Blueprints will become too cumbersome. One of the biggest advantages is that it has allowed a non-programming designer to work out a lot of simpler gameplay systems while the engineers focused on the big complicated problems, like generating the river.
I think the 5% revenue share is very reasonable. The way I look at it for us is that we’re a small team, and we’re all company founders. We will share in the revenue the game makes. Epic wants 5%, so to me, that means a smaller share than any of us, and what they provide is a baseline of technology that far exceeds that percent. To put it another way, we could never get a programmer to provide us with something similar for 5% of the revenue, so it seems very fair to me.
Middleware Tools
As far as other tools, we use a mix of Maya and 3DS Max. It’s really up to the specific artist. All our rigging and animation is in Maya, since that’s what Gwen, our animator, uses. The world objects are all built in Max, since that’s what Sinc, our Art Director, uses. Outside of that, we use the Adobe suite to tools for all our texture work and UI. We keep things simple and hand painted from a shader and texture perspective, so we’ve not felt the need to use more sophisticated shader tools like Substance Designer.
Biggest Problems in The Development
the-flame-in-the-flood-80lv-interview-_4
I don’t think we’ve hit a lot of very difficult or unpredictable situations along the course of development, but we’re also coming at the project from a position of experience. We’ve all been working on games for a decade or more, so we’ve kind of seen a lot of problems and know how to cope with them.
I don’t think it ever occurred to us to quit the game, although maybe that would be different if our Kickstarter hadn’t succeeded. I think if you work in games long enough, you hit a point where no problem seems unsolvable, and you tend to approach things from that point of view. I think the key to viewing any problem as solvable is to remain flexible when it comes to solutions.
Maybe you need to cut a beloved feature, but if the game never ships that feature won’t matter anyway. For younger folks just starting out, the best advice I can give is that the greatest lessons learned are to be found in actually shipping a game. You may not have a hit, but every time you bring something to completion, you learn a little more about what it takes, and that’s the key to actually finishing something.
The Competition on the Indie Market
I think visibility is one of the biggest problems facing indies, definitely. I honestly have no idea what the answer is, as in some ways it’s human nature to want to take part in groups, so if something is successful, it will breed more success.
Breaking through that can be hard, particularly when so many things are releasing constantly. I suspect that the number of games being created is exceeding the number of people who are willing to purchase them, which will lead to a lot of problems for developers trying to make a living on their games. I really don’t know what the solution for this is, all I know is that it’s something we’re fighting ourselves.