The New Look of Soulcaster

Last week, I had the opportunity to show the Soulcaster pre-alpha at a MIX event hosted by Patreon. With my post-GDC recovery complete, it’s time to publish the reveal here on my site.

SC-key-2016march-50pc_600px

 

It’s been over a year since I last posted images or mentioned anything about production, so it’s time to bring everyone up to speed and answer the most frequent questions I’ve gotten so far.

Continue reading The New Look of Soulcaster

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.

 

Pathfinding Exhibition

I’ve gotten things to a state where it’s good enough that I want to show it off.  This video shows all the features I’ve put in place, and what happens when they’re removed. It’s kind of like that elementary school science experiment where you bake several batches of cookies and leave out a different ingredient each time, to see the results.

The pathfinding AI is a collection of features:

  1. Gauntlet Movement: Monsters move towards the summoner. They will slide along walls with diagonal movement, but can’t navigate around corners and will get stuck easily.
  2. Sidestepping: Even without any maze solving code, the Gauntlet movement can be improved a bit. When monsters sense that they have been blockaded for about one second, they randomly try moving in a diagonal towards the summoner, which helps them get around walls.
  3. Raw Pathfinding: A maze solving algorithm points the monsters towards the closest viable path to the summoner. If the monster has a direct, visible path to the summoner, it switches back to Gauntlet movement, because that tends to be faster than using the path. Notice how the rats on the right side get stuck because they get to the doorway at precisely the same time. I call this the Three Stooges Effect, and I came up with a pretty cool solution for it:
  4. Traffic Fields: A traffic director data type watches the monster movement, and adds vectors to each floor tile.  If a monster tries to walk on a tile that has a vector pointing in the opposite direction, it gets blockaded just like a wall. This way, whoever gets there first sets up the flow of traffic for that particular tile. Each vector times out after a second or so of inactivity, which lets the patiently waiting rats through. Look at the rats on the right now–they are behaving so orderly!  Even though both rats reach the doorway at the same time, the top one got evaluated first, got its movement vector placed there, and successfully repelled the lower rat (and all his friends).  The visualization lets you see the tile vectors as arrows.
  5. Creature Weight: The numbers you see on each tile in the Traffic Field visualization are the “weights” of each tile. These are used in the maze solving algorithm. They actually represent the number of steps it takes to get to that particular tile from the point of origin: in this case, the summoner. The fastest route is easily generated by starting at the monster’s location, and just picking the lowest number from the eight available directions.  With creature weight taken into account, any tile occupied by a creature gets its weight bumped up by a couple points, or 5 points if the creature is blockaded. Notice how the rats don’t all take the same path: once a few have started using a particular route, the weight to cross it is now larger than another route. Not only does this decrease the time it takes for a large crowd to solve the maze, but it also has the great side effect of flanking.
  6. Uncrowding: This last one is subtle, but makes a difference. When a monster has been blocked for more than a couple full seconds, it picks a random direction to move which is roughly in the opposite direction they were originally trying to go. This breaks up congestion and slightly improves the maze solving time.

At this point, the pathfinding AI is good enough to leave alone for a while. I just wanted to get it to a point where the monsters don’t get stuck, and you won’t be able to cheese them (at least not easily).