Tag: Development

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:

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:

 

 

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!

Guide to the Galaxy – The People of Sector 99

Last week, we talked about the planets of the sector you’ll be traversing during your time playing The Chaser’s Voyage. This week, I’ll be showing off the different denizens of the sector that will make up your potential clients. One of the best parts of making a sci-fi/fantasy setting is creating all sorts of fun and interesting new sapient species, so we were really excited to not only show off some alien creatures, but also to write some history for them. Like most of our art, we gave our artist a lot of freedom when it came to the designs, only offering our input to make some refinements (adjustments that fit better into the larger lore we had in mind) or just some designs we really wanted to have in. From there, we wrote backstories to fit the designs, doing our best to avoid any typical alien tropes that one might see in a lot of sci-fi settings. We particularly wanted to avoid any kind of histories that would imply that everyone of a particular species shared a belief, mindset, or personality type.

 

Humans

 

 

Of course, humans exist and are quite common. We even have all our your crew mate characters be human. We did this because while encountering and befriending aliens is fun, we wanted to ensure that the vast diversity of humans was also represented in our game (and even then we were unfortunately limited since we only have four crew mates). In a lot of sci-fi/sci-fantasy stories I’ve encountered, humans are always very common either through massive colonization, a focus on places like Earth, or their commonness was not really explored at all. We wanted to explain this commonality in a different way. When thinking of the human backstory, I was inspired by an episode of Power Rangers (of all things) where they hand waved extra-terrestrial  humans by simply saying “humans exist elsewhere too.” As far as I know, that was never explained in the context of the series, but I liked the idea. So, we decided that humans would be a kind of galactic mystery, where despite what evolutionary science might say, humans came about independently on vastly different planets, all over the galaxy, thus explaining how common they are.

 

As for the other species, well, I don’t want to spoil too much since you’ll be able to find out more about them in the crew journal, once we implement it. So, I’ll give you just a little preview of them here.

 

Chlik

 

 

The chlik are an imp-like people from the swampy planet of Yazou. Thousands of years ago they colonized planets that would would later be collectively known as the Deadworlds.

 

Faeian

 

The faeians are elf-like humanoids from the forest planet, Tethalon. One of the insignias that you can equip in the game, The Angel of the Radiant Moon, is actually tied directly to faeian culture as part of their most common religion.

 

Fear-Eaters

 

These goblin-like creatures were part of the warrior caste in the religious theocracy on the planet Temekko. Since the fall of that theocracy, fear-eaters are way more common throughout the sector.

 

Gnathus

 

The gnathus are a fish like species, though they’re more like amphibians, living both on land and underwater. When it came to making different varieties of gnathus we wanted a mix of colors reminiscent to real world fish, with some being explicitly more tropical and others being more arctic. They originated on the icy world of Balitore, though because of their advanced colonization methods, their coloration changed to adapt to new environments.

 

Gryphinian

Gryphinians are avian people from the mountain world of Ai’lika. Like gnathus, we wanted the variety of colors for this species to resemble the birds we have on earth.

 

Ka’koi

 

The ka’koi are a lizard-like species from the industrial world of Agasta. They’re kind of our example of how a species could be designed in such a way to fit a character archetype, but you could still easily apply those traits to fit different kinds of characters. Ka’koi’s eyes, for example, are described as being perfect for hunting, but we say in-game that characterizing them as bounty hunters and warriors is a stereotype and that plenty of ka’koi have gone on to use their innate abilities for medical work, racing, and farming, among other pursuits.

 

Kingii

 

Our other lizard inspired species, the kingii, is the first species on this list to not originate within Sector 99 (besides humans). They are from Klik-Sss in Sector 22.

 

Maloodans

 

The mysterious maloodans are from the wasteland world known as Dusta. This species was an interesting challenge to write for because they were designed with a mask, but since you could encounter so many of them I had to come up with a reason for why they would all wear masks. What I came up with is that it’s a breathing apparatus featuring some of their cultural designs. Had we more opportunities to explore other maloodan characters, I think it would have been neat to have more variety in their masks. Oh well, there’s always the sequel.

 

Mayvian

 

The mayvians are spider people that are the descendants of those who survived a major cataclysm that happened on their home world of Old Serata. I wanted to take this opportunity to show that in this galaxy, those big origin myths that might be the backstory for an entire saga can just be fun information to anyone else.

 

Nygothan

 

 

The nygothans are another species from outside the sector, like the kingii. Their people’s history is seeped in some of our deep lore, so instead I’ll share some of the thoughts we had developing them. While the other species were designed to be gender neutral in their presentation, the nygothan design we chose was more feminine. So, we used it as kind of an opportunity to riff on the, frankly, annoying trope of the all female alien species. They only look all female due to our biases in our perspective. Their species just has very different, culturally contextualized, ways of presenting gender (kinda like us humans do.)

 

Paju

 

The poor paju come from the forest world Quitos, but mass colonization eventually forced them to all migrate off world. Their sad backstory was directly inspired by those sad little eyes.

 

Sin-Eater

 

Sin-eaters were the lowest caste on Temekko and used their special ability to make people forget specific memories. Then, they would have to atone for those sins themselves. Luckily, most sin-eaters live less traumatic lives now.

 

Todean

 

While I’m not entirely sure, I think I was inspired by some of the jokes in Portal 2 when making the backstory for the mantis-like Todean people. They have strong cultural ties to genetic modifications. I think I want it to be ambiguous whether or not the mantis form is how this species naturally looked before they adopted genetic mutations, because that’s much funnier.

 

Xanapor

 

 

Finally, there’s the xanapor. When we saw this design, we loved how weird it was. In fact, I think we specifically wanted something really out there. So naturally, we had come up with a backstory just as weird and mysterious as they are.

 

 

These are the species of people you can find as clients, but throughout our crew journal we mention several more species. Usually they are just from outside the sector. All of the art featured here was done by our client artist Santi Leigh Biondolillo.

 

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

Guide to the Galaxy – Planets of Sector 99

Now that we’ve met your crew, lets find out more about the galaxy you’ll be flying through in The Chaser’s Voyage. All of the action takes place in a small section of the galactic map called Sector 99. To the wider galaxy, it’s known as the last bit of territory before one enters The Frontier (an unexplored and enticing section of space), which makes it coveted by all sorts of galactic powers, such as the UGS, the Empire, and even gangs of pirates. Your adventure always starts on your home planet of Azedo (a small backwater farming planet), but from there the worlds you can visit open up as over 260 planets become possible destinations requested by your clients. While your stays on each planet will only be brief,  your Crew Journal will give you little hints at the much bigger world you just happen to be visiting.

 

A small shanty town on the Snowy Mountain world of Porons.

 

One of the most difficult things of operating on an indie game budget (or really any kind of game budget) is that it’s not often possible to make the world you’re exploring as vast and deep as you’d want it to be. Since The Chaser’s Voyage’s inception, we knew the player would be hopping from planet to planet. Of course, it’s immersion breaking and boring to always just be heading towards some unnamed “planet”. How’s this universe supposed to feel lived in if you know nothing about it. So, we decided to name our client planets, making one for each combination of several factors, such as land to water ratio, primary biome (borrowing the ever classic single biome trope), population density, and civilization type. So pretty soon, we were able to visit places like the sparsely populated shanty towns of the snowy world of Porons or one of the massive factories that sprawl along the wastelands of Neraka or even the modern cities of the jungle world, Shirenko.

 

A modern city on the Jungle planet, Shirenko.

 

We felt like this made each planet have it’s own identity. After enough time playing, planets like these would becomes as familiar to the player as some of the crew or key figures mentioned in the Crew Journal. With this kind of identity also came a desire to make the planet feel more alive. We didn’t want to always just show static images when the player was landing and taking off, so we added in some simple weather events. On Korri for instance, it could be snowing when you visit it, while on a jungle or forest world, it might be raining. Some buildings also have smoke effects to help make them a little less static. Background ships were added as well, to give the feeling that you are in a space port town, with ships landing and taking off every day.

 

A large factory complex on the Wasteland world of Neraka.

 

Ambient sound effects were also crucial. We made sure they were subtle, so as to not be intrusive, but if you listen carefully you can hear the winds blowing across a desert planet or the moving of machines on an industrial world. Finally, with each planet becoming more alive and characterized, we gave them small snippets of backstory that fills out your journal whenever you visit a planet for the first time. They are little comments left by your crew reflecting some of their thoughts, observations, or even the history of the planet. We sadly can’t let the players freely explore all these worlds, but we wanted to give the impression that you are just one part of this larger galaxy that is full of adventures and stories to tell. Ironically, I think it helps grounds the story we are telling.

 

A fancy city on the Snowy Forest world of Korri.

 

The art for the landscapes of each planet as well as the different kinds of buildings we use was done by Felix Yuniar.

 

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

Adding Gamepad Support

 

Hello everyone. We’ve been super busy adding and testing gamepad support for The Chaser’s Voyage. It took a lot of tweaking, but we finally got a control scheme that feels really good to use. Personally, I love playing with the Xbox gamepad now.

 

You can check out the gamepad in action on our twitter.

 

Once we get more gamepad functionality in, we’ll add it to the early access build so that you guys can get to play around with it. What was really tricky was finding the perfect control scheme for our, admittedly, non-standard game. We wanted something that was as easy and intuitive as our keyboard + mouse controls. We’re hoping you guys will like them, but even if you don’t, we do plan on making this control method just as customizable as the keyboard + mouse control scheme.

 

Default Gamepad Controls (Xbox Controller):

• Left / Right Thumbstick: Move The Chaser

• D-Pad Up: Toggle between Main Screen and Info Screen

• D-Pad Left: Engage / Disengage Autopilot

• D-Pad Right: Save & Quit (when available)

• Left Bumper: Activate Comms

• Right Bumper: Activate Space Jump Drive / Repair Space Jump Drive (if broken)

• Start: Open Pause Menu

• Select: Open Crew Journal

 

To increase power to a system, you hold the Right Trigger and then press the corresponding face button. To decrease power, you hold the Left Trigger and press the corresponding face button. Finally, to repair a damaged system, you just press the corresponding face button without holding either trigger. Each face button corresponds to one of the Chaser’s systems:

• A Button: Weapons Systems

• X Button: Shield Systems

• Y Button: Engine Systems

• B Button: Auxiliary Systems

• Right Trigger (Hold): Increase System Power

• Left Trigger (Hold): Decrease System Power

 

We’re really looking forward to having people play The Chaser’s Voyage with a gamepad and we hope you all like it as much as we do.

 

Follow us on Twitter and join our Discord where you can get more news and give feedback!