We were thrilled when we heard about and started digging into iOS 10’s new features for iMessage. As a company, we believe that rich messaging is a big part of the mobile industry’s future, and on personal level, I just love being able to send more than just words to my friends and family in iMessage.Read More
I opened Lasha's drawings, and a banana-dog hybrid was smiling at me. I had seen sketches of the banana-dog before, but this was my first time seeing it in color. It had brown speckles all over it, and looked like a perfectly ripened banana. (This creature sparked an office debate on what constitutes a "perfectly ripe" banana.) The first word that came to my mind was "Mushy", and Musha was born.
I imagined groups of these banana-dogs roaming dingy alleys looking for tasty treats (they hatch from Trash Eggs, after all). After a successful search, what better place to nap than under those dryer exhaust vents? After some feedback from Dyala, we agreed that the lint from the dryer vent would get stuck to the Musha's mushy tushes. We decided that Mushas could reasonably sleep under any type of vent, and removed the "dryer" detail. (Although I still like to imagine them making blankets out of dryer lint.)
As I started looking at the other Trash Egg creatures, I knew I wanted their names to create a sense of connectedness. I pulled open an image of a bat-like creature that also resembled an umbrella. I remembered a story my boyfriend (who is obsessed with cars) had told me. Lamborghini once made a sports car called the "Murciélago". The car was named after a famous Spanish bull, who was, incidentally, named "bat". "Ah", I remembered, "in Spanish, Murciélago means bat". Perfect! Murciela had been named, and I had a theme.
Knowing that I wanted the other creature's names to also begin with "Mu" helped direct the process. I opened up a picture of a creature made from cardboard, and its stance immediately reminded me of a Komodo Dragon. Easy enough – Mumodo it is!
Next up was a rodent creature made out of a black trash bag. I was stumped for a bit! After some brief research on Wikipedia, however, I learned that the scientific family name for rats is "Mureoidea", which just happens to begin with "Mu". I merged the word "rat" more clearly into the name, and ended up with Muratia. It was easy to imagine this fancily named creature sifting through garbage, searching for gems and trinkets.
I was now staring at an image of a green slime creature. The green was such a nice bright color – not quite the "sewer sludge" you see in the movies, this creature was more of a "radioactive ooze". I thought of scientists mixing and churning modern chemicals into new products. I recalled my middle school science class, where we made oobleck, a cornstarch and water mixture with interesting properties. From here, it was easy to attach the "Mu" to create Mubleck.
Lastly, it was time for the creature I had been purposely avoiding. An adorable pink swirl that resembled the poo emoji, but somehow cuter. I wanted to give this creature a good name, and not cast it to the side like, well, poo. After some discussion with the team, we agreed that we should let the creature shine, instead of trying to hide what it was. Without much delay, Mupupu was the final, and arguably most sincere, Trash Egg creature to be named.
Creating names and descriptions for 'Egg!' can be a lot of fun. When tasked with writing, we often pull from various sources – memories, anecdotes, and a little bit of research. Because of this, designers get to add a lot of their own personality and voice into the game. You may notice that each set of creatures sounds like a different person, or that they came from a different place. This is just one of the many ways we keep the world of 'Egg!' exciting and interesting!
Have you ever played this awesome game where a guy in a green tunic travels around a kingdom called Guyrule (Not actual name) with this amazing blue shield and sword? I did! Did you ever come across this one problem in said game where you would go talk to a specific character that would give you a set of 3 missions. If you followed the list in order and returned to that same character, your game data would be corrupted, making that 5 hours of re-spawning game play go down the drain.
Oh hoho, I did and let me tell you I wasn’t too pleased with the creators. But why would I bring an issue you may or may not have heard of? Well, dear children of Eggverse, you may have encountered a issue similar in another game. Maybe something that was clearly broken, awfully implemented or even upsetting to play?
So now I ask you this important question. If you found an issue like the one I just described, how would YOU go about reporting the issue to the creators of the game? That’s where writing a bug up comes in. As QA testers, we are tasked with finding and writing up every issue we can find in a game in order to help developers. This helps them make the necessary fixes or changes so the game doesn’t break or look bad. QA needs to find, locate, and instruct the programmers on how to find the issue on their own while we continue to find more bugs. We are like mission control, we give out the coordinates and the programmers go out and diffuse the bomb. If the code a programmer wrote does not work as intended, we send back the issue in order for them to work on another fix.
Now writing up a bug may sound like the simplest thing to you. Total walk in the park right? Alright, let me test you on your assumption. In 8 steps, could you walk me through how to make a peanut butter and jelly sandwich? Is your first step to go buy the ingredients or take the bread out? Wrong! (There’s the door, see yourself out)
You see, you already have all the supplies in front of you. Why would you waste a step on telling someone who already has the set up to make this delicious PB and J sandwich to go buy bread?
Each and every issue that we write into our database consists of 3 major things.
* Steps to Reproduce
All three are important. What is most important is to write a clear and detailed report on what it is that was found. We write up issues with the most detailed amount of steps and information to help our programmers resolve the issue that we encounter. And sometimes we add a picture of the issue for good measure. (That’s because QA doesn’t want to come off as crazy liars when the programmers can’t reproduce the issue. We have PROOF, we tell you! PROOF!) We do it to not only help them out, but also so when we go back in to check if the issue is fixed we aren’t confused on what our team member found.
So you can bet that when a bug like “A crashed occurred when tapping a button in room” is submitted it drives QA bonkers. Like, what room where you in? Which button did you push? What were you doing before you went into the room? Is it a soft crash or a hard crash? Did it delete your file? Did this happen before or after you got the Hylian Shield because if it happen after, you just spent 5 whole hours of boss battles for nothing! NOTHING! (Sorry, it gets me every time)
Details! It’s all about the details. You wouldn’t tell a cop that someone stole your awesome PB and J sandwich without telling them it was a large purple dinosaur with some whiter than white teeth and green spots on its back. How would justice be served!? Justice, to that beautifully made PB and J!
So remember kids, when reporting an issue, it’s always important to spread the peanut butter before the jelly. OH! And the details, the details are also important.
A big part of being a game designer, on 'Egg!' or any other game, is accepting feedback and criticism. The first round naturally comes from the team and others in the company, especially during the early stages of development. As the game gets further along it’s helpful to reach out to friends and family for input. And finally, once it’s out in the world, we get to hear from you, our wonderful fans. The other half of the process is what to do with all this feedback we receive. After all, everyone has different opinions and the responses aren’t always as direct and easy to interpret as you might imagine.
Internally, we always have to remember that people in the company rarely play the game the way real players do. When you have to go through the introductory tutorial 200 times in a day, you will definitely get sick of seeing Mr. Peeg. But many new player need and enjoy his guidance.
Co-workers are great guinea pigs for other kinds of design and balance changes though. From our first iterations to the version you’re playing now our balance guru, Tracie, was able to implement and fine-tune really major changes with the help of data and reviews from people in the company. The interface, art style, systems, and features all change dramatically before anyone outside the company ever sees the game.
The company is a small group though, and often too familiar with the game to test many things that we designers need fresh eyes on. This is where friends and family and a select group of players invited to test the game come in. They help us get a fresh perspective and look at the game through the eyes of people who are playing for the very first time, free from biases formed by earlier versions of the game.
One of many changes that came out of our focus tests was in how you can drag items from your inventory to your Egg. This is an action you will repeat many, many times while playing 'Egg!' Early on, you could only drag items while viewing them in the main list, and not while looking at the specific item details. This was a behavior that we had carried over from our previous game, Egg Baby, and because everyone in the company was so accustomed to it, no one had ever tried doing it differently. In the focus tests, however, every single player tried to drag the item from the details panel. Luckily it was an easy enough behavior to accommodate, but we wouldn’t have come across it without the external players.
Live User Feedback
Focus testing is great for catching specific behaviors and interactions like that, but of course once the game is out in the world, reviews and feedback from our players gives us a much broader view of issues and sticking points that might not have been problematic when it was just us and our friends and family playing the game.
One update that we had planned but then decided wasn’t a high priority was displaying a timer when the Egg goes to sleep, so you know how long it will take. What wasn’t a high priority for us turned out to be very important for our players – many of you left reviews confused and requesting that exact feature.
Putting It All Together
These examples are all pretty straight forward, and there’s not much question about one option being better than another. Most of the time, though, the feedback that designers receive is anything but direct.
Everyone has different and often conflicting opinions about difficulty or balance or how a system should work. People have many different play-styles and care about different parts of the game – the collecting, the progression, the social aspect – and a big challenge for designers is how to appease all these groups.
And, sometimes, the best decision is not to appease them at all. Players don’t always know what they want – they know what they don’t like, but the solution is rarely as simple as they think. Beneath the surface, the systems that drive the game can be very complex and intertwined, and seemingly obvious “fixes” can have cascading and wide-reaching effects.
As designers it's our job to take these opposing opinions, our own knowledge of the game and of how our players interact with the game, feedback and criticism from many sources, and figure out what changes to make or features to add to improve the game in the best and most meaningful ways. The information we gather and the choices we make with it trickle down to everything we do in design, and certainly makes for a better experience for everyone!
And that's just considering feedback from individual players. We also gather data on a much larger scale, looking at the big picture of what and when and how players do different things in the game. But that’s a larger topic for another post…
One of the most fun parts of 'Egg!' (or any game, really), in my humble opinion, is getting to play dress-up! Much of my work as an artist on 'Egg!' has involved designing and creating the various clothes and accessories you can collect to give your Eggs more personality and pizzazz.
To start out, I'm given a list of potential items brainstormed with the designers. Then I'll start bringing those ideas to life with rough sketches. Getting something down quickly in this rough stage makes it easier to make changes if the item isn't what the designers had in mind, or if the art director feels it doesn't quite look or feel right for our game.
In some cases, I'll do roughs of multiple possible versions of an item, and after input from the art director and/or game designers, choose one to take to final.
The wardrobe covers a range of styles to fit all the different personalities your Egg can have, and similarly, the clothing options can range from simple t-shirts to eggsquisite gowns. When I'm drawing the wardrobe items, I do so at a much larger size than they'll actually appear in-game, since this allows me to put a lot of polish and detail into the more luxurious garments.
Zoom out, and the final result looks super clean and sparkly!
Have fun playing around in the wardrobe, and see how creative you can get with your Eggs' personal style!
We programmers use our fingertips to bring ideas (provided by our delightful designers) and art (provided by our amazing artists) to life. The raw pieces are separate and motionless at first, but with a little bit of code, we bring them all together and make them move about.
Sometimes, things don’t move the way we thought they would. When I first programmed the rope slicing in the Dreamscapes minigame, I didn’t anticipate just how fast fingers can move across a screen. A fast finger could end up missing the rope if the finger’s frame-by-frame position skipped over the rope.
Time for a new approach! Rather than a basic collision check, how about tracking when the slice intersects the rope? That method sounds much more promising, even if more involved. As a finger moves across the screen, it moves from point A to point B, creating a new line segment with each new frame. A rope is also just a collection of line segments. There is enough information to calculate the point at which these line segments intersect, if they intersect. Using this method, even if a finger starts on one side of the rope in one frame and then ends up on the other side of the rope in the next frame, it will still get sliced. With the plan in mind, implementation can get under way.
After implementing the new method, the ropes get sliced as intended, even with really fast fingers!