Friday, February 19, 2010
"No, we can't do it that way. If the player can get through by waiting until the guard's backs are turned, then the lesson doesn't work, it's not reliable. The idea with this approach- look, call them Tutorial Gates. You see them all the time in Valve games."
It's several hours past midnight, and I'm trying to articulate yet another game design concept which I've never consciously thought about before. I just noticed them at some point, and added them to my understanding of game design. This can make things rather difficult when I need to explain something counter-intuitive.
"They'll give you a crowbar, and then they'll immediately block your path with these flimsy wooden boards that you use the crowbar to break. You lay the game out so that the player has to learn the lesson in order to get past the barrier. It's a subtle way to teach someone how to play the game if you integrate it right, but it's also one of the most effective. So if we lay the level out like so, and the guards are always facing this way, then we can assume any player who has completed this level now knows guards can see you at any distance when you're in the light."
Patrick and I have been figuring out the early levels of the game, figuring it best to start with the levels that'll introduce each game mechanic- "Guards see you if you get too close", "guards see you at a distance if you're in the light", "crates can be pushed to create new shadows", etc. Once we've got a decent idea of how those levels will go and the order in which their elements will be presented, we can roughly gauge where other levels will appear based on which gameplay elements the player needs to understand to complete them.
Of course, as we're starting to lay these tutorial levels out there are multiple cases where I need to stop and check with Josh about precisely how some game element's going to work (or rather, see whether he can give me a reasonable guess or if we need to hold off on dealing with that gameplay element until later). For example, one part of the initial concept is to have some guards with crossbows (who will instantly shoot you if you're spotted) and some guards with swords (who move at twice your speed and try to chase you down). Obviously, this implies cases where a level can be completed in a way that involves being seen by a melee guard and then managing to escape them. But what were viable means of escape? If the guard sees me run down a dead end but I'm hidden in the shadows by the time he's looking into said dead end, is he going to move in and reveal me? In that case Josh and I wound up spending a good 10 minutes hashing out the concept for the guard's movement AI, with a final concept (a guard that shifts between four states, Patrol, Chase, Track, and Return) that was largely my proposition. This would be more impressive if we hadn't decided to cut melee guards altogether a few hours later, since they weren't worth the time it'd take to write all that relevant code.
Our plans for the game are steadily developing in response to new setbacks. The first fully developed concept we came up with for the core gameplay centered around moving crates so as to manipulate the areas of light and darkness and create a working path to the end of the level. Twelve hours later we'd completely given up on that, because we just couldn't get dynamic shadows working in flixel- meaning an object couldn't block a light source. Instead, we'd figured out a viable alternative approach using traps, which I had previously written off as a third-tier priority- if you give the player a light source they can activate and deactivate at will, and they can only see traps when the light reveals them, then you've got setup that's tricky enough to make for some interesting puzzles.
Ian continues to steadily work on his sprites, which is basically all that needs to be said about his side of things. The rest of us generally alternate between talking some issue out, hunkering down to work, and leaning back in our chairs to stretch, groan, and get lost in thought for a minute (or at least, that describes me). Ian keeps one ear on our discussions and just plugs away on whatever's needed next. We're very lucky to have him.