More Villains: part 1 - Snowman

Since the game is called The Elf Who Killed Christmas (here), it made the most sense to begin this development blog talking about elves (you can review those here). However, there are several more villains in the game beyond elves. In fact, the first enemy that is encountered in the game is a snowman.

We figured that since this was a Christmas game, there must be a snowman! It is easy to recall, when we were children, all the silly stop-motion animated films that would play on television during the Christmas season. Among those shows, the Frosty the Snowman stands out in my memory. As can be seen, we clearly did not go in the direction of that film, but we knew that, being a villain in the game, we would have to get a design that sold the character as a villain. 

In this detail, you can see it was important for us to get the sharp teeth, the crooked nose, and bow-knotted tree limbs as arms. We thought that these were all important features to include for a scary character. However, some of the more classic elements of the character that we included are the top-hat, and the scarf. One limitation regarding the scarf, though, was that if we kept it hanging down, long, then it would be that much more difficult to animate. So a hanging scarf was cut out altogether. I faced a similar problem with the pieces of coal that might have represented coat buttons going down his torso. Even though these elements do go missing, I think that I prefer this pared down design a bit more, and it fits into the game quite nicely. 

Visit the game's website, and download the demo!
http://elfwhokilledchristmas.com/
http://giveupgames.com/

Video Game Self-Publishing

Publishing is always a challenge for indie videogame developers. Ultimately, the problem here is how to get the game that we worked so hard to make into the hands and screens of players out there.

On our first game, the solution was known from the beginning. We published "Alpha Chimp" (here) on Xbox360's indie marketplace. However, even though we knew this was the publishing avenue, there were still challenges that posed a barrier to entry. (Just one of these barriers was that we had to be approved by the community group of developers, that is, our competitors.) I won't get into too any more of the problems that marketplace publishing option posed, but there were many, and we knew this would not be an avenue to pursue with The Elf Who Killed Christmas.

There were a diverse group of choices that we could have pursued in publishing. One is that we could try to find other marketplaces similar to the Xbox marketplace. Well, that would just bring the same sort of barriers as before.

Another option might be to self-publish. The problem with this solution is that we would then have to develop the infrastructure to make our game available on our own website. Such necessary infrastructure would be securing internet bandwidth, as well as developing an e-commerce site. Another significant challenge with this is how we would might get random internet traffic to our site.

As a college professor, I often tell students that whenever they are offered a choice between two alternatives, then best solution is probably a combination of both alternatives. And so this was the avenue we pursued in publishing our game because it offered the best of both worlds.

AMAZON.COM just began offering a service such that independent developers could utilize their infrastructure and marketplace to sell their products. After exploring other self-publishing marketplaces (that fell through for various reasons), the AMAZON.COM solution was the one that best suited our needs.

We were able to make a FREE DEMO VERSION (here) of  "The Elf Who Killed Christmas" available in January. Now that the game is complete, the FULL VERSION (here) of the game is also available on Amazon for less than a buck!

Visit the game's website, and download the demo!
http://elfwhokilledchristmas.com/
http://giveupgames.com/

Mountain Level Design: part 3

Here are bird's eye views of the whole level.

As a whole, you can see how we implemented the ideas expressed in the previous descriptions of our plans for the level design. After entering the level from the island-like area, the spiral and curving-back theme is clear.

At first, I thought that it would be easy to implement the level as a whole, like it is presented above. However, as I described before, this presented problems by forcing the system to render the whole level, even when all that work is not necessary for the computer to perform.

Therefore, we had to optimize the level, and how it would be presented to the system.

These are just some of the examples of how the level was broken up, and delivered to the engine in chunks that were easier to process and process. This greatly optimized the stresses on the system, and increased the performance of the game in measurable ways. By giving the engine different blocks that made up the level, it would then be able to turn off certain parts of the level when it was not in view. The best examples of this can be seen in the top two images, when the player enters the upper sections of the level, which we called the Igloo Village. The player would not have been able to see further behind him since the ice-block walls were too high to see beyond. 

Visit the game's website, and download the demo!
http://elfwhokilledchristmas.com/
http://giveupgames.com/

Mountain Level Design: part 2

Besides giant snow boulders rolling down the mountain, there were other key ideas we wanted expressed in this first level. One such level feature that we wanted to include in this first level is a large field of vision. What that meant to us is that we wanted the player to see features of the level that he would run across in the future, as well as looking back to see where he has come from. What this means for level design is that instead of a fairly straight, linear path that that the player would traverse, we instead designed a path that would spiral, and/ or swerve and curve back over itself.

In the image above, the player could see clearly where he is now, and the immediate setting. It happens that this is a plane area, with reindeer pens in the back, and a large rock wall framing the area. However, while the player is looking just above the brown rock wall, he can see that second level, where he will be running as soon as he finishes off these enemies before him. We realize that the player might not yet realize that he will be running up there, but he will notice it soon. One thing that he might see now is the giant snowball boulder that is falling. We hope this will make him excited to see what is coming, and where that boulder is falling.

This screenshot above is seen by the player in the first moments of the game experience. Right away he can see that he is going to have to go through a cave, and perhaps he can make sense that he will be running up that slope in the near future. He is helped to this conclusion by seeing that there is a fence that lines the slope. Or maybe the player doesn't come to that conclusion regarding the slope. He will know soon enough.

Indeed, a few moments later, after killing this onslaught of enemies, and rounding the corner, and dodging that giant snowball, the player will find himself on the mezzanine of that reindeer pen area, and the player is able to look down upon the place he was previously. There are several places in this first level where this feature of the level design is manifest.

Above, the player is looking down that slope that he might have noticed at the beginning. He can look all the way back to the point where he began the game.

However, as game development was wrapping up and coming to a close, it became clear that such level design might have actually worked to our detriment. That is because the resolution of the assets in the level were high for our system. The best solution is to be able to turn off such assets when they are not in view. However, this is not a viable solution if we want to maintain this large field of vision. That is to say that if we want the player to look over a cliff to see places where he already passed, then we can't turn off those previous places!

Well, it so happened that the level design was such that, in fact, there were places to travel where the player could not see earlier places in the level. Therefore, we were able to exercise the best solution, and turn off certain parts of the level (just not to the degree that we wanted to.)

(Perhaps the reason there are so many games that have levels where the player travels from room to room is so that the engine can turn off all the other rooms that are not in the field of vision. We would explore this sort of level design in other levels (primarily the factory/ prison level, and the palace level). Further, now we know that our level design in future games will try to optimize the field of vision so that we can turn off elements that are not currently in view, and thus, that don't have to be rendered.)

Above is an example in this first level where we wanted a bit of a break in the feel of the level. This break is clearly demarcated by laying out fences that divide the previous parts of the level (the reindeer pens, and then up the slope) to this new portion of the level, the Igloo Village. The player can already see that there will be igloos here, and that the main borders of the path will be icy blocks instead of rocks, or the sides of mountain.

Of course, just because this is a new section of the level, it does not mean that we wanted to abandon our original ideal of seeing parts of the level that are coming up. In the screenshot above, while fighting through the igloo village, the player can see the mouth of the cave that is coming up, that might just be around the bend.

... and so, the player arrives at the entrance to the cave. Again, we wanted to clearly illustrate that the player would be entering a new section of the level, and so there is a fence that welcomes (or not) the player to what is coming next, the cave, which is the first part of the game where the player is completely surrounded, and does not have a large field of vision. This is where the player faces the boss, and finishes the level.

Visit the game's website, and download the demo!
http://elfwhokilledchristmas.com/
http://giveupgames.com/

Mountain Level Design: part 1

Somehow, early in the development of "The Elf Who Killed Christmas," we decided that we wanted the protagonist to begin in a mountain level, where the hero would shoot his way up the before getting the level boss, then onto the next level.

Mike was very clear that he wanted certain game mechanics in this game to be introduced in the first level. Earlier versions of the game included slippery ice, deep chasms to jump over, and large snowballs to dodge. As games develop, lots of things change.

It so happens that the one such environmental element that survived to the final version of the first level of "The Elf Who Killed Christmas" was the giant snowball. If this hits the player, the player dies. However, the snowball could be dodged, and even be shot out of the way.

With certain goals (like environmental elements, and the mountain setting) in mind, this helped us solve the problem of level design. In the case of this first mountain level with giant snowball boulders, this meant that we were designing a level with ramps for the player to hike up, and for the ball to roll down.

Visit the game's website, and download the demo!
http://elfwhokilledchristmas.com/
http://giveupgames.com/

Microsoft Game Test

Recently we were fortunate enough to participate in a big game-testing event. Microsoft invited indie game developers to come to their offices in Midtown, New York, and have many people play though our game, no matter what stage of development we completed.
It so happened that our game is about 90 percent finished, so we had quite a lot to show off. However, we had no idea what the event would entail. Being that our company is called Give Up Games, we were naturally cynical and pessimistic about what the event would be like.
When we first arrived (on-time, I might add), the large event room was nearly empty, and there were only a handful of other developers there, and it seemed like we would have to passively-aggressively fight for the few tables that were there. We got the last one, and it happened to be in a corner right next to the garbage bin. Give Up.
Within a short while, though, the room began to fill up, both with game developers, and eager fans who wanted to play games before everyone else. People were standing shoulder-to-shoulder watching and waiting to play our game, and for the next few hours the two of us rarely had a quiet moment, while we entertained questions from fans, media, and fellow developers. Several people even came back more than once to play the game more! We heard from more than a few people that ours was the favorite game of the event.
It turned out to be a great experience, and we loved the opportunity to show our game to a welcoming public. We got a lot of good feedback and enthusiasm from fans, and we both felt that much more energized on this home stretch.
Thanks to all those who came out and played the game.

Animated films

In addition to making video games, I like to also create short animated films. Perhaps one of these short films can be translated into a video game at some point. Here is my latest, based on the short story by Akutagawa Ryunosuke, "Rashomon."