Hello everyone and welcome to
another devlog for Bottled Sky, an action exploration game with a big drill.
I got a bit sick so I delayed recording this video, but now it’s nearly 2 weeks late and it
hasn’t gone away, so apologies if I sound sick, you’ll just have to deal with it.
This month, I’ve been thinking about a game design concept that outlines what information the
player has access to and perhaps more importantly, what they don’t have access to.
I don’t know what people call it, so I’m calling it “Available Information.”
So I’m gonna talk about that concept for a little bit and then apply it to
a specific part of our game.
As a game designer, I like to look
at game information as being on a spectrum of discoverability.
On one side of the spectrum, information is “highlighted,” meaning
the player is being directly shown that information and they don’t need to search for it.
An example of this is in chess, both players know the positions of all the pieces on the board.
At no point during a game are any of the available pieces ever obscured from either player.
If you’re wondering what happens if you design a game where all information is
knowable at all times with no uncertainty, that is what you might call a solved game.
Like a puzzle, where you have all the pieces and you just need to figure out
how to put them all together.
The downside is that the more information your
game has, the more overwhelming it is to players.
On the other side of the spectrum,
information is “hidden.”
This is the side of the spectrum that
can make games more interesting.
Oddly enough though, if you try to have
information that is completely hidden the whole time then you just end up with a guessing game
where you can’t deduce the information at all.
The most interesting kind of hidden information
is when you can gradually uncover and decipher it using other pieces of known information.
This is pretty much the foundation of the mystery genre.
To use chess again for this example, the hidden information is your opponent’s next move.
At the start of a game of chess, you don’t have much information to be able to discern
what your opponent’s first move might be.
As the game of chess continues, you can
begin to evaluate what moves are available to your opponent and figure out what their most
optimal options are, and plan around those.
Somewhere in the middle of the discoverability
spectrum is when the information is available, but is not being directly given to the player.
Keeping information in this grey area of known or unknown is what tests the
player’s ability to analyse data.
I might as well stick to
chess for this final example.
Trying to figure out which move is best on a given
turn, is something you can figure out by analysing all of the non-hidden information on the board.
Analysing all of the possible outcomes takes a long time, even for a computer, which is why
competitive chess involves a time limit.
Being good at chess involves analysing lots of
outcomes quickly, combined with lots of pattern recognition to save time by sifting out common
bad outcomes which usually comes with experience.
I might make reference to the discoverability
spectrum in future videos, but for this video, I want to look at some specific
pieces of information and decide how discoverable I want it to be.
So what I want to look at is enemies that are nearby, but off-screen.
First, let’s look at where this information currently sits on the discoverability spectrum.
An enemy that is on screen would be pretty close to highlighted information.
I’d say the difference between being perfectly highlighted and close to highlighted is
where you have to look to find the information.
UI elements are usually located in the
same position on the screen all the time so they’re easier to find compared to an
enemy that might be anywhere on the screen.
Having camouflaged enemies might be an interesting
idea to explore, which is an idea I got simply by using this design concept and wondering
how I could reduce information about an enemy that is on screen.
I’ll write it down and distract myself with that idea later.
Where would you think an off-screen enemy fits on the discoverability spectrum?
Well, it depends.
If you haven’t yet encountered the enemy there
is currently almost no other way to tell if that enemy is just off-screen.
Almost.
Enemies can still be active
and make noise off-screen.
I mostly use 3D audio for sound effects so
you might even be able to tell which direction and how far away it is, although I
won’t expect players to do that.
This means that knowing whether
there is an enemy nearby depends on how much noise it makes normally.
This is a slider I can adjust on a per enemy basis so I could have enemies that are easy to detect if
they frequently make loud noises, and enemies that are impossible to detect if they make no noise.
I think I’m happy with the current state of information for enemies you haven’t
yet encountered, but what about enemies you’re currently fighting?
There are multiple reasons why an enemy might be off-screen mid-fight.
Some enemies try to distance themselves from the player for a ranged attack.
Some enemies might outright flee from you, or you might try and flee from them.
Let’s see where this fits on the discoverability spectrum.
Interestingly, when an enemy is off-screen the information you know
about it doesn’t remain constant.
Shortly after an enemy goes off-screen,
assuming you have object permanence, you have a pretty good idea of where the enemy is.
However, the longer they stay off-screen, the less certain you’ll be about its location.
There are additional factors at play here though, such as the behaviour of the enemy
and how much randomness is involved.
If you were fighting an enemy that remains
stationary, then you can be reasonably certain that it will stay where you last saw it, but
aside from that, every other kind of enemy will eventually venture towards unknown information.
One problem I have with this is that it makes ranged combat difficult, both
to use and to play against.
An off-screen enemy is harder to hit with a
projectile, even if you know its exact position, and a projectile is harder to avoid if it’s
moving quickly and you couldn’t see the enemy’s animation signalling its attack.
Couple that with how much dynamic camera motion the game has and that gives
me a recipe for combat that is harder than I really want, so something needs to be done.
So what are some ideas to solve this problem?
Solution number one: I could zoom out
the camera far enough to encompass the range attack distance of every enemy.
This technically works, although it’s a bit of a blunt solution that causes
other problems if taken at face value.
Why?
Well, the more you zoom out the camera, the more information
that becomes highlighted to the player.
If you’ve already decided what a good zoom
level is for your game, then you might be giving the player more information than you
initially intended which is a balance issue.
It can also overwhelm the player, depending
on the information density of your game, although I don’t think that would be an
issue for my game in its current state.
The main problem I’m concerned with though is that
it reduces the visual accessibility of the game.
Zooming out the camera means everything you
normally see on the screen becomes harder to see due to its smaller relative size.
Except for these UI elements of course.
One thing I am considering though, is a mix
of dynamic camera panning and zooming during combat to keep nearby enemies on screen.
The shuttle is rarely on the exact centre of the screen so I think deviating
further wouldn’t feel too alien.
It’s a system that might require a lot of
balancing and playtesting to get a feel for what is a comfortable amount of panning
and zoom during combat, but it’s worth a try in the near future I think.
Solution number two: a minimap.
A minimap is a UI element that gives the player a
top-down view of the area around their character.
Sometimes it comes in the form of a radar
where you don’t really see landscape, and only blips of nearby activity, and
often it’s just a low resolution map.
This is a pretty common solution for 3D games
where you can’t see much of what’s behind you.
You sometimes see minimaps in 2D games like this
one, where it shows you a much wider area than your main screen view, but with much less detail.
I don’t think this is a solution I want to explore for Bottled Sky for one major reason.
A common complaint about minimaps is that if they are actually useful enough,
players end up just staring at the minimap instead of looking at the rest of the game view.
Not all minimaps are like that in my experience, but I am concerned that this is
a pitfall I could fall into given that this game is already top-down and 2D.
I am considering doing something like this, but only for showing audio sources nearby,
mainly as an accessibility option.
Solution number three: markers on the edge of
the screen that point towards nearby enemies.
This is what I ended up making.
These are UI elements that move around the edges of your screen and
indicate the direction of a nearby enemy.
When the enemy is on screen it disappears
so it’s otherwise unobtrusive.
There are a couple of problems still
so this isn’t my final solution.
Firstly, this does make it easier to aim
projectiles at enemies that are further away, but I still want players to be able to see what these
enemies are doing and be able to react sooner.
Trying to avoid projectiles flying at
you from off-screen is not really the experience I’m going for.
The other problem with this solution is that I now have to be careful
about overlapping with other UI elements.
I have some ideas to avoid that, but they all
come with trade-offs so I’m going to try this idea first and only revisit it if I have to.
So that’s my final decision on this topic; I’ll be combining screen edge markers, with
the dynamic camera panning and zooming.
This will only apply to enemies you are
directly in combat with and your camera won’t start panning around if you pass by
creatures that are idle or ignoring you.
I actually built the edge marker
system for a different purpose.
Because this game is set in space, there aren’t really any landmarks to help
navigate and find your way to destinations.
To solve this, I created a waypoint system
which uses these markers to point players towards where they need to go.
While making this system, I realised that it would also be useful
if I tagged moving objects like enemies.
So all of this was a nice, happy accident.
This feature isn’t finished.
You might have noticed the little stick figure
on the marker; it’s just a placeholder.
I want this image to represent what it’s
pointing towards so you can tell each marker apart when there’s multiple on screen.
I’m also considering having a distance counter for waypoints to destinations so players have
an idea of how long they’ll need to travel.
So yeah, look forward to that.
If you thought any of that was interesting then like the video and subscribe
to be notified about future videos.
Thanks for watching. That’s all
for now, and I’ll see you later.
