Development – MagicalTimeBean

A Case for Closed Development: Why I Stopped Blogging about Soulcaster

Seven months. It’s a good interval for a yes-I’m-still-alive-and-making-the-game post. TL;DR: Soulcaster is still happening, and I work on it every day.

So what happened to the dev blogging and tweeting? Why did I go off the radar?

It started (ended) when the game got its first non-placeholder art, and showing screens would reveal our first steps towards the new look of the game. Originally, it was a marketing strategy: wait until we have something dazzling to show before showing anything. This is the first project I have built while thinking about marketing, and it became increasingly unhealthy obsession that built up in the first half of this year. I analyzed new releases, picked apart Kickstarter videos, reached out to successful devs (who were universally, amazingly generous with their time and eagerness to help me). There had to be a secret to what “works” in this exciting and scary post-2012 landscape.

The more I learned, the more unclear things got. It was so frustrating. No pattern emerged–everyone found a unique path to success, sometimes completely stumbling into it. If there was a universal lesson to be learned, it’s that nobody knows what works these days, beyond what has worked for them at a particular time and place.

These were the decisions I woke up every morning thinking about:

Do a crowdfunding campaign, which gives us funding and publicity, or use those three months to get the game done sooner?
If we run a campaign, do we reveal the project a couple months ahead, to build towards a strong first day–or do we keep everything secret until the campaign starts, when we have something actionable for when the media pays attention?
Do we launch in early access, where we can get valuable feedback and start making income sooner, or is it too toxic of an environment to outweigh this benefit?
Does blogging and streaming help raise awareness enough to offset the time it takes up? What about the influence the public might have on the game’s design?

It seemed like every time I committed to one decision, some new piece of data would emerge that cast doubt on that plan of action. It was paralyzing. Bottom line, I spent most of this year simply not enjoying working on Soulcaster.

If I were going to see this project through, I had to change my mindset. Here’s how I see thing now:

Nobody knows what works, so I might as well pick what I am best at.

I took a break from my focus on what others might want to see, and spent time figuring out out what it is I do best, what I enjoy the most. What I’ve discovered is that I do my best work when I can focus on making the game I want to play. Wait until the bones have gelled and things are where I want them, when comments people make on the new look or new gameplay won’t make me second guess the game’s fundamentals. This means no dev blogging or streaming, for the time being. If we do a crowdfunding campaign, it won’t be planned until the game is out of this critical prototyping phase.

Going dark like this might be a little foolish, since it’s already easy enough to get lost in the sea of new indie games appearing every day. But it’s what I have to do. Since committing to zero public announcements for the time being, I’m writing the best code of my career. I’m coming up with some of my most creative game design ideas. I wake up in the morning excited to get started, and keep energy well into the afternoon, instead of losing steam around lunchtime. I’m enjoying game development again.

Because of this, I’m confident the new Soulcaster is going to be my masterwork, the game I was born to create. Weirdly, despite all this inward focus, it motivates me to think about sharing it with the world–but only when it’s reached the right point in development. I’m so excited for that day. I’ll see you then.

The Detours of Prototyping

You know, it’s really time for an update on Soulcaster. The longer it gets in between these things, the more I feel like I have to write a long treatise on everything that’s been going on since the last update. And yes–lots of stuff has been happening! But I can’t get to it all in one post. For now, I’ll just try to shed some light on where the project is, and what it’s gone through in the past few months.

My concept for Prototype #2 was to focus on the micro game of combat, and leave the exploration, upgrades, and other metagame stuff for later. So I set out to make a single-screen “waves of enemies” scenario, which gradually added more monsters to the scene after each level. I got it functional enough to show a few people, and quite honestly, nobody found it that interesting.

The reason is that I am missing a key component of what made the first Soulcasters fun and different: combining summon-based combat with exploration and dungeon crawling. The exploration element–moving from room to room, dealing with traps and ambushes as they come up–is just way more engaging than sitting in the same room, waiting for enemies to emerge from predictable places, over and over. It devolved into kind of a lame quasi-tower-defense experience.

It was also a bit too… institutionalized. Soulcaster should be about quick decision making amidst chaos–not, “Okay, are you ready for the next wave?? HEEERE they come!” which is what my prototype became.

Side note: Secret of Mana is one of my all time favorite games. I remember back in the day when I could finally play the only-available-in-Japan sequel, which had been fan translated for the emulator (shhh, don’t tell Square). Now, there’s no question that the graphics in Seiken Densetsu 3 obliterate those of its predecessor. But the gameplay just felt sterile. Each battle had a start and end, kind of like a turn-based RPG, and it defeated the purpose of action-adventure. I missed being given the option to run past enemies.

Without realizing it, I had kinda done the same thing to my game.

But that’s what prototyping is for: to try new things, see what works, and keep the good stuff. Even though the experimental new scenario didn’t work, there’s actually a lot of good stuff to keep:

A “windwalk” (phase boots?) ability for the summoner to escape when he gets pinned down. It lets you walk through enemies and become invisible to them. It’s also useful to slip into a new part of the room to begin setting up a “fallback” position
A mana meter that charges up as you slay enemies. I’m going for a Devil Trigger/Rage of the Gods type of mechanic with this one. There are a lot of potential uses, like powering up an existing summon, doing some sort of ultimate summon form
Procedural generation of monster populations. I can have the room use a “budget” for monsters and pick a theme for them, and it divides them into waves and places them appropriately
When you destroy a monster spawner, it tosses shards of debris into the air, which spin and bounce when they hits the ground (this is important)
Housekeeping code revolving around keeping an inventory between rooms, starting a new game, gaining new powerups, etc. It’s not exciting to read about, and even worse to code, but it’s just one of those things that makes it feel like “a game”

So for Prototype #3, I really am aiming for a sparse, functional version of how I envision the full game: interconnected rooms, wandering monsters, traps and ambushes, obtaining items, deciding when to retreat or avoid an encounter. There are lots of unanswered questions about item and character progression, and I think it’s best to address those once the nuts and bolts are all there. Start at the ground level and work our way up.

Procedural Room Generation Explained

There are lots of ways to do procedural dungeon generation. I came up with a way that will allow for both really chaotic room designs and fully formed, hand crafted rooms. It’s based on joining smaller patterns together to form the room’s interior. In this post, I’ll do my best to explain what’s going on.

Setup: Defining Patterns

This is a collection of four small primitive patterns, bound in separate colored boxes.

I use the editor to make this room, which contains four basic structures, the patterns. Everything is composed of simple tiles like walls, columns, floor, and water. Metadata in the room file marks specific tiles to define the pattern area (colored box enclosing the pattern) and two special types of tiles: the inlink and outlink positions. Each pattern has one inlink, shown with an E (for entrance), and one or more outlinks (empty colored squares). These are used to join patterns logically, which I’ll explain later.

For now, let’s walk through each step of the layout algorithm.

1. Create an Empty, Enclosed Room

The blue tiles are empty spaces--I know, it reminds me of Super Mario World too. — The blue tiles are empty spaces–I know, it reminds me of Super Mario World too.

Rooms can be any size–I’m using 31×17 as the default size for now. Each room is enclosed by the basic wall tile. (Walls are automatically blended to their neighbors in a separate algorithm.)

2. Place doorways at the door positions.

The top doorway has a cute little doorstep marker to prevent anything from blocking it off during construction.

Each room has one entrance, and optionally has exits on the three other walls. In this room, we have the entrance at the bottom center, and a single exit at the top center. Some decorative side pillars are added for some ambience.

The arrows are special. An arrow on a tile means that tile is a boundary tile and can be joined to other patterns. The engine knows to start at the bottom arrow, because that’s the entrance door, and that’s where layout begins. The bottom arrow is actually treated as a pattern outlink (explained next).

3. Find a Pattern from the Collection

A pool of pattern candidates is created from the four patterns we defined in the editor earlier. It automatically makes variants that are flipped and rotated in various ways for the ultimate in variety and versatility.

To select a pattern, it goes through each one and tests it against the room’s outlink positions (currently just one, at the entrance door). It checks if the pattern will have all of its floor tiles contained within the room and not intersecting with existing walls or water. Once it has the list of candidates, it randomly selects one, and the layout engine applies it to the room.

It picked the blue pattern from our collection! Excellent choice.

After the pattern is applied, it clears the outlink marker that was used, so it doesn’t get tested in the next iteration. Instead, we have two exciting new outlinks, provided by the pattern: up and to the right.

4. Repeat step 3

…over and over, until nothing else fits.

5. Ensure a path to the exits

We only have one exit to worry about in this room, so it’s only done once. It essentially does a Photoshop-style “flood fill” of floor tiles starting at the exit’s doorstep position:

This isn’t always necessary, because sometimes the layout engine conveniently places a pattern that enables passage to the exit. The engine will never place a wall blocking the exit, because of the “reserved” doorstep position we added at the beginning.

6. Trim Dead Ends

Anyone who’s played Soulcaster knows how deadly nooks and crannies can be. If you get chased in there, you’re going to have a hard time getting out. So in an act of charity, I turn the unused outlinks (the ones not pointing to floor tiles) into walls.

Notice it doesn’t get rid of all the dead ends, just the ones created by the dangling pattern links. If I wanted to be truly kind I could have it fully zap the dead ends and ensure circular passages everywhere. But that’s a task for another day.

7. The Finishing Touch

Leftover tiles are transformed into pretty water. Aesthetics.

So that’s basically it! I’m aware that while this type of chaotic level layout may be interesting, it’s not as cool as having a more pre-planned layout like the old school Soulcasters had. I liked to put concentric circles like walls and moats, have islands with bridges, or an enclosure surrounded by trees that you needed to infiltrate. That stuff’s all coming: the cool thing about this pattern system is that I can define patterns of any size, tag them for special purposes, and link them together however. A pattern could be an entire castle 40×40 tiles in size. It could even leave interior rooms vacant and link into them, populating them as needed.

Spawner placement is the next challenge, something I’ll be tackling this week.

Thanks for reading–and comment if you liked this post and want more of this sort of thing (or if you want to hear about something in particular).

Procedural.

It’s been a really productive week–lots of code cleanup, which always feels so nice. Since refactoring doesn’t make for very interesting dev blogging, my goal for today was to have something new to show. And with just a few extra hours of work…

When this room layout engine is more robust, I’ll do a more thorough post explaining how it works. You can tell what’s going on if you stare at it…