Here’s a little sneak peek at what we’ve been doing. Does it look comic-booky to you? Still some work to do, like retexturing the walls, the character, changing the HUD, etc. Wait until you see the pages flip…
In our minds, one of DBB’s biggest issues right now is that it looks kind of bland and generic at this point. The art is not bad, it just doesn’t have a specific and interesting style. Since we’re indies and we can do whatever we want, it’s kind of weird we weren’t pushing the graphical envelope.
Also, we’re sort of all over the place with what the story might be. Bones is chasing down his wife, who has gotten into some deep trouble somehow. There is a random spirit helping him (the player) who is somehow related. And no, the spirit is not his wife. We have some details here that we think are cool and fun, and a bit of dialogue written. But, just like the art style, it lacks a specific direction and most important it lacks impact.
So we’re looking at ways to improve both those issues. Step one is to turn this from a game with comic book cutscenes to a straight-up-diggity comic. The entire game takes place as a comic book story. Cool beans! And the main character isn’t some random spirit, but in fact is the animator. All this time we’ve been saying “you draw walls and jumps.” But now you literally draw walls and jumps.
The first step is to make the game look more like a comic book. We’ve decided to go drastic, and convert the entire game to halftone! So I wrote a nifty shader that does the work. Basically we want the game to look a lot like this classic Superman image:
It still needs a lot of work, but here’s some progress.
The above was my first go. It only has black and white halftoning, and it has no outlines or anything. You can tell it’s pretty difficult to make out, but it’s getting somewhere! The way halftone works is that the screen is filled with a bunch of dots, and the brighter something is the smaller the dot is. Look at Bones there and you can see how the white of his shirt causes very small dots.
Here’s the first shot at color! Using dots that are Cyan, Magenta, and Yellow (because old comics used CMYK printers), we can combine them to roughly produce any color. I also added some black outlines using object geometry, because otherwise it can be very difficult to make things out. The obvious weakness here is that everything becomes kind of uniformly washed out, aside from stuff that is closer to cyan, magenta, or yellow. Now you understand why old comics so often had characters with bright red, blue, and yellow outfits! Getting complex colors out of an old CMYK printer is difficult. The browns and tans above all look kinda bleh.
I experimented by dropping a yellow-orange cube in to see how it looks. The result is a gorgeous looking effect, basically exactly what we’re looking for.
That led me to try out making the walls a solid teal-green color. I think they end up looking great. With some gradient-like details, they’ll look much better I think.
Next I decided to see how things would look if I used Red, Green, and Blue dots. These are the color components that computers use to represent every single color you see on your monitor (and are the primary colors of light). Unsurprisingly, the image looks significantly clearer. The big problem now, though, is that the nifty effect is lost – it just kind of feels like a crappy filter over a normal game.
If you look at cool modern comics like Sin City, they generally have a few colors that really pop because they are sparsely used elsewhere. I decided to try doing this with specific colors. Here is when black or close-to-black are rendered solid (not using halftone). It’s definitely a little heavy.
And here is when we exclude solid red. I like this much better, and it’s more in line with what classic comics looked like.
Here is the final place we’re going to leave it for now. Anything that is close to one of the “primary” colors (that is, C, M, and Y, perhaps K (black) ) is excluded from the halftone. This makes the coins look particularly interesting because they stick out so much.
What do you guys think of this style?
The cornerstone of Death Boulder Bones’s uniqueness is how you control the character, or rather how you don’t control him. Drawing walls nearby to encourage him to turn this way is a mechanic that hasn’t, as far as I know, been used in any game to date. But, Dr. Indie Bones is a stubborn guy and is also pretty heedless of danger, so he makes little to no decisions on his own. I guess that’s what happens when you’ve had a benevolent spirit preventing you from getting harmed during your entire life.
Most players aren’t going to read that little bit of story, however, so instead they’ll just have this guy in their hands who seems to make all the worse choices. Why does he blindly run into lava, traps, and certain death? In our current implementation of the game, the player often wonders this. For the most part, that’s okay. Assuming our tutorials are good enough, players are generally willing to accept certain tropes and idiosyncrasies as part of the gameplay. Okay, this guy is going to just go blindly ahead, and I’m the only thing stopping him from death. That’s cool. How would the game be any fun if Bones was able to navigate the level entirely on his own?
But. This really breaks down when the character tries to get Bones to do one thing, and they expect him to do that thing, but then he goes and does something else entirely. Defiance of a player’s expectations is 100% a bad thing unless it’s done purposefully to accomplish some other thing. In our case, it’s pretty random, and no bueno. One thing we’ve constantly been told by people who play the game is that there are instances when Bones will, for no clear reason at all, go the “wrong” way.
Well, what is the wrong way? Good question. That might be sensitive to context, or it might be an overall feeling. As a result, I’ve spent a lot of time and talked with a lot of smart people to try to get a feeling for what they expect. Because then even if Bones does some totally wonky stuff, as long as the player expects it then that’s totally okay. Before I go into the approach I decided on, let me lay out the past.
The History of the Steering, and of Death Boulder Bones
Believe it or not, this 3 raycast approach, albeit with a little tweaking, is the exact one currently in Death Boulder Bones and is what we used when competing on The Next Game Boss. Why? Because, or the most part, it works. But, it works only when the walls are drawn close to or out of Bones’s vision (in other words, beyond the reach of the raycasts). If you draw a wall very close to him, it’s likely all 3 raycasts will hit, and then the way he turns can be determined entirely by minute angles in the wall or in Bones himself. That means that, every once in a while, he’ll do something you don’t expect and it will drive you crazy.
A Better Approach
Because Bones is the only one at any time who is pathfinding, I can make him do it in a far more complex manner and not care about performance. As a result, I’m not worrying so much about how many rays I’m casting or how complex the logic is. He needs to be predictable, and he needs to just work. So for this next implementation, I’m going for a more usual steering approach.
Usually, steering is combined with something like A* to get several destination nodes and then steer between them. The thing about Bones is that he has no destination. In parts of some levels he has a “preferred” rotation that he sort of rounds to, but otherwise he has absolutely no knowledge about where he is going or why. That means that finding the edges of obstacles he raycasts against and choosing the shortest way around just doesn’t make any sense to do. Because maybe he doesn’t want to go around the wall? What if we want to make him turn to the left or right instead?
This means I can’t use the usual way of steering at all. Instead, it needs to be something that causes course adjustment but doesn’t rely on having a goal of any kind. In the previous iteration, Bones would turn away from walls that were on his left or right but not in front of him, due to those 45° rays. This allowed for course adjustment without directly inhibiting his movement, which was a definite plus.
I’ve decide to experiment with losing that, and instead only making him turn if something is directly in his way. This means a few raycasts pointing straight forward and at the full width of Bones (so he can’t squeeze through spaces smaller than his waist). If those casts see nothing, he continues forwards. If they do see something, then he sends casts in a full 360° arc around him. Whichever direction is the most clear – left or right – is the way he turns.
At the very least, this approach should be predictable. No matter what, Bones will go towards the nearest empty path. It also allows me to play more interesting animations, like an “aaahh I’m surrounded!” animation when he’s completely enclosed in walls, and a “ouch I ran into a wall” animation when one suddenly sprouts in front of him. It will also allow him to run closely parallel to walls, which he couldn’t do before. This could cause weird seesawing when walking in narrow passageways (move to the left to get away from the right, now move to the right to get away from the left, over and over again), and other problematic stuff.
My main worry is that he loses some of the “flee” steering response that he previously had with 45° rays. Will it be annoying to need to completely obstruct Bones’s path to make him move, or will it feel more natural? The only answer is to try it out. If it is a problem, then I’ll just have to try a combination of the old approach and the new one.
What we went with
Eventually, we settled on combination approach. Bones casts out a bunch of ray pairs in a 360° arc around him, currently there are 8 separate pairs (so at 45° angles). He then uses a combination of whether the rays hit obstacles, how far they hit, and which way he is currently facing versus what way the ray is going, to create a single weighted cost value. Eventually, he decides which value has the lowest cost, and he turns towards that angle!
Walls have a huge cost – if a direction hits a wall, he’s not going to want to head that way. Angle changes are also costly, but not as much. In general he wants to keep going straight, but if there is a wall in his way he’ll definitely turn to try an alternate route. When he’s completely surrounded by walls, he’ll basically just go towards whichever area has a wall that’s farther away.
This didn’t quite work, so I actually added one last step. Once he has chosen a direction, if he’s facing that direction or almost facing it (in other words, if he’s freely running with nothing in front of him), then he’ll cast out a couple rays to his sides. If either ray hits a wall, he’ll eke a little bit away. This encourages him not to hug walls, but instead to keep a reasonably distance from them.
Back in the day, Grandendroit was not Grandendroit. It was two guys, Eli and Seth, trying to maybe get some games out there. I have pretty much always been working on games, even though I didn’t do it via video games until I was 11, with a sweet TI-83 game called “Fight!”. As a result, I decided to take one of the most fun game prototypes I had worked on, “Sinuosity” (from 2008), and turn it into an iPhone game. I really felt like it could fill a niche and regardless was super fun. You can have a look at Sinuosity here:
Our idea was to spruce the game up by making it pretty, giving it a story, and polishing off the rough edges. We discussed theming ideas and eventually came up with the thought of making it take place in a super hero universe. We named it Lab Rinth. We named the country in the game Grandendroit. The main character became a wannabe superhero and the bad guy a super villain. Cool beans. We wrote a script, did some art, did a lot of code, ported the game to Unity, and more. We spent over a year on it, in fact.
In many ways, Lab Rinth is sort of a more lite and casual Diablo. The enemies in the game were damn good at finding the player. They would use A* pathfinding to home in on the player and move exactly to where they were, even if they were on the other site of a wall that was 50 spaces of running around corners away. This was both inefficient and also semi-lame gameplay. As an experimentation, I wanted to see if they’d be more interesting if they were dumbed down a bit to simply have a steering algorithm. So they’d move in the general direction of the player and try to navigate around walls and like naturally as they turned.
The finer points of the pathfinding will be discussed in a later post, but the end effect was that I found the results very interesting. I noticed that if I dynamically moved the walls around while the characters moved, they reacted in emergent ways. It was almost like you could control them without actually controlling them.
The timing was right, because soon after there was a Ludum Dare 48 hour game competition. When the theme was announced as “Escape” and I already had these characters that simply run forever, I thought I had a great idea. Why not draw walls with the mouse so that they dynamically steer, and also block traps and things like arrows as they are fired? That turned into the 48h game, “Death Boulder Jones.” Sound familiar?
Soon after the competition was over, we realized that Lab Rinth was super ambitious for two guys who were working part time. Even though we got help from some other artists (Darrell included), the going was quite slow. It also is much less of an attention grabber than DBB in a lot of ways, because it doesn’t bring as many big new ideas to the table. So it was that we tabled Lab Rinth temporarily and decided to spend “just like 3 months” on our game Death Boulder Bones to get a game out there.
That was September 2011. If you’re counting, it’s now over a year later and we’re still working on it. The current charted release is July. But, I think that’s good. Instead of rushing out this hokey little game prototype, Death Boulder Bones is now a totally awesome full indie gaming experience.
Welcome to Grandendroit! We make games! Currently we’re making Death Boulder Bones, a rockin’ game where you control the environment instead of the character. We will soon appear on The Next Game Boss season 2! How did we do? You’ll have to see!
Watch for an upcoming Kickstarter.