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.