Team Phrag

So the team decided to call ourselves Team Phrag. I believe it stands for PHRenetic Arts and Games. Not my choice, team names have always sounded a little hoaky to me, but if it helps with unity, than go Team Phrag!

CS Capstone presentation

After the summer, Jinghui was unable to help on the game anymore. He had his own school work and master's thesis game, and was just too busy to help out. I really appreciate the work he was able to put in, working on side projects is always difficult, and I'm grateful for the work he did.

What that meant, however, was that I was still without an engineer or technical artist for my game. I had taken a stab at learning Unity, and felt that it was something I could definitely learn, but in the little time I had with work, classes, and other repsonsibilities, as well as being the artist and designer for the game, I knew that I wouldn't be able to learn what I needed to fast enough to make the game. So I started the fall 2014 semester without any programmers or technical artists.

I was registered for the rapid prototyping class, and was hoping to use that class to make prototypes of my game. The format of the class was that we would divide into teams of 6 - 10 people and make 4 prototypes throughout the semester. The teams consisted of engineers, artists, technical artists, and producers. I was hoping Bob and Roger would let me use my game as one of the prototypes, and just rotate the teams through to help with the prototype. A pretty selfish proposition, but with the limitations I was working under, I was desperate to find someway to make it work. After all, I needed to finish the game to graduate.

Dr. H. James de St. Germain

Not surprising, Bob and Roger declined to let me use my game as one of the prototypes, but they did refer me to a Dr. H. James de St. Germain. Dr. St. Germain runs the senior capstone class for the undergraduate computer science students at the University of Utah. I contacted Dr. St. Germain and he allowed me to come present Flux to his class on Sept. 10.

I presented the game, and as far as presentations go, I think it hit smack dab in the middle of mediocrity. (Presenting is not my strong point)

The format was that 3 of us presented, (Josh Maag was one of them. I would later go on to meet Josh Maag during my time in the Foundry.) and the students were allowed to choose if they wanted to use any of the 3 ideas for their senior capstone project.

The response to the pitch was pretty tepid, as I was leaving the class a student grabbed me and said he might want to work on the project with his team, we exchanged contact info and I left.

This turned out to be Michael Banks. After a couple weeks he contacted me and said that he and his team wanted to meet to see if we could work on the project together. 

A week or so later we met, and we all agreed it was a project we could work on together. So finally after a couple years of trying, I had a team of 4 engineers from the computer science program. From left to right, me, David Onken, Skyler Chase, Andrew Clark, and Michael Banks. Forgive the blurry picture.

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.