Rest in Peace, Ember

So, the semester is over, and so is the first of my Game Development classes - MI 445. And boy, did it end with a bang.

In the last month of the class, we were assigned to groups and given 5 weeks to make a game. No prompt, no requirements, just 5 weeks and a team. Simple enough, right? Not as simple as it sounds, as it turns out. I'm not going to bore you all with the details of how we made the game, but I am going to instead break down everything that went wrong with the game (and there were A LOT of things that went wrong). It's not that I'm not proud of the game we made--because I am. But being proud is not the same as being satisfied, and unfortunately I am not satisfied.

When we began talking about the ideas for our game, I tried to lead conversation. Basing an idea off of a prompt or theme is actually really easy, but coming up with one out of thin air is very difficult. So, I tried to get everyone to talk about game genres they enjoyed. We decided as a group that we didn't want to do any kind of 2D game and we didn't want a First-Person-Shooter, so that narrowed our options a bit. It took several hours, but eventually we were beginning to flesh out an intense psychological thriller game where you play as an Archaeologist who has to embrace evil powers while searching through a cave and try not to lose your mind. Yeah, super dark, super heavy.

Honestly, I don't think the idea is bad. None of us thought it was bad. We were all really stoked for it. But, some older students in the program told us that for a 5-week game, it was best to steer clear of story-driven gameplay, horror-games, and high-concept games. If I had to describe our game in three phrases, it would be story-driven, horror, and high-concept. So that idea was quickly canned.

We had one day to come up with a game idea. Thank God my friend Peter had one already in mind. We basically met up and he showed me the new Dragon Trainer Tristana skin for League of Legends. Our group agreed, "Yeah, that's super cute. And baby dragons are cute. And there aren't enough baby dragon games out there. Let's make it."

So we created Ember.

I think the fact that we came up with and started pitching this game idea so quickly lead to a lot of other problems, mostly relating to Level Design. Were we going to have multiple levels? Just one level? A level you have to make it to the end of then come back through? A multi-tiered level? I'd like to say that we talked through these ideas and came to a conclusion, but we really didn't ever do that. We had a designated level designer and he just sorta did his thing.

What we ended up with was a very beautiful, but incredibly large level. So large, in fact, that we seriously struggled to make use of everything. The gameplay experience was much too large to polish substantially. We ended up just slapping trees and enemies in it, but we lost sight of some of the really important aspects of level design; like balancing the enemies, coordinating the collectibles, indicating goal and providing direction. In terms of level design, we just strictly overscoped.

Another issue in our game arose with the fetching script. The idea was that when the player looked at an item that was collectible and clicked a button, Ember would go and fetch the item for them. This script was literally broken until about 11:00 PM the night the project was due. At that point, everything in the game had been created without the fetching in mind. So, when it was finally added to the game, it was completely nonessential - which was incredibly unfortunate because it looked so good at that point. What we ended up with was loose functionality that didn't really add anything to the experience.

But I think the biggest bullet in the foot for us was feature-creep. We were told in class to avoid feature-creep, but they never really warned how and when feature creep occurs. In our case, it was the last week of the project. Before then, we had a pretty solid idea of what was essential to the game. We had decided that things like a cutscene were important, boss-fights were not. A second enemy was important, a third enemy was not. Some kind of collectible was important, a wide-range of power-ups were not. However, when we started actually sitting down and making huge progress on the game (the last few days), all of these things that seemed like fleeting fantasies suddenly seemed like potential realities. Progress was kind of a drug, and it lured us into doing things that we knew were pretty terrible ideas. "Oh, maybe we can add a boss (that one is my fault)". "I think a third enemy would be good." "Let's have 4 different kinds of collectibles!". "Let's overhaul all the art in the game." This was the final nail in the coffin for Ember. What we ended up creating was an incredibly complex game with almost all attention turned towards additional features and little turned towards gameplay, which was a deadly combination.

In terms of concepting the project I think there are a few other points to take away from this experience. When we pitched Ember, we pitched it as an Adventure game. I still think this is the best classification for it. But every time I said it was an adventure game, I wanted to throw up in my mouth a little bit. Because I already knew what we were doing but it was too late to stop it.

What do you think of when you think of adventure? You think of travel, you think of beautiful scenery, you think of far away places and the feeling of vastness in the world around you. To say Ember didn't have those is an understatement. I don't think it's even feasible to develop a true adventure game in this timeframe. What we created was a cute slice of pie out of an adventure game. A drop in the bucket. A tree in the forest.

A lot of lines can be drawn to categorize games, but there is one such line that I think is of particular importance. On one side are the games that are long - they are lengthy in time but linear in strategy. These games have only one real method to play and win, so they are likely only to be played once, as the player cannot do or learn anything different in playing it through a second time. The second genre of game is wide (or circular). These games are either open-world or closed-world, and each time the player plays it, they can make different decisions that lead to ultimately different gameplay.

Ember is an example of the first category, as were many of the games created by my classmates. There is nothing wrong with these games, but as students, we are told to optimize the game experience for about 15 minutes. That means 15 minutes of great gameplay. But what happens when they're done? Are they ever going to play the game again? Likely not, because they have already experienced everything the game has to offer. At my age and level of study, there's nothing necessarily wrong with this, considering that we are making these games more for the experience than anything. However, the second category of game is one that can be played over and over again. At our level, these games often include some kind of open system that gives the user an environment or world and lets them play around with it however they choose. Multiplayer games also follow this paradigm, because your actions are influenced by the actions of your friends. Games (like Ember) that fall in the first category aren't automatically bad, but they are naturally going to lack a sense of satisfaction for the developer at the end. People will play them once for about 15 minutes, and then be done with them. It doesn't feel rewarding when you work on a game for over a month and people are over it in half an hour.

So do I think Ember was a failure? No, not necessarily. Though, I think we, as a group, failed in a lot of places. But these failures are not in design as much as they are about time management scope. We are going back and fixing a lot of the issues with the game, and hopefully we can solve all the problems mentioned above. As for the concepting issues, that's just something that I need to think about as a designer and keep in mind for future games. It's always a little disappointing when your first try doesn't come out how you want it to, but you have to remember that it was exactly that - a first try. I will not let the shortcomings of this game demotivate me. I will use them to make my future games better.