Tesla’s Touch – Week 1

The Design Box: The design box is a method of helping to narrow your game design ideas by assigning the four walls of the box different criteria that your game must meet  in order to get inside the box. The four walls are; your audience, the technology to use, aesthetics, mechanics. The audience that we wanted to reach is the casual gamer market that exists on the app store now. Our tech was to use multi-touch user inputs using the Unity game engine. Our aesthetic had some vague thoughts about realism, but lacked a theme. Our game mechanics were short 1 screen levels, multi-touch, puzzles, electrical redirection.

Audience: The audience that we are directing our game towards and that we want to buy and play the game is the casual gamer. This is a term tossed around a lot these days with all the new games available on smart phones and tablets, and we needed to define it more. Our audience already plays games like ‘Angry Birds’ , ‘Candy Crush’, ‘Where’s My Water?’ and knowing this we looked at these games and asked what makes them casual. They have a pick up and play UI, and short levels that do not demand a long play session.  The levels get harder the further you get, and they have some sort of rating on each level saying how well you did and you can try and go back and improve. This guided us to make sure our levels are short, no long game play sessions. Puzzle progression needed to start simple and get harder.

Concept: One of the concepts that Mark, one of our engineers put out there was a multi-touch game about lightning redirection. We all liked the concept of the game, but continued brainstorming for a while. We had some other ideas, but also kept coming back and refining the idea of redirecting the lightning. After discussion about why you would be redirecting it, what you would do with the lightning we decided on a simpler version, where you have a power source on one end of the screen/room and something that needs to be powered on the other end. Within this we can have many obstacles and puzzles placed between these two that the player must solve to clear the level.

Aesthetics: While our original thoughts on the aesthetic of the game was kind of vague. Upon deciding on the electrical game, we then were able to nail down a really good theme that went along with our game perfectly. Our artist came up with the idea of a teslapunk theme. This not only opened up the aesthetics and graphics of the game, but game us a whole list of devices and problems we could draw upon in the Nikola Tesla world. He had many great inventions and labs.

Having our concept and goals in mind we set off to work.

Catacombs Post-Mortem

This was an interesting and comcatacombs_screenplex prototype in which we tried to address a difficult mechanic. We were given and assignment of competition vs cooperation. Using this lens of game design we decided we wanted to try and make a game that was right in the middle of these two ideas. We came up with a game based on trust and betrayal of fellow players.

We were all excited about the concept we came up with and excited to get started. As producers we set up a Trello backlog and got our task list up and running. Next we started to work on the puzzles and the betrayal mechanic. I wrote up a script that helped with the motivation of the mechanic. After much trial and error and programming problems, the whole mechanic ended up having to be cut from the game in week 3. This was a huge disappointment for me, because what I had spent most of my time on was useless. We were still left with a fun cooperative puzzle solver. One thing I did not do well during this prototype was keeping up with backlog, but Owen was a champ at that. We both had a good points and bad points but they balanced out very nicely. I also built and presented both the presentations for this game which both went very well. Our team also had a communication problem of what was being done and how, and the priority behind them. This was mainly hindered by the language barrier that we had to work with. I didn’t mind it, but it did make communication a little bit harder. Main lesson I learned from this prototype was keeping up the engineers and learning their capabilities and time it takes them to implement things. We were constantly having to crunch to make sure the game was where it needed to be.

Chicken Crush Post-Mortem

This was a good prototype that turned out very well and ended up being quite fun. We picked the original arcade game of ‘Frogger’ to build from. I actually worked well as an idea moderator and helped to come up with what we would work on for the first 2 iterations. I immediately set up the backlog and worked to get all the team members signed up and using it. The team never fully got behind Trello and the backlog, and communication broke down a little bit. I worked with the engineers to help divide the work between them. As it would turn out later, the work wasn’t divided equally even though they had helped divide it.

If there was one project that I felt didn’t go very well on my end, it would be this prototype. I was the only producer for the team on this project which made my role even more important, but I was absent for a few days due to illness which made me fall behind on the upkeep of the backlog.  One thing that went fairly well on this project was the implementation of the backlog through Trello. I had one engineer that failed to see the use of the producer and told me so, and liked to take charge and act like producer and engineer. He was a great engineer and had a lot of good ideas. The other thing that was hard on this team was that the engineers didn’t communicate very well. One of the engineers felt he was doing most of the work, and others would get upset because what they worked on didn’t end up working out very well in the game and it was taken out.

New Project, New Team

So we received our new teams and assignment today for project #2. On this team I am the sole producer and it should be an interesting experience. I want to try a little more lax style of producing. I want to be more of a mediator and let my team pick their direction and just try and make sure they are all heading in the same direction. This could either go good, or badly but it should be a good experience either way.
                For this assignment, we have to pick an 80’s arcade game to create and then make variations of in order to make the game ours. After talking for a short while and watching some videos of old arcade games, we decided on the game of Frogger. After deciding on the game we had to choose which programming language of the two allowed we would choose. The two languages we had to choose from was Flash ActionScript or HTML 5. Not one of the 3 engineers had any experience in either language, so I reached into my pocket and used a coin flip to decide. It landed on HTML 5.


                For our first major change to the game we decided to change the theme a little bit and go with chickens making a run across the street, and to add a second player to make it more of a race. We have to develop this first game variation. In production class I learned about a management tool called trello. I am currently setting up the account and board and hope this helps to keep everybody, especially the three engineers.

Murphy’s House Post – Mortem

Working on the project ‘Murphy’s House’ was an amazing experience for me. This was my very first video game project that I ever worked on, and I not only got to make a great game, but also work with an amazing team. Now that the final prototype and pitch are completed I will take a look back on the process of the project. As a producer my duties were varied and during this project I learned what a few of those responsibilities were. One of the best things I learned is the process with which to keep track of team members responsibilities and how their progressing. This process is known as scrum. Through this process I have found some of problems we had on the project and also some of the successes.

During the beginning of project I felt like I didn’t really have a lot of tasks to do, at least not that I knew of. As the project progressed, I learned of new things that I could be doing. One of my biggest problems that I felt I encountered on this project was trying to find a balance of time between starting school, working, and time with my family. I still feel I haven’t found a good way to balance everything that I can be as productive as I need to be. 

Some of the good things were being able to help plan out the scope of the game and find ways to make the game humorous and compelling to the player. Allen and I were able to work well together in order to get all the writing done. Another good aspect was maintaining the open lines of communications between everybody and making sure all necessary assets were passed along to those who needed them.

The problem areas that are mentioned above are the areas that I need to work on the most. I need to keep a better schedule and task list for myself so that I always know what I need to be working on. Once I have that, I can work on making sure the backlog lists and priorities are set and everyone knows what they need to be working on for the project. I so far have not come up with a good solution for balancing of time, but will continue to work on and refine as I go.


This was a great project and game. I got to work with a really amazing team who came together to finish a good prototype. I look forward to working with these team members in the future, and hope to take this project a little bit further.

Project Management Mistakes, and Fixes for Future.

Each week that I progress though this program I learn something new and helpful. Unfortunately, some of these insights come from having failed, or made a mistake. I thought our project was really coming along well, and felt that a lot of my work as producer was done and I was watching our artist and engineers just working like crazy, and I felt guilty about not having more to do. I brought this up in our production class and found others felt similar. Our professor told us that, while we felt that we did not have a lot to do as producer, there was more we should be doing and we just did not know everything yet, because we are here to learn that.
    Coming down the home stretch of the last few days before our presentation, I am finding out that I kind of failed the rest of my team as a project manager. Our prototype is not where it should have been and I have to take a lot of blame. As a class we have been learning the Agile method of software management. I have learned some of the stuff that I should have been doing and have not been and it is showing in how our prototype is progressing. I should have been much more active in creating a back log and making sure it was accessible to all the member of our team. I should have also made sure that the back log was prioritized so that things got done in the order that we needed them done.


    Working with another producer has also been an interesting experience. I have had a hard time knowing what things I should work on, things to work on together, and things for him to work on and how to combine all these efforts together. We are really close to a full working prototype of a level, but we still have some work to do. I have learned a new part in what it means to be a game designer/producer and look forward to implementing that into our next prototype.

Starting the Journey

This last week I officially started my first semester at the University of Utah, in the Masters of Electronic Art and Engineering Degree or MEAE for short. This program is only in it’s fourth year and is ranked #2 in the nation. I graduated with my undergrad from UVU in Digital Media. I have currently only been working as a producer on short films and promo videos. I have always had a passion for storytelling and gaming, and figured I would combine the two as a game designer.

First Impressions:
My first day in class we got together and me our first potential ‘clients’ who we would be making the game for. We were given the parameters of the game; for a mobile platform, focused on the age group of women age 25-50, using the MOAI programming sdk. We were then allowed to ask them questions and find out what they liked in mobile games, what they didn’t like etc. Following the Q&A session we split into smaller groups that consisted of 2 producers, 2 programmers, and 1 artist. We had to come up with a game and pitch the idea to the clients in 2 days. This was not a huge rush, but took more thought and effort than I expected having never gone through a game brainstorming session before. We came up with an idea and the mechanic that would make the whole thing work, and pitched it to the clients. They had some good feedback but gave us the go ahead for the project. Once approved we set to work creating our prototype which is due at a final pitch in 3 weeks. What is mind boggling to me is how fast this moves, and others telling me that it is usually a much faster process. Today we went through what we would each be working on and set out. Me and Allen, the other producer, began fleshing out the mechanics of the game and trying to design a game that would be fun to play and keep the player on their toes. We spent several hours going over some very simple mechanics to try and make the game an actual playable game. Once pitfall we ran into was the giving of options to the player and how to give the player enough incentive to choose different options. I can already tell that this is going to be a ton of work, but I look forward to enjoying every second of it.