Annexation

At certain times, extra rooms are added to Black Annex during game-play. I actually cut this from the design doc about six months ago, but I was finally able to add it back in by piggy-backing on the system I build for spawning in enemies. It works in a much more complex way than the enemy spawn-in. With enemy spawn, there’s just an AI entity that’s invisible until it hears someone call for help.

When creating a new room, the clipping plane needs to be dramatically modified, and the zBuffer needs to be rebuilt as the room is spawning-in as well (the zBuffer typically only considers walls and static objects once when the level loads, and then never again because they don’t change.). There’s also the issue of “joining” tiles needing to appear to connect old rooms to the new ones, so certain wall tiles need to “listen” for a spawning room, and switch to a different type to connect to the new room.

In the video below, see how the new room actually “connects” to the old room, and a new window appears in one of the offices which wasn’t there before.

Communicating Control

Powering Up AbilityMost of the work lately has involved changing the way the player is shown how they’re interacting with the game. Use of abilities now has a totally different flow where that player can see how much ‘Juice’ their ability has left and the ability fails when they run out; an ability ‘Upgrade’ system ties into this concept.

I’m also trying to massively improve the menu system so it’s not so much about clicking on tiny little buttons, instead being a mostly drag & drop interface. I want to keep the menu system easy and also make it extremely clear to the player exactly what they’re interacting with.

Drag-and-Drop

Drag & Drop design is an absolute nightmare to work with, but it looks tactile and sensible when it actually works.

Changing Abilities

While play-testing your own game, it’s sometimes hard to imagine what a lot of your game’s features are going to feel like from the perspective of someone other than yourself. After a lot of play, I’ve decided to throw out a chunk of code regarding “Ability Cooldowns” simply because it’s no fun and doesn’t make immediate sense.

It can be kind of hard to accept that a ream of code you wrote might actually have no place in the game you’ve written it for, but it’s just part of “Making a game”, you put some code in, see if it works, and then change it if it doesn’t. The code I’m removing has been a core part of the gameplay for months now, but as the game’s changed slightly over time, I’ve created a much more relevant set of rules for how “Abilities” are used in a fairer and much more sensible way.

It’s become quite a challenge to communicate to the player exactly how “Abilities” work, especially when you have a full team of five creatures running about potentially all using different abilities at the same time in different locations. The player needs to be able to always see at a glance who is doing what and whether it’s working or not. I’m changing the way the “Solution” box at the top-right of the screen works so that it will show what abilities are currently being “Cast” and how long they’ve got left until they’re finished. Hopefully you’ll start to see this change in future videos. In the meantime, here’s some play-testing I recorded.

In other news, Man Fight Dragon has been accepted into the Indie Pavilion at PAXAus 2013 where I’ll have a little booth for people to come look at a game and maybe play it if they’d like to hunch over a monitor and keyboard.

“When you do things right,

people won’t be sure you’ve done anything at all”-God, Futurama

For a game to “Feel right” it’s important for the player to not quite be able to understand why the game play is as satisfying as it is, even when they’re losing at the game. When you deliver a “fail” or a “death” to a player, it’s important that they don’t feel like they’re being punished for the game’s mistakes; it needs to be their own mistakes. If a player is discovered by an enemy, you need the player to think “Whoops, I messed that up.” as opposed to “THAT’S BULLSHIT!”. When I play-test a small area, I have to think about what feels like it should work from a game-play perspective. This lead me to working heavily on the way in-game glass works.

The “Line of sight system” in the game is fairly accurate; it casts per-pixel rays from one pixel to another and fills isometric tiles along the way with creature vision. The problem is that it started to feel unfair when it seemed obvious that a player could hide next to a window frame while a guard looked out the window. Unfortunately, when the creature casts a cone of vision through the window, it can easily see someone standing next to the window.

It is realistic, but it doesn’t really feel “fair” when you’re standing in what seems, by “video game logic” to be a good hiding spot. I’ve had to spend hours now building a “blind-spot” system to make things feel much fairer in these situations. I’ve done this by treating glass windows like lenses that slightly bend a creature’s vision to create blind spots at the edge of a window frame.

<– Here is what happens when you try to sneak by some windows without Lens/Light Bending implemented.

And here is what happens with Bending. –>

This is something that the player will probably never notice exists, but when they run up next to a window to hide from a security camera on the other side, they’ll be happy not to be discovered because that’s how things should work in video games.

The Leaps and Bounds

I’ve been making lots of improvements to the game engine over the past couple of weeks and I just wanted to shoot out a few videos showing some of the new features that have been implemented.

The first is the new, smooth vision cones. Now, when a Creature wants to look somewhere, it isn’t able to instantly look at that new direction; it has to turn its head smoothly. This is fantastic for making sure creatures notice other creatures standing next to them when they’re changing direction.

These are the new class of unit called Sentry. They’re exactly the same as the “Enforcer” class (as in: they have guns, they run at stuff and shoot it) but they can be linked to a trigger and HAYWIRE!ed. If someone HAYWIRE!s them, they change their “Team” to the hacker’s team and immediately fight on their side. The one in this video has 9999 health so he easily wipes out the entire level.

And finally, this is the new “Spawn-in” mechanic and graphic. I can add creatures mid-campaign now with a little “drop pod” animation. You also notice the ground shake a little when they land thanks to the new Camera.VibrationStrength setting. Also, the game crashes if more than 20 creatures try to pathfind at the same time.

Thanks for watching!

Animating Behaviours

I’ve spent a lot of time recently finishing off a sheet of graphics for one set of human characters. Now that a lot of graphics are available, I’ve started adding in new animation routines to play-out in different situations.

Making these work has lead to the creation of new behaviours to go along with the graphics. Now, when an entity wants to react to a gunshot by returning fire, they first check if they can actually get a bead on their target. If they can’t, they will start running towards the place where the sound came from. As soon as they can see their target, they go back to walking and start shooting at it. If the lose sight again, they’ll run.

Lots of other little animation details have been worked in now; creatures always face the direction they’re shooting at, creatures play with computers while working on them, and a few other little details.

Here’s a quick video.

Building Better Bullets

I spent Friday building a stand-alone prototype for a completely new bullet/projectile system. The old┬ámethod was starting to become pretty unreliable and inaccurate for actual game-play situations, and there was no real way to draw a “Bullet” travelling through the game scene.

Now I’m actually drawing bullets flying along a path and checking for creature collisions along the way. It seems like an obvious way to do things, but when I was creating the old projectiles I was not familiar enough with how the game scenes were going to be processed, so it didn’t seem like this method would actually be possible. Now it’s fully implemented and working nicely.

I’ve also now made it so that bullets do not stop where you click to fire them, they go until they hit a wall or run out of momentum, meaning you’ll have to really think about what you might hit before firing a weapon in a scenario.

Potentially Boring

While making the “Popup” boxes work in a fully implemented way, I recorded ten minutes of my desktop footage just to show a little bit of my workflow. Most will find this kind of thing extremely boring, but some people might like to see how a game actually gets made.

The video basically shows the “Warm Up” bars being displayed when a creature doesn’t have the big popup box open over an object they’re working on. I wanted it to be clear that a creature keeps working on an object even after you close the popup box and go do other things. Once the creature finishes working on the device, a “Cool Down” bar appears over the device (This part was already working prior to recording).

Also, have a photo of my desk.

Bugs So Far

There’s a few bugs I’ve been noticing from time to time that have been really hard to sort out. For quite a while now, when creatures decide to use pathfinding, any other creature on the field who was already using pathfinding will suddenly forget where he’s going. If two creatures were trying to use get through a maze, they’d keep “stealing” the ability to pathfind from each other and running around at random.

Another issue appears sometimes where if the game is allowed to run for about 20mins straight, the player characters lose the ability to move completely. I have no idea what’s causing this, but it might be related to the pathfinding banks becoming completely unavailable or something to that effect.

Amongst other small functionality improvements, I’m making lots of small but complex map layouts to try out different situations and see if I can nail down these movement bugs. So far I’ve resolved to just give every creature their own pathfinding bank instead of having a shared managed pool of them to use. It means that if I have more than 50 creatures in a map, more memory will be used as the previous pool only allowed 50 pathfinders at a time, but overall I don’t think that’s a big problem. If it solves these bugs, I’ll be happy with it.

A new unrelated feature now is the ability for all creatures to move at speeds independent of each other, so one creature can run while another walks. I also added a new “Running” animation for this.