What I Learned, What's Next

I'll make this brief, these are a few things I learned in the process:

• You can only do so much planning on paper. It's difficult to learn what you need to until you start prototyping.
• Prototype rapidly, cheaply, and often.
• Make a hypothesis, prototype it, test it, listen and learn from the testing, implement feedback, keep doing it until you have something that resonates with your players. 
• Stay small as long as you can, and only move forward when you've solved the problems right in front of you. If you don't, you'll be trying to solve them with too much complexity around them.
• Understand the resources you have and scope accordingly.
• Don't assume you know what you're game's going to end up being. Be prepared to move where the project and the players want you to move. But still find a way to make it your game, and have it be your voice.
• This is hard and extremely rewarding.
• Find the things you can change, and find out how to accept the things you can't. 
• Fight for the things that are most important to you, but don't make too many things that important to you. 

Leo Tolstoy said, "Everyone thinks of changing the world, no one thinks of changing himself." A few weeks ago on April 13, I put in my last day at Disney Interactive. I have a freelance job that will last for one year, and I want to see if I can't get a few personal projects off the ground, a game idea being one of those projects. When I started at school three years ago, I had no idea this would be the result. I'm excited to see what happens, and ready for the next chapter.

Where We Ended Up

So all in all this is what our team was able to accomplish:

1. 58 levels of Flux, fully playable.
2. 2 mini games, Trax and HiJax, using the Flux mechanics but strong standalone games themelves.
3. Multiplayer functionality
4. A tutorial screen
5. Level selects
6. Full audio track for the entire game
7. Custom settings

The programmers showed it off at CS Demo Day last week, and I'm told they were voted 5th place out of 16 projects. Not too bad.

I missed showing it off at EAE day because of the work I had to complete for my other finals, so that was a fairly anti-climactic way to bid adieu to the EAE program, but whatcha gonna do?

I'll blog some more about what I learned, and I don't even know where we're going to take it from here. There are a few bugs that might keep it from being a public release, and because we're all graduating, our inability to do any further work on it might just make people mad that we released it without further supporting it.

We'll see where it lands, but all in all, what a rad experience.

Game Video

 

HiJax

Trax

 

Flux early levels

Rock Star Programmers

Left to right: David Onken, Skyler Chase, Andrew Clark, Michael Banks

So Michael worked what I consider to be a small miracle during the course of this project, he put multiplayer functionality into Flux. This was not a feature that I thought was doable with the time and resources we had. This is a shooter, so synchronous gameplay is critical for multiplayer success.  Synchronous gameplay means that what happens on my screen is exactly what's happening on the other player's screen at virtually the same time. For example, if I wanted to shoot another player, I'm going to aim at a particular spot on the screen, a spot where I believe the other player actually is. If there's any lag in our game, then that player has probably moved from the place I'm aiming. Resulting in me thinking I'm shooting at someone who isn't actually there.

Asynchronous mobile games exist, Draw Something is an example of this. I make a move, then the other player makes his move. It's not critical to the game that the players be in sync. A lot of games do this, already. Synchronous mobile games however, are a lot more rare than asynchronous.

Multiplayer support has always been something I want to do with Flux, but I presumed it was something that would come down the road. When Michael set out to do this, I admit I was pretty skeptical - skeptical but impressed. A lot of really cool things are made when you don't know that you can't make that thing. So when Michael said he was setting out to do it,  I was really excited to see what he'd come up with.

I've played an earlier version of multiplayer, Michael was playing on his laptop and I was playing on a mobile device. Sure enough, we were playing together. I was shooting him and he was shooting me. It was pretty impressive.

I haven't played the recent version, but look forward to seeing what Michael has built.

This is only one of the things that the programmers did that I didn't think we'd be able to do. Especially considering that these programmers had virtually no game play programming experience before Flux.

The ai is another example of this. I thought that getting complex ai behavior in the non-player shapes would be something possibly too difficult to add in the time we had. I was prepared to make it work with backup solutions, and would have been ok with that. But as Andrew started implementing the different ai behavior, it became clear pretty quickly that we'd be able to have a relatively robust ai feature set. He worked hard throughout the whole project to get this in.

 I also really appreciated Andrew's leadership and communication abilities. Communication and schedule management have never been my strongpoints. It was great having Andrew take charge with a lot of those things. I think his cool head definitely helped in stressful times that we all went through.

Skyler not only owned all of the controls, created a mini game, implemented the levels, and probably a ton of other stuff I'm unaware of, but he also created some of the art assets and animation. He animated the shapes changing when they got hit. This was a crucial part in helping people understand the evolution devolution idea. It was something that sat on my plate for a while that I was never able to get to. He finally just made something himself and implemented it.

He also created the sound track for the whole game, which has an awesome retro electronic epic feel that I think works really well.

On the CS Capstone demo day, I noticed that he had also created bullet and exploding FX to the game.

When discussing new features to implement, David was usually the first one to say, "That shouldn't be too hard." I don't know how much of it was actually harder than he implied, but the fact that we never heard about it speaks to his always positive attitude. He was also probably the most experienced gamer among us, which came in handy. He provided me with a list of all the games he's beaten, as well as those he has yet to beat. It was quite an extensive list, I didn't even recognize some of the games on the list.

The programmers also deserve a ton of credit for having to put up with me and my lack of time, bad scheduling, and poor communication. They definitely made the most out of what was given to them, and I really appreciate their patience with me.

Ed Catmull recommends working with people smarter than yourself, and I definitely lucked out by being able to work with the kind of intelligence, talent, and hard work of Michael, Andrew, Skyler, and David. Thanks guys it was awesome!

Features That We Never Iterated and Tested

There are a lot more features and design elements I'd like to incorporate into Flux that we were not able to implement. Here are a few bullet points:

• Provide a way for the player to be able to change his own shape through pickups
• Perhaps there is a red or green energy orb surrounded by an orange circle. When hit, the orange circle explodes, and the player can pickup the energy orb to change his own shape. There are times in the game where you need to change your shape to accomplish a goal, or else you're stuck. There's the option of shaking your device to change one of the elements on screen, and that's a nice feature, but it takes time away from you, and I'd like to be able to have a way where it's not a negative thing to be able to change your shape. It shouldn't happen to often, but if you made it a reward for shooting a moving target, then you had to go pick it up, probably amidst enemy fire, it might offer some cool additional gameplay.

• Powering up. I'd like to create a way for the player to power up and require more hits before it changes shape. I would visually represent this with small shapes at the base of each shape. For example, a circle might start the game with one small circle trailing him. As he gets more points, he'll power up represented by additional small circles.

The other shapes might look like this:

When hit with red or green bullets, you'd be able to visually tell what you were about to turn into.

Once all of the mini shapes were filled up, you'd turn into the next shape.

• Shape changing. One of the things that has always been confusing for players in this game was the evolution/devolution idea. A player rarely grasped that the shapes were evolving or devolving when hit with the colored bullets. When I first observed people playing the game, this was one of the first things I realized. I've since considered how we might change that and recently I've played around with the idea that red bullets turn you red, and green bullets turn you green. If you're hit with a red bullet and you're already red, then you'd turn into a white square. The circle's bullets however wouldn't be able to turn anyone into white because I think that would make the white too powerful. We could give it simple bullets compared to the triangle and square's more powerful bullets. I think this would be more intuitive, and what the player is expecting. 

Play Testing and Feedback

We tested the game numerous times with a variety of people. We tested among groups of people, and individuals. It was all very valuable feedback and I look forward to continuing with the process.

While all the test groups were valuable and offered great feedback, I'd have to say, testing it with my kids brought the greatest satisfaction. Pretty quickly I decided that if I could make a game they could enjoy, I'd be happy. 

Among the groups we tested were:

EAE Cohorts.

Both during concept and development of the game these students proved to be extremely valuable resources for testing. It was helpful that they all spoke the same gaming language, and were hard at work making their own games as well. The feedback I received from this group was usually very precise and detailed information. They were all quite astute at quickly recognizing the key problems with the game, and what options we might explore to make it better. Being gamers themselves, they had a wide range of gaming experience, and were also very honest. They were able to tell me whether or not they liked the game, whether they would play it and even pay money for it, and where it compared to other games in the market. They pointed me to games that I could look at to learn things that would be valuable in our development, and that was extremely helpful. Even when the game wasn't the type of game they would normally play, they could still let me know what was working and what wasn't. It was very valuable having this feedback, and I hope stay in touch with a lot of these guys after graduation.

Family and Friends.

This next group was a fun group to test with. Most of them were very complimentary toward the game, simply because it was me making it (that might be an assumption on my part). It felt like I might have been able to make any game and they would have spoken well of it. That's not to say there wasn't some real honesty in the feedback. I have the kind of relationships with these people to ask for and receive honest feedback, and that was usually never a problem. My kids were by far the most fun to test this with, and I loved seeing each of their personalities come through as I tested the game with them. At first they were just thrilled to have their dad ask them to play a game. Then they moved to being very complimentary toward the game, and told me how cool it was, and what a good job I did. (I should add that they're all under the age of 13, so no teenagers yet.) They struggled with much of the frustration with the game that other testers did, and I could tell they did, but I definitely had to pry out of them the things they thought weren't working well. I had to let them know that they wouldn't hurt my feelings by telling me the frustrating parts, and that the more they told me the more it would help me make the game better. When they realized this they were not only helpful in telling me where it was frustrating, but also suggested ideas that might solve a lot of the problems. It was truly great to hear their ideas, some of them were spot on with how I would solve it, some of the solutions sparked new ideas and insights that were really good. 

If I continue to make my own games in the future, I will definitely focus on developing games that they would enjoy. If possible it'd also be fun to develop games with them if that's what they wanted, they've got some great ideas. Who knows.

The CS Capstone Students.

These students were shown the game on multiple occasions throughout the year. They were shown all the prototypes that were created and gave feedback. This was helpful, because it represented a group of people that approached development from the engineering perspective.

Here's some of their feedback:

• The transformation mechanism is not intuitive enough (e.g. it was confusing to people that a green bullet caused the triangle to turn into a square).

• People thought red should be lowest then white and then green (in order to be consistent with how the bullets transform you in that green leads to green and red leads to red).

• Some people mentioned that it would be better if the transformations looped (e.g. the white would become a triangle if hit with a green bullet).

• People liked the mini-games.

• Several people were entertained watching us play the game but were intimidated to actually play the game.

• People seemed intrigued by the concept of change and how flux explores that and most everybody said the game was cool.

• Some people said they really liked how elegant and smooth the game looked.

• Some people liked the animations.

• Several people felt the first ten levels were too redundant -- different elements need to be introduced sooner.

• The win/lose screens need to be transparent, so they can see what they actually did to win or lose.

• The additional elements make the game more interesting and fun like the pass through walls and reflecting walls.

Professional Colleagues.

I took the opportunity to test with some of my colleagues that I've worked with. I made sure not to do this at work, as it was a conflict of interest, so I tested it with them outside of work. This was very helpful for a lot of the reasons that the EAE cohorts were helpful, but unique in that these colleagues had a lot more professional experience than the EAE cohorts. I'm not saying that that's a good or bad thing, just different. It offered a unique perspective that was hard to get elsewhere. They were able to see design and development problems clearly, and many times had very efficient and clear solutions. They offered advice on how they might do something differently, and how they would implement things themselves. It also proved that there are a lot of really bright and talented people who could make some great games and apps themselves if given the right opportunity and environment. 

The Foundry

Around the middle of the semester I was accepted into the 10th cohort of the Foundry at the University of Utah. The Foundry is a startup incubator composed of entrepreneurs, mentors, and students looking to get their ideas off the ground. A group of student entrepreneurs go through a 12-week course where they test and refine their idea for a startup, with the help of the mentors and other members of the cohort. This was a really cool experience with some great mentors, Russ McBride and Josh Maag. I tested the game within the cohort and received helpful feedback and ideas for the game itself, but equally valuable was the advice outside of the game design that was offered.

The Foundry turned me on to a process and philosophy that I had heard about before, but was only marginally familiar with, which is Lean development. Eric Reis wrote a book called The Lean Startup outlining some of its core ideas and implementations. It's tough to boil down everything that it is into just a few sentences, but as I understand it's a process of making assumptions or hypotheses, then testing these hypotheses in small, simple, experiments that help you learn what you need to further your hypotheses.  The Foundry is run on this philosophy, and much of what Russ and Josh advised toward was this process, what's the next step, what are the experiments that you can run to test your idea and how do you do it in a quick efficient process. 

It wasn't only valuable to get feedback on my own project, but on my fellow students' projects as well. The Lean mentality and process was applied to building and launching products and companies, but it could also be applied to game development. And in fact, as I read and became familiar with this process, it resonated as a process that I've heard used among successful game companies like Nintendo. This makes sense, as much of the Lean philosophy is derived from the Japanese company Toyota, and the way they manufacture their cars. 

It's a process that I think is critical in a creative place like a game or animation company. What I took out of it is that often we just don't know where we're going to end up in making a product or game. If we're willing to admit that, test our hypotheses in simple, inexpensive ways, and learn as much as we can from these experiments, we'll have as good a chance as any at getting to a product or game that might resonate with people. 

The time I spent at the Foundry was very helpful, I only wish I had more of it.

Game screenshots

Here are some screenshots of the game in its current state:

The above picture represents how the main menu appears in the game. The below picture represents the layout I would have liked to have (with the correct logo). It's another example of how I just didn't have enough time to iterate on everything I would have liked to iterate on.