When taking on the ability to directly manipulate thoughts of other people there are many problems that present themselves. Trying to write down all the thoughts of lots of different individuals becomes problematic because of the number of thoughts a single person can have. The next problem is how to plan for all the possible combinations of thoughts that a player could make. If the player is able to take any thought from any NPC and place that thought in any other NPC in any order then it creates an almost endless number of permutations.
How then to try and bring those permutations to a more reasonable level and still let the player feel like they are making meaningful choices? We have decided to try and limit the players choices in a logical way. We started with a room with 4 people who each have 3 thoughts. Just this limited number of possible thoughts presented thousands of possible permutations. Moving forward we decided that the player would only be able to swap one thought for another, and this took our permutations down about 150. But this still seemed like way to many possibilities for the player to choose from.
We really wanted the solution to be obvious to the player so we wrote our the NPC thoughts in such a way that the solution was obvious to us. We brought in a few people to play test our thoughts and see what solutions they could see and would want to try. What we thought had been obvious to us was not what other people saw. This really clued us in that everyone interprets thoughts differently and our design had some flaws. We could not have a single solution to a problem and expect everyone to manipulate the same thoughts to get there.
So knowing this we decided our game really needed to have many possible solutions to every problem. We decided to start way small for our prototype. We have one room with one NPC who has 3 thoughts. We start the player with 2 thoughts in their inventory and give them a short tutorial on how to place a thoughts. With only being able to switch one thought, this limits our possible outcome to about 9. This is a much more reasonable scope for the prototype than dealing with hundreds, thousands, or millions of permutations.
So we had to go over our schedules for our prototypes today, and quickly came to realize that nobody had really made one yet. After being raked over the coals for a while, which we deserved, I have made my first pass at a long Milestone schedule.
While this still needs to have some info filled in, it gives a good idea of the major builds and sign offs that need to happen. This is to give an overview of the entire game schedule. I also have made a similar schedule for the first sprint.
This has the features that we will be working on for this sprint, as well as a time estimation for how long each of those features will take us. This Schedule can now very easily be translated into a back log to share with everybody. The next item that really needs to happen is to create a brilliant 1 page design doc that will help guide the team in a unified direction.
So today we got the voting results back on our game. It was given to us with no game names attached to the results. So just using the raw data of votes and no bias of game, we had to narrow it down to 2. After about 2 hours of discussing the votes and what aspects of the votes were most important to our team we came to a decision. Once we reached our conclusion we took that to the teachers and they informed us which 2 games we chose.
Our group ended up picked the game ‘Ragwheel’ and the thought manipulation game we have named ‘Make a Man Thinketh.’ I am happy that the racing game got picked, but I am not very happy with the game MAMT, because I see way to many problems with the game and the design to really want to tackle the project. The rest of my team feels that this is the most risky game, but that it will be the most likely game to get noticed by at IGF.
I also am not a huge fan of selecting a game to make by trying to decide what is going to be most innovative, or most controversial so that it will be noticed by IGF. I played quite a few of the IGF student games in research and a lot of them were not fun at all. I agree that if you get picked as a student showcase game that it is a great boost to your reputation and career, but if you don’t get picked(most likely) then you run the risk of having worked on a game that isn’t fun but was made to be controversial for IGF. I would much rather be able to take a game into a job interview and say, ‘hey look at this wickedly fun game I made as a student.’ Instead I’ll be like, hey look at this crazy game that is super controversial, but it isn’t any fun to play.’ And since it didn’t get picked as a showcase game, all I have is a not fun game. Well, that’s my short rant about that particular criteria for our game designs.
This week we took our 5 game ideas and created a game design doc for each one of them. Since the living room Lava game was my idea, I made the design doc for it. I won’t include all 5 pages here in the post, but here is a sample of how it looks.
This is not the most elegant design doc but I think that it serves its purpose fairly well. We also got to get up and present all 5 games design ideas to the class and have everybody vote. We won’t find out the tally until next week, but hopefully will prove useful.
We only had 2 minutes to basically describe our game to the glass. It was an interesting exercise in how fast we can describe a game so that it is understood. Now we just kind of wait until we get the results back. I will start to work on a schedule for the rest of the semester.
100 Game Ideas:
This week we had to come up with 100 game ideas that we could then use to to narrow down to 5 game ideas. In order to organize our thoughts we put a Google spreadsheet where we could put up all of our ideas. Once they were all up on the Doc I got on and read through all the ideas. Today we met at the first of class and went over all of the ideas.
From there we were able to narrow down to 5 ideas. These ideas were a game about thought manipulation in which you play as a devil and run around changing peoples thoughts to achieve your own goals. Next game is call Living Room Lava, where its about a person who daydreams and incorporates that into his life. We have a nightmare game in which the style of the game changes constantly. Next we have a game called Ragwheel in which we add some new interesting game mechanics to a racing game. And a game about an invisible avatar in which the mechanics continually change based on the environment.
These 5 game ideas will now be expanded upon and presented to the class for feedback and votes to help us narrow it down to 2 games.
Long Term Teams
This began a new semester of the projects class. Today was an interesting day as we had to pick our teams for the next 15 months. This was done in a matter of a couple minutes which was an interesting exercise in who our classmates are and who we know in the class. I stood up after the teachers told us to go form our teams. A couple of people had already sent out emails to other people in the class and forming teams before we were supposed to. An artist that I had worked with on a previous project came up to me and Owen and asked if he could work with us again. We kind of looked at each other and decided we were going to work together.
Next came the mass hysteria of trying to find a balanced team of artists and engineers. We ended up with a good team of 10. It is not as balanced as I might have liked, we have have 4 engineers, 1 artist and 5 producers. We are trying to get another artist but the outlook doesn’t look good.
Now that we have formed a team we have to come up with 100 ideas by next week. The process from there is to narrow it down as a team to 5 ideas which we will make up 5 page design documents for each of those games. Then from there we will present the games to the class and have a vote to help us decide which 2 games we will prototype and present to the industry panel. AND AWAY WE GO.
This was by far the best team and project that I had the absolute pleasure to work on. I had progressed to a point that I was much more comfortable in game development. I know I still have a long way to go and a lot to learn, but I am comfortable enough to know what to work on and when and knowing how to interact with team members. This team was a little unusual in that we had 3 producers. This was good, but also created a problem of splitting up the work of a producer 3 ways. In one way this failed, is that none of knew which was doing the backlog, and one never got created. But our team communicated so well with each other that we always knew what everybody was doing and when.
I enjoyed this prototype and actually really got into the producer end of publishing and the tasks that go along with that. I got a domain name and set up a website for the game. I have been maintaining the website and getting blog posts and art work up on the site and getting email set up so that bug reports and comments can have someplace to go. After that was set up I moved over to the Windows store front stuff of getting the whole process of building the package and everything that it contained so that when the engineers had the game ready we could test it on a tablet and get it out to the world. I went through this process and got it worked out. This was good, because I ended up teaching a lot of different people the process. I am looking forward to continuing to work on this game and just how cool the game can and will be. We are still working on some touch bugs, but hopefully we can get that worked out for the next update.
This has been an amazing week for the game. We have about 25 levels designed and about 21 of them are fully functional. While this is a great step forward in having a game that doesn’t get old after about 15 minute, the main reason that this week has been amazing is that we finally got a touch tablet that we could use for testing. On Wednesday night we were able to get our app side-loaded on the tablet. Our engineers got really excited and set to work getting the touch controls enabled. After about an hour and a half we had the game loaded up on the tablet with touch controls working. We were all excited and almost giddy. The touch controls still have a couple bugs that need to be addressed, but they work and they make the game incredibly fun. For me personally, I enjoyed playing the game with the mouse, but using the touch controls on a tablet made the game so fun.
Also this game was the EAE Open house in which we had people come and tour the lab and see all the games we have been making. We had some industry professionals come through and check out all the games. I had the opportunity to show a producer from EA our game and talk up the team. He was impressed and said that we were on the right track. Another professional from Ninja Bee looked at the game and said “you guys need to publish this.” We are now left trying to tie up a few loose ends, and fix the current bugs. We also need to come up with a plan for how we are going to keep updating the game.
This has been a great week for us. Our engineers made great strides in getting the game code up and a bunch of levels hammered out. Some of the levels were too simple or redundant, but we now have a lot of working levels. Several of us, sketched up some other level designs that the engineers can implement.
These levels are all still based off of mouse controls to create the nodes, but we now have a tablet that we are using to try and implement some touch controls. Our artist has also been hard at work producing assets for the game. You can see his handiwork in the level above, and others in the different levels, and also a great logo that we can use for the website and windows tiles and more.
The producers have been working to make sure that the levels are playable and fun. One of them has done some good work in producing the music and sound effects that are being used in the game. The other has been working on getting our pitch and presentation materials ready. I have been working today to get the game package exported and working on other computers. I have done some package exporting from Visual Studios and Side Loading of the game onto other devices for play testing. It went pretty well, until I got to loading it up onto a tablet device. It had a fatal error, and would close before you could read what the error was. I am now working with the engineers to try and resolve the issue.
We are now 3 weeks into the development of the game and with only 1 week to go before we have to submit it to the Windows App Store. The game is going pretty well and we have working levels and menus. This group has really done well getting everything together and working smoothly.
This week we hit a small road bump in looking at the requirements for the Windows store and finding out that even if we had multi touch in our game, it had to be playable with a keyboard and mouse in order to be approved for the store. This has only effected our development very little right now, but greatly effects our end goal. Th
e whole premise of our game is to use multiple fingers as electrical nodes to guide the electricity. Running it with the mouse it is still pretty fun, but most of the real fun would come with trying to get your fingers all twisted up.
While this has been a problem we have set to working up a solution to the problem that has been set before us. We have thought of giving players the option to play with a mouse, or to activate the multi-touch if they are using a tablet. This option would be the best, but we still need to work out the problems that go along with it