Fall Semester Prototype

The programmers put a ton of effort into the game and by the end of the semester they put out a one level prototype.

It included:

• the tutorial start screen
• a level including shape changing
• shooting
• navigation
• tapping the enemy shoots

There were, I believe 4 or 5 shapes, if I remember correctly. When I played it, it was the first iteration I had seen where the player could control the shape, shoot, and change the shapes of the other player. 

There was a lot happening on the screen, and it was difficult to know what the objective was, but it was awesome seeing an iteration of the design after so much time on paper.

The programmers showed it to their CS class, and they received some good feedback. A lot of the feedback was that it was a little confusing and frustrating, but predictable based on the prototype. The test did not go how I think we would have wanted, but I wasn't too worried, I knew that there were a lot of changes that we could make that would improve the game. 

One thing that I learned from the experience was that I needed to try to be more involved in the design and development. I had been unable to spend much time in development because of my other responsibilities, and beginning in late November, I started to consider how I might change this.

Name Changes

Throughout the process the name has gone from Flux to Fluxo. We moved to this because there are already a lot of games out there called Flux. We like Flux, but with the name already being used I thought Fluxo might work.

None of the team really liked it too much, so we stuck with Flux. At this point it's probably a problem we'll solve if we publish the game.

Tutorial Screen II

We tested that with users, it worked well, Skyler was able to implement. Here's another iteration we made based on feedback, this made it in the game:

S

Tutorial Screen

A few posts back I wrote about the start screen tutorial, and how we wanted to make a start screen that served as a tutorial to teach the mechanics and objectives of the levels.

The programmers implemented this, but we were unable to iterate on it much and test it. The result was not what we had hoped for, and it proved to be a difficult sell.

In order to solve the problem, we decided to create tutorial screens with text and demonstrations to teach the user. Here's what I turned into the programmers:

 

Twin Stick Shooters

We studied from a lot of games that incorporate dual stick shooters, geometry wars was one of them.



This article on Gamasutra proved to be helpful:

A Guide to iOS Twin Stick Shooter Usability 

In the article they reviewed multiple twin stick shooter configurations and which ones worked the best.

This was a conclusion they reached in the article:

Core Mechanics

The dual virtual joystick proved to be quite a problem to solve. We tried many different set ups

At first I placed the direction and fire buttons at the bottom. When I held an ipad, however, I thought they might be too low, and it might be too easy for the ipad to tip over. So we placed them on the sides. 

We iterated a lot on the dual joystick, these are some of the options we tried:

• Left joystick moves the shape, right joystick rotates gun
• Left joystick moves and rotates. 
• buttons fired continuously, when pressed
• touching a shape on the screen fired the button
• constant speed vs. no constant speed

We tried a lot of configurations, and tested them extensively with people. Most of them seemed very difficult and unintuitive to use. 

This is a game that works really well with an xbox controller, but not as well as the tablet like we had thought.

It was difficult to test whether or not the game was fun until we got the controls working right. Eventually we removed all the mazes and walls for the first ten levels and that took away a lot of the player frustration.

Skyler did a ton of work on the controls, with a lot of back and forth, I think we eventually landed on something that works.

Time

Work heated up the first semester, and I found myself in a lot of overtime again. Between the overtime, and the work the rapid prototyping class was taking, I was left with very little time to meet with the programmers. I tried to support them asset wise, and meet as often as I could, but it was very difficult.

They blazed ahead and worked a ton. I gave them this blog, and any design documents they needed, but I think they eventually created their own design document and worked from that. They had to create a document with schedules and features which they turned into their teacher. They seemed to work from that, and I worked from what I thought the design and art priorities should be, and we tried to work out what needed to be worked out. I enjoyed working on the team and hammering things out, but it was definitely difficult without having more frequent contact with them.

I don't remember seeing their design document, and I never really worked from any design document. Early on, I mentioned to them that producing was not my strong point and one of them might need to function as the producer. Andrew stepped up as the de facto and did an awesome job. He's got a way with communication that I don't, and I think our team greatly benefited from his skills.

Being on the same page with milestones, features, schedules, and priorities was difficult for me. I think the programmers did well with this, as they were in constant communication, but with my lack of time, the lack of meeting and communication meant I felt a little out of the loop the first semester.