Dev Blog Entry 8

Unity Technical Questions:

• What is the proper way to work with Animations and Animators in Unity without having to enable legacy components?
• How do Unity Ads work?
• How do you publish an game made in Unity to an app store?
• Is it really that inefficient/bad to use OnMouseDown() rather than Raycasting to approximate touches on mobile games?
• How do you develop games for consoles using Unity? How do you get input from game controllers in Unity?

What I Learned:

1. Working with particles
2. Making mobile games
3. Working with UI elements/canvas scaling

The main resources I use to help me with any issues I encounter with Unity are the Unity Manual, the Unity Scripting Reference, and the Unity Answers forum. Unity has great documentation that has helped me figure out how to implement many of the mechanics that I have needed to implement for my games. Piazza was also a great resource for getting help from my classmates and my professor. My teammates were also extremely helpful for the two team projects I worked on. When all else failed, trial and error usually helped me figure out what I needed to do. It was also helpful to write down my ideas and make diagrams sometimes to help me visualize concepts/logic.

Dev Blog Entry 7

I definitely think it is important to encourage innovation in game design. Many great games are created by refining or re-imagining the mechanics from other games. However, when innovating off of an existing game mechanic, it is important not to step on the feet of the people who originally developed that mechanic. This is exactly what happened with the clones of Threes! They came out so soon after the release of the original game that no one had time to appreciate the work that the original developers put in to creating the mechanics for Threes! I think there should definitely be some way for developers who create new game mechanics to sufficiently profit from the time, effort, and capital they invested in their innovation. I do not know if a patent is the right choice for this, but if patents were used in that case I think they should have a shorter length than a traditional patent. Regardless of whether it is called a patent or something else, there should definitely be some legal way for developers to protect their new game mechanics for a couple years. After a new mechanic is created, there should be a period of at least three years in which the game that created that mechanic is the only game on the market with that mechanic. If a developer wants to use that mechanic within that time frame they have to get permission from the people who created the mechanic. That way new games can be made by innovating off of the new mechanic, but in a time frame that will not take attention away from the original developers' game in which the mechanic was created.

Sources:

• http://asherv.com/threes/threemails/
• http://www.uspto.gov/trademarks-getting-started/trademark-basics/trademark-patent-or-copyright

Dev Blog Entry 6

http://bit.ly/26xUxTs

My second Game Design/Development Grandparent is Kim Swift. She was born in 1983 and for a women in her early thirties she has accomplished quite a lot. She is most known for her work with Valve on the Portal, Half-Life, and Left 4 Dead series. The reason she is one of my Game Design/Development Grandparents is because of here work on the Portal series (mainly Portal since she left Valve for Airtight Games halfway through the development of Portal 2). She is an inspiration to me because prior to working on Portal she was a student at DigiPen Institute of Technology. For her senior project, her and group of fellow students worked as a team to create a game called Narbacular Drop. Any true Portal fan knows that Narbacular Drop is the predecessor to Portal. Gabe Newell, the then president of Valve, saw the team demo Narbacular Drop at DigiPen and asked the team then and there if they would want to develop a game for Valve. The entire team was hired by Valve directly out of college and went on to develop the extremely successful game that is Portal. This type of success story speaks very strongly to me and I'm sure it does to other aspiring game developers as well. It just goes to show that any project, even a project for a class in college, can go on to become something big if given the right attention. I would describe her influence on games to someone not familiar with the games field by saying that she worked on many of Valve's successful games and should serve as an inspiration for college students (or anyone else) that is an aspiring game developer.

Sources:

http://www.gamespot.com/articles/by-design-half-life-2-orange-box/1100-6180884/
http://www.gamasutra.com/view/news/26404/Portal_Designer_Kim_Swift_Leaves_Valve_For_Dark_Void_Dev.php
http://old.seattletimes.com/html/businesstechnology/2014794592_brier18.html

Dev Blog Entry 5

http://bit.ly/1NP4T5I

My first Game Design/Development Grandparent is Shigeru Miyamoto. Miyamoto grew up in the Japanese village of Sonobe. Since Sonobe was a rural village, there was no television. Miyamoto also had no toys so he made his own. He grew up surrounded by nature and spent a lot of time hiking and biking. Miyamoto tries to recreate the sense of childhood wonderment he felt when making his own toys and exploring nature in his games. Miyamoto has helped develop many well-known and influential games including Duck Hunt, Ice Climber, The Legend of Zelda series, and the Donkey Kong Series. Perhaps what he is most known for is being the creator of the Mario franchise. Mario Mario made his first appearance as Jupman in the original Donkey Kong arcade game in 1981. Since then he has appeared in many games on pretty much all of Nintendo's systems. The Mario franchise his brought a number of memorable characters into the gaming world including Mario's brother Luigi, Princess Peach, Bowser, and Yoshi. The amount of influence that the Mario franchise and Miyamoto's other games have had on the gaming industry is innumerable. It is for this reason, in addition to the fact that Super Mario 64 is my favorite videogame, that I chose Miyamoto as one of my Game Design/Development Grandparents. I'm not sure if there is anyone who is unfamiliar with the Mario franchise, but I would tell someone who is unfamiliar with Miyamoto's work that he is one of the main reasons that Nintendo is the successful company it is today.

Sources:
http://www.newyorker.com/magazine/2010/12/20/master-of-play
http://www.imdb.com/name/nm0594427/

Dev Blog Entry 4

Grim Fandango is a great game. Although I have never played it directly, I did watch the Super Beard Bros' playthrough of it on YouTube and it was amazing. The art style, the narrative, the characters, and the puzzles all worked really well together to create a compelling and immersive gameplay experience. I found the "Puzzle Document," which breaks down the design and development process for the game, to be very intriguing. I think it is great how organized everything is. It is extremely clear how much effort went into making the puzzles and narrative blend together seamlessly. The document definitely has given me ideas/inspirations that I can use to improve my own design process. I definitely like the idea of using flow charts to track the progression of the story and puzzles. I also was intrigued by the fact they wrote out detailed descriptions of the puzzles and their solutions. Furthermore, I found it interesting that they left the player some options in terms of the order they can play through the puzzles. I like the idea that, even though all the minigames need to be completed, some minigames can be worked on simultaneously. Overall, the designers/developers did a great job making a truly immersive game with a compelling story.

Dev Blog Entry 3

Link to WebGL version of the game: https://googledrive.com/host/0B0fww2eOQcDTXzU3cGVteVdsd0k/index.html
Link to video from start of game (WebGL does not support Movie Textures): https://drive.google.com/file/d/0B0fww2eOQcDTMWNsSThLZTBvNGM/view?usp=sharing

Our design went through many iterations throughout the development process. The biggest changes that happened in our game were made to help convey the story of the game. For example, there was originally supposed to be a minigame after every level but then we decided to only have them at the beginning as story telling devices. CAI (the evil AI) also got a bigger role as opposed to the minimal player interaction that she was originally planned for because we needed her as a story telling device. Another change that was made for the purpose of the story was that the Scientist character was added. There were other small things that we had to take out during development because we had trouble implementing them. The light on the chest of AHAB (the player) was supposed to flash every time it fired a lase but we could not figure out how to make that happen. We also could not include one semi-important narration file because it was supposed to play when AHAB broke the first wall with the laser and we could not figure out how to implement that.

There are still some aspects of the game we want to improve on/change based on the results of play testing. Some of the narrations were too long, specifically the one where CAI kills AHAB. There is also a glitch where the laser can hit the player if they are walking forward while shooting it. The game should also loop back to the menu or show some ending screen after the good or bad ending plays. It would also be cool to be able to incorporate some of the features that we could not figure out during development such as the blinking light and wall break dialogue mentioned above. Overall, our game was pretty well-received.

Dev Blog Entry 2

Link to WebGL version of my first game project: https://googledrive.com/host/0B0fww2eOQcDTS3pZQ2dSUUVSTEk/index.html

My design went through multiple changes as I was building it to account for program-ability and difficulty. For example, I originally wanted the shapes to follow behind the player when they picked them up but then that would cause the shapes to go through walls which was not aesthetically pleasing and did not fit with my games mechanics. For this reason, the shapes now move to the same position as the player when picked up which actually works out well because it looks like the player is carrying the shapes. Another thing that changed a lot was the timing of the doors and the location of the shapes. I had to time the doors so that they would serve as an obstacle without being too difficult to get through when opened. In the end, I think there still might be slightly too much difficulty associated with the doors based on the results of my play testing. I also had to play around with the location of the shapes because I wanted the puzzle to be solvable without being too easy. Another thing that changed was the addition of the portals. There were no portals in my original game design, but then as I started layout out the level I realized that the player could inadvertently get locked in a room so I added the portals to compensate for this.

I still want to work on making my game easier and more aesthetically pleasing. I could probably make it easier by adjusting the layout of the level and the timing of the doors. I also would like to add more levels in the future. One main complaint I got is that my background is not aesthetically pleasing. Some people didn't like the bricks, some people didn't like the color, and some people didn't like either. To fix this, I will experiment with more background choices. I also want to improve the timing/score mechanism and give more of an incentive for getting a better time and maybe add collectibles of some kind that could be used for scoring.

Dev Blog Entry 1

Of the games we’ve played so far in class I think 140 exhibits the most elegance in its design. I think all of the elements (sound, color, shape, mechanics, etc.) of the game, as well as the developers attention to detail, come together really nicely to form a well-designed and interesting gameplay experience. One example of this is how cleanly the player "character" changes shapes for different actions:

The smoothness of the animation as the character changes from shape to shape as well as the little trail that follows the character as it moves really add to the game's overall aesthetic. Having different shapes correspond to different types of movement (or lack thereof) is also an interesting gameplay mechanic. I also really like that the music provides a rhythm that you can follow to progress through the levels rather than just simply being background music, as can be seen in this excerpt from the game's trailer:

You'll notice that the each time the player lands on a platform there's a corresponding beat in the music and the music also corresponds to the movement of certain obstacles. The game also uses color very well. For example the game's main obstacle is static. Even without any formal instruction, the player can tell that the static is bad because it is aesthetically different from the rest of the game's vibrant colors and is often placed at the bottom of pits which from previous game experience players know to avoid. Thus, overall 140 is an elegantly designed game.