Tag: The Chaser’s Voyage

The Long Awaited Gamepad Update is Now Live!

Hello everyone! We’ve finally done it! You can now play The Chaser’s Voyage using gamepads! In this week’s article, I’m gonna give you a rundown of what’s new in Update 0.2.0.

 

 

Let’s start with the obvious: Gamepad support! Since the next goal of ours is to make a playable tutorial, we first needed to add in gamepad controls. This took much longer than we expected, mainly due to implementing full menu navigation via gamepads. (You can read more about what that entailed here.) Besides navigating the menu with gampeads (and now keyboard as well), we also added in rumble, rebinding of gamepad controls, and even some neat interactions with the PS4 and PS5 gamepad lights! Those lights will now match the Chaser’s Cockpit Color and will also change to match whenever a character is speaking. Of course, you can also pilot the Chaser using a gamepad, and we have a handy control mapping (seen above) in game to help people understand the controls until we implement the playable tutorial. We also have notifications that pause the game to tell you when a gamepad controller gets connected or disconnected, a must have for gameoad support!

 

 

An important note regarding Steam’s Input Controller. Currently, The Chaser’s Voyage does not support Steam’s Input Controller. Gamepad support has been implemented to be used through Windows, so if it seems like the gamepad isn’t working at all, make sure to set the “Override For The Chaser’s Voyage” (under The Chaser’s Voyage Properties->Controller) option to “Disable Steam Input”. This should allow Windows to do it’s thing without Steam’s interruption. (Not all controllers work with Windows though, so keep that in mind.) We would like to eventually add support for Steam’s Input Controller, but as we have a form of gamepad support already implemented, it is currently not as big of a priority compared to things like the Tutorial or Crew Journal.

 

Next, thanks to some feedback we’ve received, we’ve gone ahead and made a few non-gamepad related changes. The first is that we’ve changed the default Power Level Configuration. Before it was 2 power in Weapons, 2 in Shields, 2 in Engines, and 2 in Auxiliary. An even split made sense to us as a middle ground between any customization the player may want to use. However, it is also a absolutely TERRIBLE configuration to keep one’s power at, and by making it the default power, we wrongly enforced the idea that it should be the main power configuration. To address that, we’ve now made the default configuration as follows: 0 power in Weapons, 3 in Shields, 3 in Engines, and 2 in Aux. The most important things when playing The Chaser’s Voyage are to go fast, and to not take too much damage. This configuration should hopefully prime players into a more optimal play style.

 

 

The second change was made to spice up Minefields. While Minefields can be very challenging when fighting off enemies, a Minefield on its own was a bit lack luster. We wanted to spice up Minefields so that they were more interesting without an enemy, but not too much harder when there was someone to fight. Our solution? Moving mines! Each mine in a Minefield now has a chance of moving up and down in addition to the left. These mines are marked with a yellow pulsing light, instead of the normal solid green light. These make minefields much more exciting, and we originally tested out having all the mines move in this way, but that made fighting enemies within a Minefield much too challenging. By only having some mines move, we hit a nice balance between interesting and not overly punishing.

 

 

Finally we made some much smaller changes: We made The Phantom Nebula Insignia’s free repairs now work with Neutral Imperial and Neutral UGS Fleets, we rearranged some buttons on the Customize Ship screen (and added a Randomize All color option), updated some UI, and fixed a whole bunch of bugs!

 

Here’s a link to the full patch notes for more details, and for more news follow us on Twitter and join our Discord. (Where you can also give feedback!)

Fun Little Gamepad Features

We’re still working hard on getting our gamepad update done! A lot of what’s left (at the time of this writing) is getting it so that when a controller connects or disconnects, the game will pause and notify the player. In the mean time, please enjoy just a taste of what is to come regarding playing with a gamepad.

 

You can follow us on Twitter and join our Discord for more news and to give feedback! If you wish to play The Chaser’s Voyage, you can buy it while we’re in Early Access on Steam:

3 Tips When Playing The Chaser’s Voyage

Last week I talked about some of the ways we’ll be updating, and not updating, The Chaser’s Voyage based on feedback we’ve received. So while we begin crafting the tutorial, here are some tips to help you succeed at The Chaser’s Voyage.

 

1) Gotta Go Fast!

We’re experimenting with what the default engine power should be, but remember that you only have 100 days to earn your one million units. This 100 day limit is not a flavorful timer, it’s real, and your space jump drive charges faster the more power you have in your engines. This doesn’t necessarily mean you need to have level 4 engines on all the time, but having them fully powered up often, especially when in empty space or during other opportunities when you can auto-pilot, is a must.

 

 

2) Experiment With Power Set Ups / Balanced is Bad

As mentioned last week, we are changing the ship’s default power distribution from 2 Weapons, 2 Shields, 2 Engines, and 2 Auxiliary to a 0/3/3/2 set up. This is because the 2/2/2/2 set up is really bad. It’s like driving the speed limit in a racing game, it’s safe, it’s boring, and you aren’t gonna win. Instead, you should be experimenting with extremes. Choose a system you want to focus on for each situation. For example, when fighting pirates that you want to quickly dispatch of, you should try and have your weapons set to power level 3 or 4. Then decide whether you want to put more power into your shields or engines. Some situations might demand more shield power than engines, such as flying through a dense asteroid field. Others might demand more engines power, such as if the pirates are using ion weapons that easily chew through your shields.

 

The point is, you definitely need to shift your power around in order to succeed. Especially, remember to set your engines to max power when you can cruise on auto-pilot. After all, you are in a race against time!

 

3) Look Over Client Information

I think a lot of players will be tempted at first to just pick the client who is paying the highest amount of money. That’s usually fine early on, but eventually, a lot more factors are added into the equation and if you expect to survive and pay back your debt, you will need to take them into account.

 

 

For example, some clients have specific factions that are after them, like the Empire or the UGS. When looking at the right side of the client select screen, you can read that fun little story about why they need to hire you and find out if anyone is after them, which should factor into your decision if you scroll down further and see which territories their trip will take you in. (The client face portrait backgrounds are also colored to reflect any enemies or allies they may have.)

 

So, let’s say you pick up an “Evil Scientist” on the run for their experiments. They’re offering you the most money out of your three clients. While reading their story, you find out they’re on the run from the Empire. Then, when you check their territory list, they want to cross 3 imperial territories in a row. From your past experiences, you know that imperial territories have more patrolling imperial fleets that you’ll have to fly through. Also, if in any of those territories you come across a planet, you will not be able to land on it for repairs as it is an imperial controlled planet. So, while that client is offering you the most money, maybe even the best deal as you must take into account how long their mission is going to take, it could still be the riskiest.

 

Those are just some tips I usually recommend to players when first starting to play The Chaser’s Voyage. I know, as the developer, I will not be able to hold the hand of everyone who plays our game, so we’re going to try and emphasize these tips in the tutorial.

 

You can also follow us on Twitter and join our Discord for more news and to give feedback! If you wish to play The Chaser’s Voyage, you can buy it while we’re in Early Access on Steam:

 

Feedback We’ve Gotten and How We’re Addressing It

With our second Steam sale ending this week, I thought this would be a good opportunity to talk a bit more about where we’re taking The Chaser’s Voyage based on feedback we’ve received since going live via Early Access. First, there’s the article Cameron wrote up a few weeks ago talking about how we’ve been busy updating our game to work with gamepad controllers. We should hopefully be done with that soon, but at the time of this writing, we’re currently nailing down rumble features. Also, if you use a PlayStation controller, you’re in for a special treat! One of the reasons we wanted to get the gamepad stuff in sooner rather than later is due to  some feedback we got shortly after launching into Early Access.

 

Interestingly, the other feedback we’ve been receiving has revealed an issue we suspected could be a problem. It’s luckily not about any major game design decisions, as we were pretty determined to make sure our game was close to finalized before entering Early Access. Instead it’s about conveying how to play our game. Even before our Early Access launch, we anticipated this might be an issue. It’s our belief that tutorials should be made last because they are the first thing to become outdated if you change any kind of mechanic and in our case, it’s a good thing because we might have to change some stuff to better emphasize mechanics.

 

Here’s some examples of feedback we’ve received that we will be addressing in some matter or another:

• Going Slow Makes the Game Boring

An interesting bit of feedback we’ve received involves a core part of our game that ties the space jump drive to the engine speed. The general gist of the feedback is always that some events take too long/aren’t interesting enough when going slow, but are too hard and intense when going fast. It’s a kind of paradoxical issue to work out because it comes from players wanting the best of both worlds, something that’s safe and easy but also challenging and dangerous. When designing this game, we made a couple of design choices that we thought would encapsulate the idea of skill and risk that comes from, honestly, a good game.

 

 

The first was that higher speed would mean more punishment for mistakes. It’s a simple risk reward system that is essential to any game where the premise is that you must complete a task by a certain amount of time. In that sense, The Chaser’s Voyage is a bit like a racing game. Playing things safe and going slow is how you lose. However, the second design choice we made is that going slow by removing power from your engines IS sometimes necessary. It’s why we gave you the amount of power that we did and why part of this game is learning how to manage your resources carefully. You cannot have it all, so you must choose carefully, and sometimes when fighting off an enemy, you will need that extra offensive or defensive boost. It’s one of those aspects that, I think, makes our game really interesting.

 

The third design choice was tying the engines to the jump drive. The reason we did that actually came about from testing and was very obvious when we tried having the jump drive separate from the engines. The optimal strategy would just be not to play. Like, say you were in a debris field: you could set shields to max, engines to to zero, and go make a sandwich and by the time you come back, you could just jump to the next area. One really shouldn’t be making a game where not playing is a good strategy. An alternative could have been to make the speed of obstacles always the same and have the jump drive still charge at a fixed pace, with engines just affecting maneuverability. We actually do have some insignias that somewhat do that, but with some added effects to change the game up a bit, but overall the reason we didn’t want that for the default game mode is because it greatly simplifies the experience and reduces the impact of the choices you can make. It also eliminates the possibility of damaging an enemy ship’s engines and then just boosting away, which we think is a really cool strategy that you don’t see in a lot of games.

 

 

So that said, what are we going to do with this feedback? Well, for starters, we’re making some adjustments to the default power distribution that you get when first taking off from Azedo and when you respawn in Voyager Mode. Before, it was a 2/2/2/2 set up (that’s 2 in weapons, 2 in shields, 2 in engines, and 2 in auxiliary). We had it set up like this because it just kinda felt right, even if that set up is actually a very sub-optimal way of playing. We’ve now set it up so that default power distribution is 0/3/3/2. We did this to reinforce a couple of key points, such as: you should be going somewhat fast at all times and that defense is more important than offense. We also believe this set up is the best to keep someone alive after they’ve just respawned.

 

We’re also going to  place in the tutorial (and maybe at the start of a new game, though in that case it will be toggleable) a message from Wolfe that will better explain that the faster you’re going, the faster your jump drive charges. That’s what this problem really is: players not understanding this mechanic. If we can get players to learn that, then we think they’ll have a lot more fun with the game.

 

• Mouse accessibility

We’ve heard, and always suspected that some players might just loose track of the mouse when playing with the mouse and keyboard. We hope that people more accustomed to gamepads can alleviate this problem by switching to gamepad controls once we release our gamepad update. For those who will be sticking with the mouse and keyboard, we’ve explored solutions like adding a trail or a small pulse that could come from the mouse to help players keep track of it. However, many of the style of fixes we’ve thought about are things that the Windows OS already has built in. For this reason, we’ve decided that, at least for now, we aren’t going to be adding any mouse accessibility options, since it just overlaps with the accessibility options that Windows already has. (We do already have the option to turn off our custom cursor though!)

 

• Speed lines

Playing The Chaser’s Voyage, you might have noticed these white lines that streak across the screen as you’re flying. They were originally suggested by our artist, Nate, as a way of conveying motion across the screen, as we were pretty adamant about not letting the space background scroll (as that is not how perspective works in space). Lines such as this seemed common enough in space games, but I suppose never in a bullet hell-esque game that The Chaser’s Voyage can be compared to. Due to some feedback, we’ll be adding an option that will turn off the speed lines for anyone who finds them distracting.

 

• Changing what buttons advance cutscene dialogue

When we first made the cutscenes, we set some of the controls for them, like clicking to progress and space to auto-advance because those made sense to us. Hearing some feedback, we think players have all sorts of preferences that would be easy to accommodate, such as pressing spacebar or enter to progress, while making the auto-advance toggle a less commonly used button.

 

 

• Better communication

Just like with the engines, we overall need to better communicate some core mechanics. For example, one player didn’t remember that the space jump drive was it’s own system and needed to be repaired on it’s own to function. One of the hardest things right now for us, is understanding how new players think without us being directly there to hold their hands. We’ve been developing this game for so long that a lot of the controls are second nature to us. We try our best, but sometimes we think something is clear when it isn’t. The challenging part is that we need to find that fine line between giving our players the opportunity to learn the game and constantly holding their hand, afraid that there might be some aspect they don’t understand. Games are suppose to be about learning to make, and experiment, with your own choices. The best we can do, as the developers, is give the player the tools they need to succeed. We cannot help it if someone just forgets something we already explained.

 

 

You can also follow us on Twitter and join our Discord for more news and to give feedback! If you wish to play The Chaser’s Voyage, you can buy it while we’re in Early Access on Steam:

 

 

Free The Chaser’s Voyage Summer 2022 Wallpaper!

Sometimes it’s really important to take a break and enjoy the summer sun… even when you have a mission to complete.

 

 

Here’s our little summer gift to all our fans: a summer 2022 The Chaser’s Voyage desktop wallpaper. Feel free to download it! Also be sure to check out The Chaser’s Voyage, currently in Early Access, on Steam. It’s on sale during Steam’s Summer Sale for 49% off!

 

Follow us on Twitter and join our Discord for more news and to give feedback!

 

 

The Chaser’s Voyage is On Sale, 49% off, During Steam’s Summer Sale

Hey everyone! Ready for some summer time fun? Well, you can head over to Steam and pick up The Chaser’s Voyage at a cool 49% off during the Steam Summer Sale!

Follow us on Twitter and join our Discord for more news and to give feedback!

What We’ve Been Up To: UI Navigation!

It’s been a while since out last development update, so this week we wanted to share what we’ve been working on: UI Navigation via gamepad and keyboard! For the most part, we have finished implementing UI Navigation and only have a bit left until we release our gamepad update! (We’ve also updated a couple of menus to have more animations and more intuitive layouts.) Here’s more details on what exactly we’ve been up to:

 

You might remember that a couple of months ago we talked about our progress in adding gamepad support to The Chaser’s Voyage, including our new control scheme for the gamepad. The implementation of those controls was a fun and relatively quick experience. But gamepad support does not end at letting the player pilot the Chaser! In order for our game to fully support gamepad use, we need the player to also be able to navigate the UI of our game with a gamepad.

 

As The Chaser’s Voyage was initially designed with Mouse and Keyboard in mind, we knew implementing the gamepad menu navigation wouldn’t be simple. As someone who primarily plays games using gamepads, I have had a long history of frustration at many games’ UI navigation. Implementing this feature myself gave me a much needed outlet to address all of these frustrations! Here’s some of those frustrations and other challenges we’ve met while implementing the navigation:

 

•Virtual Gamepad Cursor: We both have noticed a growing number of games that use a virtual cursor that is controlled via the gamepad. In implementing our menu navigation, it became clear why. If you simulate a cursor, then you don’t actually need to make the menu elements navigable, you just have the player “click” on them with a virtual mouse. I have no love for virtual cursors. They are always either clunky or imprecise and sometimes both. They always felt odd and out of place and now they just feel like the cheap alternative to properly implementing good menu navigation. However we do understand how time and money limits can cause AAA games to need to cut corners, and while cursors aren’t a perfect solution, they are an easy one. Regardless we did not want to resort to a virtual cursor for our game, and thus still had to tackle the following issues.

•Menu Wrapping: This is a feature whose absence always baffles me. Not only does making the menu navigation loop back around the screen save so much time and reduce unnecessary button presses, it also just feels right and the lack of it is immediately noticed.  What’s even worse than no menu wrapping though, is bad menu wrapping. Games that have menus wrap, but only in one direction are particularly infuriating. Nothing quite compares to accidentally looping to the top of a menu, only to find you can’t loop back to the bottom and instead have to go all the way through the lengthy menu again. (And if you accidentally loop again? Agony!!) Implementing this feature was pretty trivial, especially with Unity’s UI Navigation tools. (Making me even more confused why any game would not have it.)

 

 

•Scrollbar Positioning: We don’t have many different scrollbars in The Chaser’s Voyage, but you do find one every time you’re picking up a new client. As a product of menu wrapping, the player can continually navigate down or up and continue switching between the scrollbar and the confirm client button. But when this happened the scrollbar would stay at the bottom or top of its zone. What I’ve seen other games do sometimes is that if you highlight a scrollbar from the top, the scrollbar would then jump up to the top most position, and jump to the bottom is highlighted from the bottom. This took a little bit of extra coding to pull off, but the final result is well worth it. It really ties the scrollbar to the other menu elements in a subtle manner. A second consideration was making sure that the Insignia Selection menu’s scrollbar automatically shift its position to match which insignia the player was currently highlighting. On top of that we needed the correct insignias to be highlighted when the player moved off of the scrollbar after they moved it manually.

•Button Highlights: This was thankfully already mostly accounted for by our current design of our UI, but many games do not make it obvious enough which button is being highlighted or is currently selected when using a gamepad (or even a mouse sometimes!) This was something we kept in mind from the beginning of our previous UI redesign, and Eos came up with the current (wonderful) highlight icons for buttons, and I added in the smooth animations to make them pop to life. Now all that was left in regards to button highlighting in gamepad navigation was making sure that buttons only became highlighted when they were usable. We have quite a few neat animations with our UI screens popping in and out, or fading different elements, so I needed to account for these animations where the UI buttons aren’t activated.

 

 

•Button History: When you go back a menu, you expect to be put on the button that led you to said menu. With our nestled menus, we had to keep track of what buttons led you where, and make sure to put the player back on the correct buttons when exiting a menu. This was relatively straight forward for the most part. But the next item on the list complicated this process quite a bit.

•The Back and Start Button: These two buttons were the trouble children of menu navigation for us! We have a decent amount of nestled menus and had to make sure only the most recent menu disappeared when the back button was pressed. We also had to make sure that like the UI buttons, the Back button wasn’t usable while the menus were animating in or out, as it would cause some very awkward game states. On top of that, we needed the correct previous button to be highlighted. This was easier when everything was done by clicking on UI buttons, as each button that exited a menu could point to the previous button, but the Back button can be used on any menu no matter what. So we needed to keep a more detailed history of the buttons that were pressed to get into nestled menus, and make sure that that history was cleared and used correctly. Adding in the Start button as a way to exit the pause menu (a necessity) no matter which screen you were on complicated things further. We now had to make sure multiple button history elements were cleared or risk the player being trapped in an inactive menu! (Don’t worry, we always allow the mouse and Esc key to be used, regardless of if the gamepad is in use, so the player is never locked out of the game. You know, just in case. ;D)

 

 

•Dual Stick Controls: This is a relatively small point, but it still deserves a place here due to my affection for it. Let it be known that the Nintendo Switch has absolutely spoiled me. The ability to navigate its menus using either the left OR right thumbsticks is such a wonderful improvement to UI navigation. There have been way too many times where I would try to navigate through a menu with the right thumbstick as it occasionally felt more natural, only to be reminded that almost no games do this. Why limit UI navigation to one stick when the other is unused? Some games make great use of the right stick as a way to scroll through many menus, but that is not drastically different from just having the left stick scroll instead. We decided for The Chaser’s Voyage to make the left and right sticks both navigate through the menu in the same way, just like the Switch.

 

That covers most of the big points of UI Navigation that gave us any sort of trouble or that I wanted to give a special spot light (dual stick controls). With UI Navigation done, the current task is now getting button remapping to work with gamepad, adjusting the options to let players switch between control schemes, and adding in some pause menus for when controllers get disconnected. We can’t wait to get this update into your hands, this has definitely been a very important feature made with lots of care!

Follow us on Twitter and join our Discord for more news and to give feedback!

Inspiration and The Chaser’s Voyage: The Adventures That Made Us – Part 2

Continued from Part 1!

So now that the game that would become The Chaser’s Voyage was designed on paper, we needed to decide how exactly we were going to make it. The switch to a real-time action game presented a lot of new challenges, some of which might have eventually presented themselves in our original design, but some I think were wholly unique to our new vision for the game. For instance, how were we going to alert players to events happening in the game, such as systems breaking or new enemies incoming? The answer, of course, was voice acting. We could have taken many approaches, but we were particularly inspired by Star Fox 64’s use of voice acting that served both a flavor and thematic purpose, but also had hidden mechanical purposes, such as giving you advice on what to do or letting you see the boss’s HP.

 

 

We wanted something like that for our game and so we decided that you would have crew mates that correspond to each of the different systems, as opposed to having a single co-pilot who would update you on everything. This way, based solely on which person was talking, you could tell what system was being affected. The biggest challenge was to find enough people to lend us their voices, but luckily we were able to.

 

The characters themselves we knew should be kept wholly original, though of course, starting with some base inspiration isn’t a bad thing. Tai was originally conceived as a bit like Captain Rex from the Star Wars: The Clone Wars TV show, as a no-nonsense fighter. Wolfe, while very different, started off vaguely as having a similar energy to Strawhat shipwright Franky from One Piece mixed with the hot shot brattiness of D.Va from Overwatch. Nila, was supposed to be very Spock like, in that she was cool and logical. Edwin was probably the most original idea from conception: just a guy who didn’t want to be there, but was because he’s your friend. By the end of writing though, these characters all ended up taking on a life of their own. Edwin basically stayed the same, except we give him some hidden depths and courage just to make him a little less one note. Tai, on the other hand, became more of a battle-ready goofball who knew when to be serious and when to be himself. Wolfe became a full of herself, hot headed artist full of passion and drive (more inspired by myself than any work of fiction). Nila also took on a somewhat quirkier personality for reasons that I can only remember as being “the more subdued, logical character, doing goofy things is really funny”. I might have been inspired by Garnet from Steven Universe, but I don’t remember if that was a conscious thing, I just knew I liked the trope.

 

 

[Hover over this next part to reveal some ending spoilers]

A particularly challenge that came from changing the premise of the game to “you now owe a debt to a crime boss type of character” was: what happens if you lose? The idea of having to race against time to complete an object isn’t necessarily new, but the only game I know that ever did so on such a scale was the Nintendo classic, Pikmin. The only problem I had with that game though is that you lose for failing to meet the time limit. I remember playing that game for the first time and just barely not getting that last part before the time limit ran out. While I didn’t lose, I didn’t get the best ending and trying again would mean restarting the entire game. So, that’s why we thought it would be a cool idea to not have the game end, but instead radically change. Instead of racing against the clock to beat a deadline, you instead were fighting for survival to get a bounty off your head.

 

But just like with FTL, what I think makes our game great isn’t the stuff that makes us similar to the games and pieces of media that we like, but the differences. In our hyper-media focused world, it might be easy to say that there are no original ideas anymore. As true as that might be, neither Cameron nor I would want to use that as shield for simply copying the things we love. We want to learn from them. When George Lucas first created Star Wars, the story was extremely rooted in the contemporary politics of the time. It meant a lot to him and how he expressed his feeling about a tumultuous time in American history. If we had gone with my original idea, and just used an evil empire, it wouldn’t have meant anything. It would be like that scene in Yesterday, where the main character sings “Back in the USSR” in a world where only he remembered The Beatles, and Ed Sheeran was perplexed why he would sing a song where he called Russia a name that no longer was used by the time he was born. That’s why when it came to our story, we presented our republic stand-in, the UGS, as neutral with our Empire, not better than them. Yes, both sides were at war, but I wanted to express my feelings about politics, especially from the viewpoint of a bystander. I wanted the crew to express different views of the galaxy’s long and complicated history of perpetual conflict.

 

 

Because ultimately, that’s what inspiration is. It’s not about taking things you like and using them without any rhyme or reason. It’s about taking those things you like and asking yourself critically about why you liked them. What made them work, how did they work in the greater context, how could something like that work in this new context? Inspiration is about learning from something that came before you. It’s about realizing that what makes Star Wars great isn’t the starfighters and big battles, but the characters and the message that George Lucas wanted to tell. What made Star Tours great isn’t the number of scenes you get to go through, but how each combination made every encounter different, making you eager to experience what was next. What made Star Fox great wasn’t the fact that you were flying with a squad, but that you were part of a team that each contributed to your entire effort. And what makes FLT great isn’t that it’s a roguelike with a Star Trek feel, but that it acts as a playground where gamers can tell their own harrowing adventures of captaining a ship and taking on unpredictable adventures with the help of their crew. All of those lessons are what we really took away and used to craft The Chaser’s Voyage and for that we owe our gratitude.

 

Follow us on Twitter and join our Discord for more news and to give feedback!

Inspiration and The Chaser’s Voyage: The Adventures That Made Us – Part 1

Last week I answered the question of whether or not The Chaser’s Voyage is, in fact, a roguelike. The answer ended up being “yes”, but in that article I explained how we never set out to make a roguelike and how we accidentally stumbled into the genre through a wellspring of inspirations taken from experiences and media we enjoyed. This week, I wanted to share what some of the inspirations for The Chaser’s Voyage were, because I think it’s important for us, as game developers, to share our process and show how we learned from our inspirations, rather than just blindly took, to create something wholly unique and innovative.

 

I think it must first be said, that some might find that The Chaser’s Voyage gives off a lot of FTL: Faster Than Light vibes. As I mentioned last week, Cameron and I were familiar with FTL, though we didn’t really think of it as a “roguelike” when we played it. Mainly because we didn’t really know what a “roguelike” was back then, but I would argue that despite the similarities, (such as managing power across multiple systems like weapons, shields, and engines) the FTL devs and us both just drew inspiration from the same pool of sci-fi related tropes. “Divert all power to the engines/shields” is a common enough phrase mentioned in both media like Star Trek and Star Wars and it just lends itself readily to the idea of having a limited amount of power and only being able to allocate it in specific ways. To give credit where it’s due, FTL did show me that such a concept could work and, in a story that I find a little embarrassing, I may have subconsciously been a little too inspired by the game in the beginning.

 

 

In my original prototype for “Project: Space Captain”, you took on the role of a daring space captain. You were in charge of managing power across your four main systems. You made the call to stop for repairs or keep going. Most importantly, you pushed the big button that would warp you from one part of space to another, where you would battle enemies in different kinds of interstellar environments that would be chosen and mixed together at random. That last one was definitely inspired by Disneyland’s Star Tours more than anything! I thought it would be a neat game that really captured the feeling the being in command of a starship, where you had to trust your crew, make bold decisions, and face the unknowns of the next big jump. So it kinda came as a surprise to me when Cameron gave me one condition before greenlighting this project: “make it less like FTL.”

 

I remember wanting to be defensive about this. It wasn’t like FTL. Sure, your ship didn’t move on screen, but that was so the player could concentrate more on managing their power systems and yeah, you were being pursued by an interplanetary empire, but that was just for plot reasons to justify the timer, not to hinder any exploration. We also both have permadeath, but that was inspired by lots of other games, mainly my fascination with the mechanic from the survival horror game, ZombiU.  The more I thought about it the more obvious the truth was. For all it’s differences, “Project: Space Captain” would look way too similar to FTL. I took the task to make the game less like FTL and more true to what Cameron and I set out to accomplish when we formed Bright at Midnight: make unique and interesting games set in fully realized worlds. I remember thinking to myself “how could I have strayed so close to a game that I played only a couple of times in college? I really thought I was paying homage, while staying distinct from, one of my favorite Disneyland rides of all time.” That’s when it hit me. FTL’s inspirations were clearly from Star Trek. It’s space battles played out like the submarine combat that inspired the original show. Your role as captain was like being Kirk or Picard. But I’m not a Trekkie. I’m a Star Wars fan. If FTL was going to be like Star Trek, then it would seem only fitting that we were gonna be more like Star Wars.

 

Immediately, Cameron and I agreed on letting the player also pilot the ship. We actually really liked the idea of piloting a ship while managing systems in real-time. It reminded me of… well, a Star Wars game I played as a kid. It was the Revenge of the Sith movie game for the Nintendo DS. It had this mini-game where you would fly a starfighter and using the touch screen you could strengthen your shields in the front, the back, or keep them balanced. It was actually really fun and very Star Wars to be making those kinds of adjustments in mid-flight. Luckily, the original design already kept things very simple and the only significant change, besides the added piloting, was tying how fast your jump drive charged to the ship’s speed. In the original prototype, the goal was actually to travel a certain number of lightyears within the time limit and a space jump would take you 10,000 lightyears. The amount of distance your engines could travel was very small, even at full power, so they were mainly there to better your chances of evading. The space jump drive would charge at the same rate, regardless of how much power was in engines, and like in The Chaser’s Voyage, it would stop charging if it was damaged. With the game now being a real-time action game, we needed a way to discourage players from simply turn off their engines and waiting for a full charge. By tying the engine power to jump charge (with no power resulting in no charge), we found that way.

 

 

Cameron also wanted a change in the plot. They felt like the “transport an imperial defector” plot was too similar to the plot of FTL (which I didn’t even remember until they brought it up.) This challenge actually wasn’t as simple as just writing a new plot. The reason I initially went with that defector plot was to spice up the reason for having an arbitrary timer. I felt that the timer was majorly important to adding tension to the game, but just having a timer with no consequence didn’t make any sense. But then it hit me: What if you had a debt to repay? That was very Star Wars. In fact, it was Han Solo’s motivation for taking Luke and Obi-Wan to Alderaan. However, simply changing the window dressing didn’t address the root of the problem, so I proposed that instead of one big adventure, what if our game was actually comprised of many smaller adventures? After all, we didn’t want to just tell players that this big final score is gonna save their skin, we wanted them to say it themselves naturally when they saw a client offering a lot of money.

 

So from this radical rethinking of how our game could be structured, a desire to make something more unique from another popular game, and a leaning into something we love without borrowing too much, we felt that we had come up with a game that was unique, interesting, and a perfect way to show off what we could do as game designers.

 

To be continued in Part 2!

Follow us on Twitter and join our Discord for more news and to give feedback!

 

Is The Chaser’s Voyage a Roguelike? The Answer May Surprise You! (Spoiler: Yes, but Accidentally)

Now that Steam’s Going Rogue event is over (thank you to everyone who checked out our game!), I thought now might would be a good time to discuss a pretty important question: Is The Chaser’s Voyage a roguelike? The answer (and the history behind said answer) is a little complicated. For starters, neither of us set out to make a roguelike in the first place. When I initially pitched “Project: Space Captain” to Cameron, the word roguelike was never mentioned in the conversation. Looking back on it, there were definitely a lot of roguelike elements in the initial design, but we both were still rather unfamiliar with the term and our experience with the genre was limited to games like Spelunky and FTL: Faster Than Light. Instead of roguelikes, we looked at other sources of inspiration, such as the Disneyland ride, Star Tours. Particularly the modern incarnation that randomly strings together sequences to create unique experiences for the riders. I remember I pushed hard on the permadeath aspect because I was fascinated with the concept thanks to playing ZombiU, the only survival horror game that I really like, because of the actual fear it put into me (because of the permadeath mechanic, I actually felt a little sick after a particularly harrowing experience and I loved it). With these inspirations we created a game featuring procedural space encounters with a permadeath system. So in short, we accidentally reverse-engineered the concept of a roguelike, which I say is a testament to the appeal of the genre.

 

Since starting Bright at Midnight, Cameron and I wanted to be free from the constraints of genre labeling and in a way, we think that really helped shape what would eventually be The Chaser’s Voyage. This lack of focus on genres allowed us to think more deeply of the experience we wanted to create, rather than try and force in ideas that were common to a specific genre. For example, according to Wikipedia’s page on Roguelikes, some key features of the genre include making the game turn based, adding in resource managements such as health potions, or in the case of a sci-fi setting, fuel, repair material, and ammunition, as well as other concepts that neither us really wanted in our game. The freedom from genre also allowed us to add features that would be appropriate for the game were making, but maybe not what people would think of when you call something a roguelike. For example, our 100 day time limit and transporting clients who are willing to pay you (and have their own stories going on in the background) was particularly inspired by the scene in Star Wars: A New Hope where Luke and Obi-Wan meet Han Solo, who if you remember, is primarily motivated to pay off a debt to the notorious gangster Jabba the Hutt, just like how the player must repay a debt to the infamous pirate lord, Pirate Lady Styx. (What I’m saying is that The Chaser’s Voyage is a Han Solo simulator, okay?)

 

 

Thanks to this genre free development mindset, we were able to confidently cut a galactic map feature, which meant we removed any literal exploration from the game without ever having to think “wait, but isn’t exploration a key part of roguelikes?” Which thank goodness we removed it, because thinking about that idea again, it would have unnecessarily made the game way more  complicated. We also were able to implement one of our more unique features without a second thought, that being that after failing to repay your debt to Lady Styx on time, (Hover over for spoilers) you do not get a Game Over, but instead the game continues, giving you a new mission with new unique challenges. We remove the time limit and increase the money you need to pay to Lady Styx, but due to the bounty she placed on you, the difficulty of the game increases in unique ways.

 

So why are we calling our game a roguelike now? Because, while we don’t like the constraints of genre labels, marketing does. When it finally came down to putting our game onto Steam, we had to think of a label to call our game. Again, we didn’t even consider our game a roguelike, because we never set out to make it one. Before this, we had kind of been describing our game as a “sci-fi sidescrolling space based action game with real-time strategy elements.” While most of that was true (real-time strategy is true in only the most technical of aspects), it was also a mouthful. Once we were looking at genres to classify our game on Steam, it kind of dawned on us that our game might be a roguelike. Looking at the Wikipedia article (and finding out that what is and what isn’t a roguelike is a debated point) and this article on RogueBasin, we realized we hit most of the high value features in the Berlin Interpretation:

 

1) Random Environment Generation. Yep. If you want, you can think of each territory you jump into as a room filled with randomly generated obstacles, with many of them having randomized factors.

2) Permadeath. Again, yes. Though we eventually added a mode that removed this because we know that permadeath isn’t for everyone. We still have two modes where permadeath is very much in effect.

3) Turn-Based and Grid-Based. No. Here’s the reason why I said we hit -most- of key features. We never intended this game to be played in either of these fashions, even in the initial concepts.

4)  Non-Modal. Yes. One of the reasons we designed our UI the way we did was so that every action you take could be done in real-time.

5) Complexity. Absolutely. We invite players to find their own solutions to solve the problems each jump puts forth. The only challenge we give the player is to survive and earn their money within the time frame. This means the player can run away from bounty hunters rather than destroying them, tank asteroids with their shields at the cost of speed, communicating with pirates (if those scoundrels are open for it), etc. You could also vow off picking up any clients that are wanted by the Empire or risk it all by going with whoever is paying more.

6) Resource Management. Your money is a resource that not only do you need to win, but also to survive. Since all hull repairs deplete your money, taking too much damage puts you that much further from you goal. You also manage your power across your systems, which tie into the resources that are your shields and oxygen. We would argue that the game is primarily about resource management.

7) Hack’n’slash. This one could be a little contentious because we are more a bullet-hell esque side scrolling shooter than a Hack’n’slash (this is why we don’t like genres), but killing enemies is important to our game. It’s not necessary if you’re skilled enough and sometimes pirates can be talked out of fighting you, but I’d still argue we hit this marker in spirit, if not in perfect practice.

8) Exploration and Discovery. Again, this might be contentious because, yes we don’t have literal exploration in our game, but we do encourage a kind of narrative exploration that helps players decode our system to help them make better choices. For instance, while I spoiled it a few weeks ago, pirates being more common in UGS territories is not told to players outright. It’s revealed through the crew journal in an entry that talks about how the UGS has a pirate problem.

 

 

So why did I feel like it was necessary to tackle this question? What other game devs feel like they need to justify their own genre labeling? After all, if someone calls their game a Metroidvania, nobody really questions that. Part of the reason was because I wanted to acknowledge that our game doesn’t have the usual trappings one might expect in a roguelike. It’s something that’s always been in the back of my mind when talking about our game, because I’m worried someone might say “this isn’t a roguelike, because there’s no items or upgrades” or something like that. So, it just makes me feel better to have all my thoughts laid out here. The other reason though, was to encourage any developer or aspiring developer out there to really do away with the notion of genre. The Chaser’s Voyage was born not out of the idea to make a space-based roguelike in the same vein as FTL, but to make a game where you felt like a daring space captain. Where you felt like Han Solo making your Kessel Run. A way to create unique and cinematic moments where you can later brag to your friends how you narrowly avoided that bounty hunter just off of Wohza by racing her through an asteroid field. Really focus and make your game in such a way that best serves the experience you want to deliver to an audience. Then later, for marketing or to just easily describe your game to your friends, shoe horn it into a genre.

 

Follow us on Twitter and join our Discord for more news and to give feedback!