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.
This was an interesting and complex 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.
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.
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.
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.
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.
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.