Another one in the can

Well, there's the sneaking game. Or, rather:

http://www.bigdicegames.com/SafetyLast/safetylast.html

there's the sneaking game. It's got 5 levels, which you can play through with one guard per level, which is pretty easy, or three guards per level, which can be pretty challenging. I'm not actually sure if you can beat the game - three guards is pretty unforgiving, especially on the big, open levels, or the tight levels.

Things I got in since my previous post (12-ish hours ago):

• Crazy Ivan. Every now and then (between 4 and 14 seconds, or thereabouts), a patrolling guard will stop and turn to a random direction, which might be more than 180 degrees from his current facing. Assuming he doesn't see you, he'll return to his original direction and proceed with his patrol. Just like tailing a Russian sub, you don't want to get too close to a guard, especially if you can't duck for cover quickly.
• Patrol Route Recovery. I'm not sure it feels right, yet, but when a guard decides he needs to return to a patrol route, he finds the closest waypoint that he can see, then traces forward to find the last visible waypoint after that. It feels OK, but I'd rather have dynamic patrol routes, which would make this less important.
• Title Screen / Instructions / Credits. I ported the game into my old codebase that I've been bringing forward (code reuse!) since January. This required a certain amount of cleanup and general "paying down of technical debt". It's still a nightmare, but it's a little better than before
• More levels. Well, it had been better - introducing more levels is a huge hack that involved duplicating code because I couldn't be bothered to do it more cleanly. That's the nature of pushing on a hard deadline.
• Visual cleanup. The grey dots that had been illustrating the patrol waypoints are now hidden. Now, the game reminds me a little bit of Berzerk, or Armor Attack. I had thought that I'd make some 8-bit retro pixel art sprites, but not this time around.

It's satisfying that this one's "complete". There's a lot that I'd like to do, but the fundamental framework is there for me to come back to later. Or, maybe, I throw out the framework and draw from the lessons learned. I should really write down lessons learned, if I'm going to do that, because I doubt I'll remember.

I'm kind of thinking of taking bits of this forward into my next game, which if I get time and energy to get WebGL up and running, will be some sort of 3D game. Or, if I don't get that working to my satisfaction, I could hack together a raycaster and have a 3Dish sort of game, which would still be OK. I'm not sure I like the idea of trying to get perspective-correct texture mapping working in JavaScript.

Whew.

This marks halfway through the One Game A Month challenge, and I'm pleased to have made it this far. I've turned in some pretty sloppy games, but always something game-ish, and a variety of different games. I have a couple of bigger games that I want to work on after this is all done, and one of the things I was hoping to get out of 1GAM was a toolbox of code that I could reuse. I intend to be more deliberate about identifying useful technologies and working them into the next 6 games.

Sneaking progress

New screenshot:

First thing this morning, I've knocked out the difficult / boring / tedious bits:

• Guard as its own object. When I first wrote the code, I was on a plane, working on a netbook, so I didn't have big monitors to make organizing my code easy. I've finally ripped all of the guard's code out of the main file and into a guard object. Not visible, but important for the next pieces.
• Multiple guards. Following on the above refactoring, I was able to have more than one guard patrolling the level. The difficulty jumped up substantially.
• Guard visibility arc. You can see yellow sectors in the screenshot above; that's where the guard can see. Well, the guard can see farther, but just in the indicated direction. Perhaps I'll want to adjust either the display or the visibility calculation This turns the difficulty down, as you can now sneak behind guards and between them.
• Guard turning speed. Guards now turn at a maximum of one radian per second. I put that number in as a starting point to tune from, but it feels OK.

Next up:

• Crazy Ivan. My current thinking is that the guard will have a random fuse, and when it expires, he'll turn to a random direction. This won't necessarily be a full turn; perhaps just a small turn to the left or right. If he turns and doesn't see anything, he'll turn back to his patrol route.
• Smarter / Lazier guard recovery. I'm still thinking about how to get this to feel right. Maybe take the closest waypoint, and look ahead to see if the following points are visible.
• Game modes. Game over, title screen, and so on.
• More levels. One cheat I might do is have a single level with different patrol routes or different numbers of guards.

Sneaking: well, it's technically a game now...

There are a lot of important points in the life of a game. One point is when you stop working on it. One point is when you ship it. These may not be the same, especially if you're working on an online game.

One important point is when the team actually has fun playing the game, and stays at work playing the game instead of going home. Not all games get to that point. Most don't, I'd wager.

One point that I know I always was searching for on previous projects is the point when the game is "fun". It's hard to know what that means, and pieces of the game might be fun early on, but making the whole game fun is tricky.

Well before any of these points is a point where the player was some in-game recognized notion of success and failure. In some games, these may be vague - for arcade games, failure is the "GAME OVER" screen that tells you to put another quarter in. For console games, you may not have as clear a failure mode - just get knocked down and start over. Maybe you go back to the beginning of the level. Console games often have a clear ending point - defeat the final boss, the credits roll, and you walk out to the kitchen because who reads the credits?

Even though I know that my little sneaking game isn't going to have a lot going for it by the end of the month (still got 27 hours), but it's got success and failure finally.

What you see here is a maze (green boxes) and a guard (green dot) as well as the player character (pinkish dot) and an exit square (pink box). Get your guy down to the lower right hand corner of the screen, and you win. But the guard might see you, as he does in this picture (blue line). When the guard sees you, he runs faster than you do, so you don't want to let him see you too often.

There are several things I want to get in to the game before I call it quits:

• Proper "game over" logic, and probably a title screen. I know how to do this stuff, it's easy, it's just getting around to doing it, which may mean refactoring the code I've written. (It's a mess.)
• Multiple levels. I was thinking of doing 10 levels. I might get 3 written. They're not hard to make, really, so 3 should totally be doable. Maybe even 10, if I get everything else squared away. Heh, squared. Like boxes. Ehhh, maybe I've spent too much time at the computer already.
• Multiple guards. Again, a little bit of refactoring will be necessary - right now the guard is a mess of global variables. (Bad!) Having multiple guards to contend with will make the game harder.
• Limited visibility arcs for the guards. Right now, the guard has 360 degrees of visibility, so you can't really sneak up behind him. If I narrow this down to, say, 120 degrees, it'll make the game easier, so this should go in along with having multiple guards.
• Turning speed for the guards. The guard currently has no notion of "forward", he just gets pulled toward his destination. That destination can jump across the level, and does - for instance, when the guard sees you; he immediately heads in your direction. I'll need to give the guard a heading in order to have visibility arcs, and shortly after that, I'll add in a turning rate.
• Lookie-loos. Right now, the guard's patrol route is a little boring - he just plods along in a straight line toward his next waypoint. I have this idea of inserting points where the guard stops and turns around and looks behind himself, which would be a good thing for a guard to do, but would make following a guard a really dangerous thing to do. I can insert this as explicit turns in the patrol path, or I could give the guard a random fuse that he'll occasionally stop and check his six. Maybe I ought to call that the "Crazy Ivan".
• Cleanup? Those grey dots you see in the screenshot - those are waypoints for the guard. Handy for me as a developer, maybe useful for the player... maybe too useful. Maybe confusing. I think I ought to take them out. You know, when I'm done with everything else.
• Smarter / Lazier guards. That sounds weird. Right now, if a guard loses the player, he'll head to the last place that he saw the player, which means he's got a limited ability to chase around corners. One corner, really. As soon as he loses the player, he goes back to patrolling, starting with the "next" waypoint that he can see. This may be way back across the level - which seems weird in some circumstances, like if the guard breaks off chase with the player, then returns to a waypoint to the south, but the next waypoint is north of the break-off point; the guard executes a weird 180 degree turn, retracing his steps. Probably makes sense to check what the "last" waypoint in view is, and then maybe consider the closest waypoint, or something that looks smarter.

There are a few things I won't be getting to, I'm sure:

• Pretty graphics. Sorry, not happening in time. Maybe the player and the guards will become stick figures. Don't get excited.
• Sound, Music, Score. Feel free to hum and make your own sounds. And award yourself points.
• Dynamic Levels. Yeesh. Procedurally generated levels would be nice. 
• Dynamic Patrol Routes. This would kind of need to happen with dynamic levels.
• Pickups / Powerups / Rich Environment. One thing that I thought of doing early on was to give the player two things to do on the level before getting to the exit. Like picking up a rope and opening a window. There will be no ropes and no windows. I also thought that maybe you could pick up gold, or somehow get points for traversing the whole of the level. I don't see that happening, either. A long time ago, I had an idea for a similar game, and in that game, there would be things like squeaky floorboards, which would bring the guards running. Not in this game, though. Maybe later. If I were to return, maybe I'd create some powerups to help the player out. Super sneaky limited use shoes. Or smoke bombs. I'm not sure.
• Level Countdown Timer. Actually, maybe I can get that in. That'd really ramp up the difficulty. But it also kind of pushes against the sneaky feeling of the game. Maybe I award bonus points for the timer, and let it go to zero without killing the player, just don't award any points past a certain time. That could be OK.
• Guards coordinating their patrol routes. Imagine a randomly generated map, with randomly generated patrol waypoints. It'd be good if the guards covered these in a somewhat intelligent (appearing) fashion. Several years ago, I fiddled with a similar system where the guards would seek out waypoints that hadn't been visited recently. There was nothing keeping the guards from clumping up and patrolling in a gang, which wasn't what I had in mind.

More Sneaking

When I last updated here, I had a guard patrolling around the center pedestal of this space, and the player's character could move around the space, trying not to be seen. Thing was, I had some weird flaws in my raycasting math, and the guard could see the player when he shouldn't have been able to. I looked around, and found a number of different implementations of line segment intersection tests (seems like a while ago, it was easier to find good intersection tests online - have things got worse?) which I coded up bits and pieces of, and eventually came up with one that I liked.

Today, I added in a notion of a "patrol path", an ordered sequence of points that the guard would march along. The way that works is that there's an index of which point the guard is trying to reach. If the guard is close enough to the destination, increment that index. If the guard can't see the destination, increment the index. This suffices (for this map) to give the guard pretty reasonable patrolling behavior.

On top of this, I also check to see if the guard can see the player. If so, rather than moving towards the next patrol waypoint, head toward the player.

This provides a small amount of tension, and you can now "sneak" around the level, timing your darting from one occluded area to another. If the guard sees you, you can dart back into a shadow, which leaves the guard to pick back up on his path. That's not so satisfying, so I'll come back to that later - my plan is to have the guard drop a cookie crumb at the last spot that he saw the player, and chase that in absence of having clear line of sight - this should allow the guard to do some simple chasing around corners.

There's no actual "win" condition yet, and the "lose" condition might be if you want to say that when the guard reaches you, you're "out".

I had planned to have fancy art, and I might still get around to that, but I might stick with abstract representations in order to get something done by the end of June. I've got less than a week. Yeesh.

Beginnings of a Sneaking Game

Inspired a bit by Monaco as well as the movie Safety Last, I've been working on a game where you attempt to bypass a guard.

I'll admit that the connection to Safety Last seems tenuous right now. Perhaps I'll bring it together by the end of the month.

So far, the player (the pink dot) can move around the level and bump into walls. The cop (green dot) patrols around the center of the level.

It won't be hard at this point to add in a ray cast from the guard to the player to see if the guard can see the player. After that, adding in some better AI for the guard will consist of:

• scripted patrol path - right now, he's on a circular track, moving at a constant velocity. I imagine him having a series of waypoints, with ability to stop in place and turn to face a specified destination (usually his next movement waypoint, but adding in times when the guard loops the opposite direction will make him harder to evade).
• Pursuit - when the guard sees the player, the guard will break off his scripted path and follow the player. If the guard loses sight of the player, I want to have him head to the spot where the player was last sighted, look around, and if there's nothing there, then break off pursuit.
• Return to patrol - this might be the trickiest part - being able to navigate back to the patrol path and pick up the patrol script. I could do a pathfinding approach, which would be complex, but fun to implement (I hope), or I could do something simpler, like dropping breadcrumbs during the pursuit, and then following them backwards to retrace the guard's steps.