A Few Changes

In the last post there were a few changes in the game. Most notable, I'm leaning toward changing the name of the game. When searching for games in the app store, 'flux' had been used quite a bit. Fluxx was also used. I couldn't find any games currently named fluxo, so it seems safe for now. We'll go with that unless a better name comes along.

The other slight change was in the player's shape. To distinguish it from the other non player shapes in the game, I'm putting a small triangle, circle, or square in the middle like so:

It seemed necessary to do this since the shapes would be changing during gameplay, sometimes rapidly. Hopefully this becomes clear as to what the player's shape is at any given moment.

 

Refining the Start Screen

After trying to explain the start screen to my brother, I've made a few changes. We're prototyping that right now.

After opening the app, the load screen will appear. The bar below the logo represents the load bar.

When the game finishes loading, all but the word 'fluxo' goes away, and 'fluxo' turns green. The green fire button and the joystick appear in a rectangle representing the non playable area.  The player has control of the triangle. Hopefully at this point the player moves the triangle, plays around with the green button, which shoots a green bullet, and ultimately shoots the word fluxo. If, when we test this with people, the player fails to shoot the word 'fluxo' and is confused as to what to do, we can try animating the word fluxo, hopefully prompting the player to shoot the moving word, or we can put a '?' at the bottom center of the non playable area that, when tapped, pulls up a help menu explaining what needs to be done.

If the player hits the word fluxo, it will change to a red 'start'. Hopefully the player then shoots and hits the word start. 

When the player hits the word 'start', the player loses control and a white box with the following shapes appear.

The shapes blink a few times, and animate down toward the bottom of the screen above the timer. A level appears as well as a second shape. Once all elements are on the screen, a 3-2-1 countdown appears in the middle of the screen. When it counts down to 0, the timer starts, the other shape starts to move, and the game begins. 

 Again, the purpose of this start screen is to teach the mechanics of the game in hopefully a simple, intuitive way. I'd like to try to do so without words, tutorials, or prompts.

Latest Prototype

Here's the latest from Jinghui, just getting in the shape changing.

Many thanks for the work he's done on this, he had an internship in China the past few months and had to do this on his free time, thanks Jinghui!

Team Building and Creating a Culture

 

Have you ever been to one of those company sponsored, team building exercises at your work? The kind where you take off for a few hours to an offsite location, or a company is brought in that specializes in these type of activities? Your managers come into these with a little more enthusiasm than normal, as if they were ordered from their bosses to be more enthusiastic, or they just finished reading a manual or received a powerpoint presentation on how to be more enthusiastic. Often times they tell you at the beginning how excited they are to be there. The people running these activities are totally juiced to be there as well, as if they've found their callings in life, and that included putting you through one of their research-based, time-tested, life-altering team building exercises? Sometimes they have loud music playing, sometimes there are decorations, sometimes t-shirts are handed out. 

For these team building exercises, you usually divide up into groups and are given tasks to complete that make you feel and look really ridiculous, but should force you to work together to accomplish a goal. As you complete these tasks, I think the people who organized them expect you to bond with your fellow workers, and be inspired by what you can accomplish when you work together as a team. I think they hope you take the skills you learned in these exercises to follow you as you sit down at your desk the next day and punch in your tps reports.

The idea for these things seem to be born out of your company's management discussions around a long conference table, as managers seek ways to improve company morale, employee cooperation, and personal investment. It seems to be the first thing these managers and hr people reach for when trying to solve difficult problems within a company and workforce.

I'm currently working my way through Ed Catmull's new book Creativity Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration, and it doesn't take too long into the book before you realize that Dr. Catmull is not one of these managers.

I've been impressed by the insight, the candor, and the perspective he shares with the readers into the culture and processes of the company he co-founded, Pixar as well as the one he now oversees at Disney Animation Studios.

What impresses me most about Catmull's book is the sincere desire he seems to have to analyze, diagnose, and solve the problems that exist within his own company. He recognizes the complexity of these situations, and the human natures that are creating that complexity, as well as how those human natures might be utilized and understood to solve the problems that are perplexing his company and culture. I don't' know if it's the result of his engineering and academic background, but he's able to present his thoughts and ideas in a way that is objective and refreshing, presenting the facts as almost self-evident.

I was able to personally meet and talk with Ed Catmull a year ago at the U, when he came in to view our game program and participate in some exercises we had planned for him and his engineering colleagues. In the short time I was able to talk and interact with him, I was impressed with his brilliance, humility, and the perspective with which he saw things. Immediately following our exercises with him and his group, he made a b-line to our professors and started to engage them on our program, and what he saw as common trappings and mistakes within creative endeavors. He started offering recommendations for our program as well as anecdotes from his experience at Pixar that would illustrate what he was talking about. I was impressed at the humility with which he approached this situation, and the urge he had to diagnose and offer help to those in charge of a very creative endeavor.

I don't make this post to review the book or offer my opinion about Dr. Catmull, although I have done both. Rather, I make this post because as I've worked on this project I've thought a lot about companies, cultures, teams and their leaders. I truly believe that the creation of a company and a culture is a highly creative endeavor. And I don't think we can make these things succeed in the long term unless we are willing to go through the tough and honest introspection that Catmull exhibits in this book, and even then, there's no guarantee. As I observe creative companies and organizations, it appears that rare is the individual who is aware and willing to perform the kind of self surgery needed to overcome the problems that exist in their companies. It's difficult to fault them in this however, because I think it's a very difficult thing to do. But it'd be nice to have more people that did so.

iOS design, movement, and development hang ups.

After thinking more about the movement of the player for iOS and how I want to keep things simple, I'm leaning toward the following design:

The player has constant movement. The circle moves the slowest, the square moves faster, and the triangle moves the fastest.

The left joystick will rotate the player and move him in that direction. He will only be able to shoot in the direction he's pointed. This has been my biggest hangup because I'd really like the player to be able to rotate the shooter independent of his direction. I think it's important to be able to move away from a shape that's chasing you but rotate your turret toward that shape so you can shoot him. This would work fine with console controllers that have 2 joysticks and trigger buttons, but for iOS I don't want the player to have to lift his finger off one of the joysticks to shoot.

I could be wrong, and it might not be that big a deal. I've also played with the idea of tilting the ipad to determine direction. That's definitely something I'll iterate on, but for now, I think I'll take a pass at the single joystick. Here's what the interface might look like:

  

This whole notion has revealed a major flaw and problem I'm running into with development of this game. I'm not iterating fast enough and frequently enough. It's really difficult to design this game and make any progress forward when the rapid prototyping phase is essentially non existent. I appreciate the support I've received so far from everyone working on it, but he lack of programming and technical support and resources has really hurt this process. Not having the ability to test and iterate on prototypes has really proven the value and importance of this process. 

I have a few ideas on how to fix this, and who I might be able to talk to, so hopefully this part of the development can move forward.

 

Design Idea

Lately I've been thinking of starting the game as a triangle instead of a circle. By limiting the player to a triangle at the beginning, hopefully that gives them something to work toward to appreciate the power of the circle.

Also, Jinghui has sent a recent prototype that should include the shooting and transforming of enemy shapes. I'll upload it as soon as I get it.

Obstacles - Part Two

Another major challenge that I'm facing at this point in my schooling is the fact that I'm a part time student attending a program designed for full time participation. I'm grateful for how the professors and advisers have worked with my busy schedule, they've definitely been more flexible than I'm sure they anticipated they'd have to be. But for all the efforts they've put in, there's only so much they can do.

Recently I've run into quite a conflict because of this. It was a conflict that taxed my own energies and patience, as well as patience and energy of those involved. I won't go into it, but it's been a major source of anxiety and difficulty in my experience at the U. It feels like it's going to have ramifications for the rest of my schooling, and I worry that the managing of those dynamics are going to put additional stress on the remainder of my time at the U. This has also affected the experience I thought I would be getting at the U.

Lastly, one of the major obstacles I'm facing right now is burn out. For two years I've been juggling full time work, a second job of teaching at the Art Institute, attending classes and doing homework at the U, as well as personal family and church responsibilities, including a new born baby. In the last 2 years, I've also experienced 9 months of crunch time where I've put in anywhere from 60 to 80 hours a week of work. As I head into the 3rd year of this program, and I look at a schedule and a situation that doesn't appear to be changing, and I face down a semester that will probably be one of the more difficult semesters, it's safe to say, it's a little bit daunting, and I worry about having the necessary energy to fulfill my responsibilities.

The question then becomes one that we're all familiar with. How to go on, even in the face of mounting and seemingly overwhelming obstacles. I understand that these obstacles seem trivial compared to other obstacles out there. This isn't Mount Everest, it's not cancer, and it's not the death of a loved one. It's important to keep that in perspective. In fact, it's probably a good idea to spend a little bit of time each day recognizing and being grateful for the things that are going right in my life. Recently Dieter F. Uchtdorf said of gratitude:

"Have we not reason to be filled with gratitude, regardless of the circumstances in which we find ourselves?"

I'm usually not one that does a good job at being grateful. The times that I've focused on it in my life, however, has really helped me. It's helped change my attitude and put things in their proper perspective. It's made me a little more able to tackle the things in front of me, and it's helped me get out of myself a little bit, and focus on the concerns and needs of others.

There's probably a long list of things I can do to overcome the obstacles I'm facing right now. There's probably some things I can do to revitalize myself and generate the energy to get through this next year (hopefully it includes paddle boarding, the ocean, and surfing.) While I'll need to do some hard work to figure these things out, I think what I need to start with, the thing I need to put at the top of my list, is gratitude. If I can start with that, I have a feeling that the other things will work themselves out. Past experience teaches that in overcoming obstacles, if we can put the proverbial one foot in front of the other, committed to the journey as well as the destination, then whatever is necessary to overcome our obstacles will eventually come to us in time.

Obstacles - Part One

It seems that in most things we do we run into obstacles. Forces that push against us as we're trying to accomplish something. This seems to be built into nature, Newton's 3rd law of motion states that for every action there is an equal and opposite reaction. True to this, it seems that the harder we try to accomplish something the stronger the opposition is. I don't know that we can escape this phenomenon, we should probably expect it in all we do, and be used to it when it comes. After years of experiencing this, however, it still seems to catch me off guard when it happens.

This game has definitely run into its share of obstacles. I anticipated this, but for a game that has yet to really get off the ground, the challenges seem to have come earlier and more frequently than expected. 

I've mentioned this before, but when I started the game design program at the U, I enrolled with the expectation of certain experiences. I wanted to work on a mobile game, and I wanted work on it with a small development team, one that would allow me to take on roles and responsibilities that I haven't experienced in my career. I wanted to learn and implement game design, I wanted to design the visual look and feel of a game, and I wanted the challenges that came with a small team and a limited amount of resources. My experience is that constraints are often a good thing, especially in creative endeavors, as they force you to channel your energies into a focused path of creation.

The constraints and challenges that I've experienced in my time at school however, came in large part from the factors outside of the game development itself. This wasn't something I was anticipating, and it's something that's caused a lot of frustration and energy as I try to figure it out.

One of the biggest challenges I've faced is my work arrangement. Because I work for a video game company, I'm prohibited from profiting from a game that would be a conflict of interest with my job. Additionally, because I'm a working professional, I'm not allowed to enter my game into the student indie game festival, which is one of the goals of the program at the U. Because I can't enter my game into the student IGF competition, my fellow students cannot use my game as their thesis game, as they wouldn't be getting the experience that the program was designed to give them. Therefor, any help I get from students is extra time they have when they're not working on their own projects. Because of my professional status, I'm also prohibited from working on other student's projects. This became a problem on the student game Vinyl. This was a music game developed by the grad students in my cohort wherein the player played as a character on the needle of a record player. The player would "surf" on the needle in a half pipe to move around obstacles and effect the music being played.

After hearing this idea, I really wanted to animate for it. Board animation, particularly surfing animation is something that I have always loved to do. My demo reel is full of personal pieces where I've animated surfing characters. I love animating surfing characters, I love the body mechanics of board sports. I really wanted to animate on this game. When I offered my services, it caused quite a stir among the professors, as it was really important to everybody that I not work on the game. I understand the reasoning, as it would have invalidated some of the work and the deals they were working toward. It was still frustrating, because it kept me from being able to contribute to a small project that I was really excited about.

The lack of other student's help has also been a major hindrance. I'm so grateful for the time and enthusiasm of the other members of this team, as they're going above and beyond their regular schoolwork to help with this game. I really appreciate it. It's really amazing that they are helping out in addition to everything else they're working on. This grad school is insanely busy and stressful, they're really going the extra mile. Because it is a side project for everyone, however, it also means that it quickly slips in their list of priorities, and work on the game can be agonizingly slow at times. Wrangling everyone and constantly keeping in touch, and organizing meetings, and trying to keep them excited about the project has also exposed a major weakness in myself. This type of thing is definitely not my strong point. Constant communication, status updates, and trying to keep everyone excited about our progress, is definitely not one of my strengths. When I haven't been placed in leadership or supervisory positions in the past, I have always preferred working on my own, getting my stuff done fairly independently, and being responsible for my work alone. When I have acted in leadership or supervisory roles, I've done better at this, but it's definitely not something natural to me. As a result, I've let a lot of the communication slip on this project. This has resulted in sporadic updates, and bursts of progress from others. My own progress has remained fairly steady (taking into account my personal schedule) but the progress and the cohesion of the team has definitely been wanting. If this game is going to get to a playable representative state, it's definitely something I have to work on.

I'm going to wrap this post up, it's getting long.

Additional levels & background patterns

 

This last one is playing with deflecting walls. The two gray bars on the inside square are supposed to be deflecting walls. When you hit these walls with the bullets, they deflect. This is there in case you need to fire on yourself.  

None of these are final, just playing around with ideas.

 

Bonus Level

Here's an idea for a bonus level. Multiple shooting shapes line up at the top of the level. When the timer starts, they start descending at varying speeds. They start shooting, and the turrets on the side start shooting.

Your objective is just like the game, to match all the shooting shapes with the target shapes below in the given time.

Early interface design

An early design using an inner circle for the movement, and an outer circle for the rotation, freeing up the right hand for firing and pickups.

Idea for a start screen

I'm playing around with an idea for the start screen. In following the minimalist approach, I thought I'd start the game with the following load screen.

After the game loads, the shapes of the logo fade out, and the shooter and a 30 second timer fade in. (As a note the timer is placeholder, I'd like to find an animated icon or something that depicts time better) 

At this point, the player can move his shooter around freely and shoot. The timer will begin to count down so hopefully the player gets a sense that they have to do something. Hopefully they realize they have to shoot the logo.

Once they hit the logo with a red bullet, it turns to a red "Start".  If they hit it with a green bullet...well...I'll think of something, maybe it turns back into the full logo with the shapes. The timer wills till remain, and the player will still be able to move and shoot.

If they hit the red Start with another red bullet, the start will turn into the target shapes which will start blinking. As the target shapes blink, level one appears.

Hopefully it becomes a fun start screen as well as a simple tutorial.

Unity, and source control

For our project we're using Unity. After a short discussion with our group Unity became the obvious choice. Here are the reasons we're going with Unity:

• Cross platform
• Friendly to indie development
• Can do what we need it to
• Our engineers have experience with it
• Supports both 3d and 2d art assets
• Friendly enough for artists

Talking with a friend whose developed for mobile, he recommended using Atlassian Bitbucket and Source tree for its repository and version control features.

I started setting things up with Unity, SourceTree, and Bitbucket. I looked at forums, viewed video tutorials, talked to my friend, and was inching my way through the process. I've never done anything like this and it was all pretty new to me, one of those situations where I didn't know what I didn't know. 

I've mentioned that one of the reasons I came to the U was to get experience with a small team developing a mobile game. Well, part of working on a small team means you take on more responsibilities, learn what you need to and do whatever needs to be done.

In the studios I've worked at it's been a little different. They've been bigger studios, and I've specialized in animation. I've only had to worry about the responsibilities associated with animation. It's been really nice to call on riggers to do the rigging, tech artists, engineers, and IT departments to do what they're best at.

So the progress was going pretty slowly with Unity and version control when Jinghui contacted me with his first prototype. When we met to view the prototype, I realized he was up and running with Unity, and familiar with version control enough to set it up himself. Problem solved. I can spend my time on design and art, and he can handle the tech side of things. I now send him my artwork and he throws it in the prototype. Kinda nice.

I'm sure as we get bigger and move into this more we'll have to implement a little more structured, organized system, but for now, I'm happy focusing on art and design.

More Levels

Playing with turrets, shield pickups, land mines, and laser beams.

Design Ideas

A few ideas for the game:

Balance:

• Wondering if the white circle is going to be too powerful. 
• Try giving each shape their own speed. 
• Circle is the slowest, Square is medium, Triangle is the fastest.  

 Mobile Navigation, Level Design

• Prototype a Pacman type navigation for mobile. 
• The player character always has velocity. 
• The level is  a maze with the pathway just wide enough to go in one direction. 
• The player swipes up down left right to turn into the corridors. This allows swiping with one hand and firing the bullets with the other hand.
• Any pickups could be lined up next to bullets, tapping the pickup activates the pickup, whether it's a shield, a grenade, or a color.

 

Industry Panel Feedback

I reorganized my pitch from the first time I presented it. After seeing the pitch, one of our Professors, Roger said that there was too much text on my slides. I just read the things that were written on my slides, he said it was distracting, so it was a great note. I don't like presentations that do this, so I should have known better. It's the same reason I hate watching movies with captioning turned on. There must be something about our brains wanting to read text that's right in front of us, even though a person is telling us exactly what's written.

I took out most of the text and just left the images, it represented more the kind of presentation I like to see.  I felt it was much stronger. I then took the pitch to Cohort 4 at the U and presented to them. I received some great feedback, and rearranged my pitch again.  

The pitch to the panel didn't go as smoothly as I would have liked, some of the things I rearranged felt a little awkward, and I'm going to revert a couple things to the way it was originally. Other than that, and probably a little more nerves than before, it went ok, just not great.

One of our producers, Jen gathered the notes from the industry panel, super helpful. Here is the feedback:

• Pacman meets Defender with a twist.  like the idea of making levels that become challenging. need more puzzle development.  solve to have access. nerd challenge: how good are you? keep track of what's going on. make it scarier.
• Kernel of an idea: its biggest struggle and challenge/weakness. game of change: it can be a huge frustration,
• As things change I need to adopt strategy. why even try it.  all my work went to waste b/c stuff is changing.  lock part of the board or turn base thins so they can't change it.  
• I like the fast pace, simple mechanism. complicated levels. figure out strategy. have both kinds of levels would be overwhelming.  In a simplified game it would be a lot of fun.
• less frantic, slow it down.  more puzzley.  AI can be wandering around in more pattern base notion so see it and use to your advantage.  Lost it with platform. perfect for tablet I think mobile. I don’t see it work with console.
• I agree. nothing bad.
• I see this mobile. Not $5 on console.  limited control scheme on pad. keep simple, more success for mobile.  then add more features.   
• Meter them out. so they work for that particular level. game built on patterns and predictability. randomness crushes that.
• Randomness makes you feel cheated. hate it and don’t understand what happened.   increase strength of puzzle.  use it more as a puzzle, changing shapes, static, there are only certain ways, more puzzle and solution than randomness.
• Hate randomness.
• Pattern behavior and predictability
• Worry about color blindness
• Mobile. nice. on path and have clear document
• Nice pitch. kind of like randomness. combination
• Take a diff approach, take out shooting. have to tag each other. so its more of a puzzle. hate virtual D pad.  prefer swipe mechanics. input you can solve for mobile.
• You don’t need to control ball if ball rotates randomly--shoot other pieces. make it more time shots to hit ,,rotate faster/slower...level design...1 button really fun game.

The panel was fun, the panelists were very helpful, and about half of them are friends and former colleagues, so it was good seeing them. 

From the panel I received some great ideas and direction that I'd like to iterate on. Even though I don't practice this as much as I should, I believe a creative endeavor like this needs constant feedback, early and often. My tendency is to try to get things as perfect as I can before I show it to others. Inevitably there are changes that need to be made, and it's a lot more difficult to make those changes when I've spent so much time.

First playable prototype!

Well here it is, the first playable prototype, our programmer Jinghui put this together in Unity. It's early and we're trying to figure out basic movement within a maze-like level, so it's simple, but pretty awesome to see something up.

Overthinking the obvious? Choosing which platform to publish on.

A few weeks ago I presented Flux to an industry panel at the University of Utah. The panel included representatives from the major game studios in Utah, as well as smaller start-ups, and even a recent graduate of the EAE program. The panel was very informative and it was a great opportunity to get feedback from professionals and peers.

There were roughly 10-12 panelists. After the presentation they all took turns giving feedback on the game. While there was a lot of differing opinions and comments about some of the features, the comment that stood out most and was pretty unanimous, was that this game should definitely be published as a mobile game. The reason that everybody commented on this was because I had pitched the idea of publishing this game on the new next-gen consoles and services, namely Steam, Xbox One, and PS4.

Crazy right? When you look at Flux, this is very obviously a mobile game, it looks like a mobile game, it feels like a mobile game, and it plays like a mobile game. You can see yourself playing this game waiting in a line somewhere, on a bus, or wherever people play mobile games these days (which is pretty much everywhere). So why would I consider publishing this on anything but a mobile platform? And furthermore, why would I target the big 3 platforms where the market on those platforms consists largely of hard-core gamers, who, when they sit down in front of their consoles are usually not in the mood for a casual game? Ludicrous.

I'll keep from spoiling what my final decision is, and let you be the judge as to whether I'm over thinking this or not. Let me spell out my reasons.

Flux was originally a mobile game, particularly an iOS game. It was conceived as an iOS game and designed as an iOS game. Part of the reason I'm attending the Master's program at the U actually is to have the experience of developing an iOS game. The reasons are obvious. The market is huge, these devices are everywhere, the platform has opened up smaller less expensive games that are able to turn a profit, and these games can be made by teams as small as one. Whatever you think of Apple or Steve Jobs or the iDevices, you have to at least recognize that the iPod, iPhone, and iPad revolutionized the way we do a lot of things, and made these devices an inseparable part of our lives and our culture. Reflective of this fact is our toy basket at home, which has become a technological graveyard for dead iPods and cell phones that the kids can play with.

So why did I change my mind and choose to make Steam, the Xbox One, and the PS4 my choice for publishing? I can probably boil it down to 4 reasons:

1) Control Schemes
2) iOS publishing
3) Disruptive Innovation
4) Colin Cowherd

1) Control Schemes

The mechanics of Flux are simple, move the shape around, rotate it 360 degrees, and shoot. This being an iOS game, there a few options for this. What I thought was obvious, was 2 virtual joysticks. One joystick would be used to navigate the player, the other joystick would be used to rotate it, and the red and green fire buttons would appear next to the joystick. The control scheme would look something like this:

This control scheme, or something close to it seemed like the simplest solution. After talking to a few people about it, doing some research, and discussing it as a team, however, it appeared like the decision would not be that easy.

Virtual joysticks, it turns out, are a bit of a controversial topic in the mobile game market, some people like them, a lot of people hate them.

There are various configurations of virtual joysticks. Here's an excellent article on Gamasutra written by Graham McAllister about the pros and cons of various virtual joystick schemes, and their pluses and minuses:

A Guide to iOS Twin Stick Shooter Usability

Another problem with this scheme is the fire buttons. You'd have to take your thumb off the joysticks to fire. This isn't ideal especially for a shooter whose targets are constantly moving. I wondered if I wasn't forcing my game onto a platform that didn't fit the control scheme.

The industry panel gave me some excellent suggestions on how to tweak the design to make it work with mobile, and I can always iterate on it to find a better solution. As I thought about other options, my mind went to the traditional controller, and how nice it would be to just use the old tried and true:

 2) iOS Publishing

 

I knew that publishing on iOS would bring many challenges. That's part of the reason I wanted to develop on iOS, I was interested in cracking that problem. I was interested in finding out how to market an iOS game in the very crowded iOS marketplace. The benefit of iOS is the size of the market, the downside of iOS is the size of the market. How do you get your game noticed when hundreds of games are published every week?

Our Lead Producer, Rody Rodriguez did some excellent research on iOS publishing that revealed just how tough it is to be successful with an iOS game. Here's some of what he found:

● App Sales Figures
○ Total Active Apps: 896,720
○ Total Game Apps: 151,676
○ Games submitted in July: 1,118 (118/day)
○ Average App Price: $1.50
○ Average Game App Price: $0.83
○ “Games is the biggest single iOS app category. In a study earlier this year, Distimo found that gamers
downloaded 5 million games in just one month.”
● Games contribute 62% of all iPhone app sales
○ Free Game Apps 36.25%
○ Paid Game Apps 45.75%
● Games contribute 48% of all iPad app sales.
○ Free Game Apps 35.00%
○ Paid Game Apps 42.75%
● iOS game sales compared to Android
○ iOS games earned in Q4 of 2012 3.5 times more revenue than Android
● Aspects to be Aware of as it pertains to iOS App Game Market
○ 60% of all developers don’t break even
■ “To put his findings in context of dollars, half of the developers surveyed have made less than
$3,000 in lifetime revenue. A quarter have made more than $30,000 on the App Store, and
another quarter have made below $200. Another 25 percent reported that they’ve earned
between $1,000 and $10,000 total.”
○ Top 1% of iOS game developers make ⅓ of all total revenue
○ Bottom 80% represent an anemic 3% of total game revenue
○ Top Earners spent on average 14% of time on promoting and marketing the gaming app
■ However, most developers do not spend much time in promoting their gaming apps.
■ 52% of developers spent 5% or less on marketing efforts

Some excellent statistics, and some daunting facts about publishing. What at first was a challenge I wanted to tackle became enticement to look to the next gen consoles.

With the flooded iOS marketplace, I wondered if the timing was right to jump into indie self publishing on the next gen consoles. It's a new market, relatively few competitors, and I'm curious if there would be many casual games on it (admittedly, there's probably a good reason there's not too many casual games on it.) While the information about self publishing on the consoles is still trickling out, it looks like both Sony and Microsoft at least appear to be committed to indie publishing.  An example of this is that fact that it looks like you can use a normal console to develop your game without needing an expensive and hard to get development kit.

Essentially, after the industry panel, I wondered if I was jumping the gun with the next gens, and should figure out ways to make mobile work. There are a few other reasons why I wanted to jump to the next gen consoles and Steam, but this post is already too long, so I'll pick it up later.

The Prototype as a Published Game

The idea for Flux came from a larger game idea I had some years ago. This game is meant to be a full console, next-gen experience, including many characters, worlds, and multiplayer features. Because of the scope of this game, making it on my own is pretty unrealistic. With Flux, I've tried to extrapolate the key ideas and design elements of that bigger game and abstract them into a smaller game with simple shapes and levels.

Flux then, essentially, becomes a way to whitebox or prototype the design of the bigger game. By making a smaller more manageable game I can focus test the design, and iterate and polish the idea with relatively minimal resources. If I can make it a polished enough prototype, then I can release it as an inexpensive mobile game, get it in the hands of more people and start building the community and further refining the design based on the feedback and experience of the players.

In a perfect world, the mobile version does extremely well, and the revenue generated from it goes to pay for the larger game. This is one of the other ideas I'd like to explore in developing Flux; can you make a polished prototype, publish, and sell it to help you build the bigger game.

Design and Development

Part of what I'd like to explore with Flux is the design and development process itself. I'm particularly interested to see if we can manage scope in a way that will allow us to produce a good, fun game with the limited time and lack of resources we have. The minimalistic look and feel of this game is a result of this philosophy.

I look at design, scope, and development as a series of concentric circles emanating from the center. 

At the center of these circles is the main idea, theme, or essence of the game. If we can discover and define what that is early on, then we have something to build the rest of the game on. That's not to say that finding the main idea is an easy thing, that it doesn't take iteration after iteration, or that it won't change as we develop and test the game. But starting out with a central theme will help us focus on what we're trying to create. With most creative processes I've been a part of, what we initially start out creating usually changes along the way. And with games especially, as you put your prototypes in the hands of your players and listen and react to their feedback. it should change along the way. 


The main idea or theme that I'd like to explore with Flux is change, and how that change affects our choices and strategies. If that's the main idea, then we move to the next concentric circle and find the basic objective, mechanics, and the player elements that we'll use to explore this theme. For me, I'm using shapes, circles, squares, triangles, and red and green bullets to explore the theme of change. The basic design is to change the shapes of other players along with your own, by shooting them with different colored bullets. The objective is to make the shapes in the level match the target shapes.

Once I have the basic design and elements and know how they support and explore the theme, I can then define the mechanics and abilities based on the theme and start prototyping the design. At this point, the resources needed have been very minimal. I can use sketches, writing, and thoughts to develop the idea. We then start prototyping the mechanics and basic movement.

I can figure out control schemes, and how I want the player to move in the world. I wouldn't worry too much about polish, but I'd spend time on controls and movement to get a good idea of feel. Once I get the movement feeling good, I can start giving it abilities, in Flux, this is shooting.

As we develop the game we ensure that each concentric circle is working well, is fun, and supports and contributes to the central theme of the game. If something presents itself that is more fun than what we initially had in mind, the earlier we find this, than the less painful it is to change. As we move outward in the circles, changes to the inner circles get harder and harder to make, because the ripple effects become harder and harder to manage.

Ideally if the very center of the game is fun, and we find and polish that fun early on, then keep that fun throughout development, we can add features and elements as our time and resources permit. If we have the resources, than we can start to add better vfx, better sound fx, more levels, etc. If those resources expand, than we can move onto development of characters instead of shapes, worlds, instead of simple mazes, and storylines, etc.

I'm interested in exploring this idea of development and design because I believe much of our industry works in the opposite way. They spitball and blue sky as many elements and features as they can think of early on, and start iterating and prototyping on all of them. As the features grow and the design expands and changes to fit in all the prototypes and elements, the game and development quickly balloon to an uncontrollable point. At this point in development, usually late in the cycle, in order to ship the game, the developers are forced to cut features, trim scope, and piece together the remaining elements. This often comes with a  lot of pain, because these features and designs have cost a lot of time, thought, energy, and resources developing them.

I don't mean to criticize this process, a lot of great games have come from this process, and a lot of great developers really thrive by making games in this way. Also, for bigger studios who have the luxury of abundant resources and flexible deadlines, this process can be very successful. For myself however, with the limited time and resources I have, I would like to explore the concentric circle approach and see if we can't make a game in a more focused, disciplined way.

Sample Levels

Here are a few sample levels. In getting feedback from an industry panel a few weeks ago, there was some confusion as to whether this would be a slow paced puzzle game or more of a quick action game. I want to try to keep it as an action game, so we'll have to make sure these levels don't move into too much of the puzzle realm.

Additional Design Elements

Here are a few elements that can be added to the levels to increase the degree of difficulty. Since there are only so many variations on the pattern of the target shapes, we'll have to find other ways to make the levels challenging.