Slender is, by far, the most horrifying game I've ever played. It's the first game since Resident Evil 2 that I've been too scared to continue playing, and it was much more efficient at doing so. My first attempt to play ended in under a minute, chills running through my spine. Nothing has given me chills like this to me since I was a kid watching The House on Haunted Hill. It's an amazing and free experience - go download it if you're feeling particularly brave.
What is it?
Slender is a first-person survival horror game in which the player is searching for eight mysterious pages from a fenced off section of woods at night. All the while, there is a sole enemy hunting you - the Slenderman. The Slenderman is a modern fireside ghost-story myth, a phantom in the woods born from the internet. There's very little to know about the Slenderman, but all you need to know to play Slender, is that it is hunting you.
The gameplay itself is simply an exploration of these dark woods. You have a flashlight and nothing else (more on this later). You have no direction aside from a readme file detailing controls and the task at hand: Find the eight pages before the enemy gets you. However, this simplicity has a great layer of depth hidden underneath.
I called this game a survival horror - that means that there are limited resources that the player must manage in order to survive. There's an economy here with various currencies: Flashlight battery, maximum stamina, and health. The flashlight battery slowly drains while in use, maximum stamina is lowered by running, and health is lost when looking at the enemy. However, it gets deeper.
The flashlight keeps the enemy at bay. While looking at the enemy with flashlight on, the enemy stays in place. With the flashlight off, the player is more easily captured, but looking at the enemy costs less health. Running is the only way to get away from the enemy when he gets close, but every sprint costs stamina. Running away too much leaves the player incapable of running. Looking at the enemy offers you a time to get away, but it costs health. There's a lot of balancing of resources - and they're all being balanced against your fears.
Why is it so scary?
First of all, the first-person perspective is a horrifyingly claustrophobic experience - it's like wearing blinders, killing off peripheral vision. When the player enters a building, their sight is tremendously limited, and the enemy could be lurking around the corner. To gather a page, the player's entire view is taken up by the page and the wall it's on. This limited view makes the player realized just how much they don't know about their surroundings.
Also from the first-person perspective, everything that happens to the character happens to the player instead. It sells the experience, because the player can't step back and say, "Oh, it's just happening to Murphy." No, there's very little disconnect here - it's happening to you. You are in the woods at night. You can't see around the corner of this building. You are hunted by the Slenderman. You don't know where he is. You are the target.
Sound is tremendously effective. There's a lot of silence in the woods. Most noise comes from the player's footsteps. There's an ambient forest track playing throughout. As the player gathers pages, throbbing ambient music layers on itself, building the horror. Meanwhile, the Slenderman is lurking in the darkness silently. If the player turns the corner and the Slenderman is suddenly there, a harsh piano kicks a deep note, selling the jump-scare. With so little sound, every element has incredible strength.
The Slenderman's movement takes place out of the player's view, silently. This leads to a lot of unknowns about where the enemy is, and people generally fear what they don't understand. This is surprisingly effective at keeping the player from looking around. I never turn around while playing, making wide turns to avoid the possibility of finding the Slenderman suddenly behind me. Not knowing that he really is there is just as terrifying as if I were to turn and see him just behind me. Not understanding his movement algorithm fully is horrifying. Does he move slowly out of the player's view, slowly tracking the player? Does he just teleport every now and then? It's an unknown, and that scares people.
All in all, this is a package of horrifying unknowns built around a modern ghost-story with a very intricate survival economy. Again, it's free to download, so go download and play it - if you can handle the void of those dark woods.
Monday, July 30, 2012
Monday, July 23, 2012
Postmortem: Summer Game Jam
During the first two weeks of July, we had ourselves a game jam at work. It was a truly awesome experience, one that every game studio should make time for at least one week out of the year. There was so much renewed energy, so much fresh air, and so many lessons learned in such a short time. All in all, it was invaluable.
Our Method
The game jam event was announced without warning at our weekly meeting early on a Friday. Basically, we were told that Windows 8 is a big deal, so our studio should check it out. For the rest of that Friday, we were given a few setup tasks, and even fewer rules:
In my case, we had a team of six (three programmers, two artists, one designer). However, the first week was also the first week of July, so two of our team members were out for half the week. We had decided to work on a simple plane game, where you build a plane and it flies differently depending on the parts used. This core concept was the primary focus for the first week, with little to no focus on the gameplay of actually flying the plane.
With a four-person team (two programmers, one artist, one designer) during the first week, we were really able to keep communication solid, open, and smooth. With two programmers, we were able to divide tasks up completely - I handled the plane building, while the other programmer focused on flying the plane. Our artist kicked ass, and our designer found some critical flaws early on by mocking up the build scene in Excel. We had a strong finish for that first week.
[Quick side note: We decided to use HTML5 and Javascript for our game, which none of us had used before. This decision was largely based on the opportunity to try out new things, but was aided by the example code available online.]
The second week didn't go nearly as well for us. With a third programmer and a push to include combat, we had a fair amount of work ahead of us without a clear division of work. I was delegated to the user interface, the flight programmer continued tweaking the flight model, and the returned programmer volunteered for getting the enemies in. It seemed like a simple division, but it quickly turned into a tangled mess.
With each of us working on the game scene, we stepped on each others' toes a fair amount. Our returned third programmer hadn't had a full week to approach Javascript, so his ideas for an enemy architecture were based on incorrect assumptions. All in all, we had me trying to grab any task available, and two programmers working on overly complicated systems for such a short development time that didn't have anything to give. Once the basics of these architectures were finally put together, it was Thursday, and the code was a convoluted, overcomplicated mess. By Friday, our enemies were shooting, but they weren't visible. At least the UI was good and solid.
The Good
Let me stress just how great of an experience this was. Even though our game ended up crashing and burning in the final hours, we learned such an invaluable amount through this process.
We learned the importance of enabling designers as early as possible - our designer was far too often spinning his wheels with little to work on while waiting on code. If we had geared ourselves toward getting him set up, he would have had content churning out consistently as we got the rest hooked up how we wanted. In short, figure out what the designers need to give you and how they'll do so, then build functionality and architecture to use that input. This will get programmers and designers working in parallel. This also works with artists, by the way.
Speaking of artists, just let them play and make as much content as they want. While you may not be able to put everything into the game, artists seem happy to just keep "arting" away as long as you do your best to show off their work in game. This worked really well for us, especially since the artist working on the build scene sits at the desk next to mine. Whenever he had something he was happy with, he was able to grab my attention for a moment to make sure everything would work in game. Alternatively, when I needed him to make sure I had everything right in game, he was right there. So there's another lesson - keep artists and programmers near each other when they're working on related tasks.
As for programmers, it's important understand scope and the goals at hand. Focus on what the content of your game is, why you're making it, who for, and otherwise get into the mindset of the designer every once in a while. Don't hold onto complicated gameplay systems that are not fun or understandable for the player. Don't complicate your architecture when the lifetime of your engine is two weeks. All in all, build the right software for the task at hand. If that task is a game jam, forgo writing perfectly correct code for code that works and takes half the time to implement. If the product of your game jam is to be further pursued as a full product, you'll probably need to rewrite everything anyway. If you're building something to last, that's when you write code to last.
Overall, this game jam was a blast. It was a breath of fresh air and the boost in the team's energy was amazing. Jamming got everyone excited and invigorated. You could feel the difference throughout the studio, and every team member felt vital to and ownership of their project. That's just something that doesn't happen as much on large products. Quite frankly, it was all about having fun.
The Bad
Part of our game jam involved installing the Windows 8 preview. This was to check out just how well everything we use for "real" work plays in the newer environment, as well as to just jump into the operating system and get some experience with the differences. However, that meant that if we needed to go back to Windows 7 after the game jam, we'd need it to still be there. Unfortunately, some of us used a slightly different installer that didn't give us the option to install to a different partition, wiping out our Windows 7 and upgrading it to Windows 8.
This would not have been so bad if Windows 8 agrees with all of our tools instead of one tiny detail - our internal test network doesn't acknowledge users trying to connect to our game (the real thing does work, though). This meant that those of us that used that specific installer needed to reinstall Windows 7 and nearly every program under the sun (that's how it feels to reinstall all the tools we use on a regular basis). Seems safe enough, but then there was the one person who reinstalled, but then was unable to connect to the network fully, keeping a developer from getting back to his day job for an extra week while working with IT to figure out the minute yet significant detail that wasn't in order during that installation process that flagged his computer as unsafe for the network. In case you haven't guessed it, that developer was me, and that process was just not fun. However, it did provide ample time to write about the game jam experience...
Another issue was the Monday after jamming. You could feel the complete and utter lack of energy as everyone got back to their day job. We went from a bustling, excited studio to one of morbid silence in the matter of a weekend. The feeling was palpable, yet difficult to describe. It's kind of like the end of The Graduate when Ben and Elaine get on the bus. They're exhilarated and laughing, but then their reality sets in during the span of moments. Their smiles fade, they try to hold on to that excitement, but it's futile. Their life will come to some form of normality. That return to normality from such a different world is jarring.
In Conclusion
While the fallout from our game jam cost me a week of work and a day or two of studio-wide regulation, the experience of those two weeks was incredibly inspiring and powerful. It was a compressed learning experience that got the studio's blood flowing. It let us shine where we wanted to, work on what we wanted, and really feel ownership over a product - something that just doesn't seem to happen on a large project. Every studio should make the time to game jam - it really let's everyone play at game development and discover just what they're capable of in a short time, and that's just too powerful an experience to pass up.
Our Method
The game jam event was announced without warning at our weekly meeting early on a Friday. Basically, we were told that Windows 8 is a big deal, so our studio should check it out. For the rest of that Friday, we were given a few setup tasks, and even fewer rules:
- Wrap up "real" work: Basically, to put everything on hold for a week or two, we needed to get it wrapped up nicely. This consisted of backing up work in a safe place, getting stuff checked in, and otherwise making sure the "real" work would be there when we got back.
- Divide into teams: Team building was given the most rules of our game jam. We needed two to three programmers per team, and teams could have up to six people each. We were also encouraged to work with others we don't normally work with. This gave us about nine different teams.
- Install Windows 8 and tools: This task is fallout from the core goal of our game jam: Each team was going to make a Metro-style app for Windows 8. That was our only development rule, so it was important to get the environment and tools ready for Monday.
In my case, we had a team of six (three programmers, two artists, one designer). However, the first week was also the first week of July, so two of our team members were out for half the week. We had decided to work on a simple plane game, where you build a plane and it flies differently depending on the parts used. This core concept was the primary focus for the first week, with little to no focus on the gameplay of actually flying the plane.
With a four-person team (two programmers, one artist, one designer) during the first week, we were really able to keep communication solid, open, and smooth. With two programmers, we were able to divide tasks up completely - I handled the plane building, while the other programmer focused on flying the plane. Our artist kicked ass, and our designer found some critical flaws early on by mocking up the build scene in Excel. We had a strong finish for that first week.
[Quick side note: We decided to use HTML5 and Javascript for our game, which none of us had used before. This decision was largely based on the opportunity to try out new things, but was aided by the example code available online.]
The second week didn't go nearly as well for us. With a third programmer and a push to include combat, we had a fair amount of work ahead of us without a clear division of work. I was delegated to the user interface, the flight programmer continued tweaking the flight model, and the returned programmer volunteered for getting the enemies in. It seemed like a simple division, but it quickly turned into a tangled mess.
With each of us working on the game scene, we stepped on each others' toes a fair amount. Our returned third programmer hadn't had a full week to approach Javascript, so his ideas for an enemy architecture were based on incorrect assumptions. All in all, we had me trying to grab any task available, and two programmers working on overly complicated systems for such a short development time that didn't have anything to give. Once the basics of these architectures were finally put together, it was Thursday, and the code was a convoluted, overcomplicated mess. By Friday, our enemies were shooting, but they weren't visible. At least the UI was good and solid.
The Good
Let me stress just how great of an experience this was. Even though our game ended up crashing and burning in the final hours, we learned such an invaluable amount through this process.
We learned the importance of enabling designers as early as possible - our designer was far too often spinning his wheels with little to work on while waiting on code. If we had geared ourselves toward getting him set up, he would have had content churning out consistently as we got the rest hooked up how we wanted. In short, figure out what the designers need to give you and how they'll do so, then build functionality and architecture to use that input. This will get programmers and designers working in parallel. This also works with artists, by the way.
Speaking of artists, just let them play and make as much content as they want. While you may not be able to put everything into the game, artists seem happy to just keep "arting" away as long as you do your best to show off their work in game. This worked really well for us, especially since the artist working on the build scene sits at the desk next to mine. Whenever he had something he was happy with, he was able to grab my attention for a moment to make sure everything would work in game. Alternatively, when I needed him to make sure I had everything right in game, he was right there. So there's another lesson - keep artists and programmers near each other when they're working on related tasks.
As for programmers, it's important understand scope and the goals at hand. Focus on what the content of your game is, why you're making it, who for, and otherwise get into the mindset of the designer every once in a while. Don't hold onto complicated gameplay systems that are not fun or understandable for the player. Don't complicate your architecture when the lifetime of your engine is two weeks. All in all, build the right software for the task at hand. If that task is a game jam, forgo writing perfectly correct code for code that works and takes half the time to implement. If the product of your game jam is to be further pursued as a full product, you'll probably need to rewrite everything anyway. If you're building something to last, that's when you write code to last.
Overall, this game jam was a blast. It was a breath of fresh air and the boost in the team's energy was amazing. Jamming got everyone excited and invigorated. You could feel the difference throughout the studio, and every team member felt vital to and ownership of their project. That's just something that doesn't happen as much on large products. Quite frankly, it was all about having fun.
The Bad
Part of our game jam involved installing the Windows 8 preview. This was to check out just how well everything we use for "real" work plays in the newer environment, as well as to just jump into the operating system and get some experience with the differences. However, that meant that if we needed to go back to Windows 7 after the game jam, we'd need it to still be there. Unfortunately, some of us used a slightly different installer that didn't give us the option to install to a different partition, wiping out our Windows 7 and upgrading it to Windows 8.
This would not have been so bad if Windows 8 agrees with all of our tools instead of one tiny detail - our internal test network doesn't acknowledge users trying to connect to our game (the real thing does work, though). This meant that those of us that used that specific installer needed to reinstall Windows 7 and nearly every program under the sun (that's how it feels to reinstall all the tools we use on a regular basis). Seems safe enough, but then there was the one person who reinstalled, but then was unable to connect to the network fully, keeping a developer from getting back to his day job for an extra week while working with IT to figure out the minute yet significant detail that wasn't in order during that installation process that flagged his computer as unsafe for the network. In case you haven't guessed it, that developer was me, and that process was just not fun. However, it did provide ample time to write about the game jam experience...
Another issue was the Monday after jamming. You could feel the complete and utter lack of energy as everyone got back to their day job. We went from a bustling, excited studio to one of morbid silence in the matter of a weekend. The feeling was palpable, yet difficult to describe. It's kind of like the end of The Graduate when Ben and Elaine get on the bus. They're exhilarated and laughing, but then their reality sets in during the span of moments. Their smiles fade, they try to hold on to that excitement, but it's futile. Their life will come to some form of normality. That return to normality from such a different world is jarring.
In Conclusion
While the fallout from our game jam cost me a week of work and a day or two of studio-wide regulation, the experience of those two weeks was incredibly inspiring and powerful. It was a compressed learning experience that got the studio's blood flowing. It let us shine where we wanted to, work on what we wanted, and really feel ownership over a product - something that just doesn't seem to happen on a large project. Every studio should make the time to game jam - it really let's everyone play at game development and discover just what they're capable of in a short time, and that's just too powerful an experience to pass up.
Subscribe to:
Posts (Atom)
