Capstone Game Post Mortem: Amazons

Capstone Game Post Mortem: Amazons

Capstone Game Post Mortem: Amazons

Game Summary 

Amazons is a mobile adaptation of “Game of the Amazons” invented in 1988 by Walter Zamkauskas (Wikipedia, 2014). The game is played on a 10x10 chessboard and similar to chess player game pieces are represented by white and black game pieces. Typically the Amazon game pieces are represented by chess queen pieces however any token or object can be utilized to represent the game pieces. In addition to the game pieces, tokens are needed to play the game; tokens are utilized to designate blocked board tiles. A single turn consists of two phases, a move phase and a fire phase. During the move phase an Amazon can move across the game board with the same rules that govern the chess queen. During the fire phase, the player selects a tile to fire an arrow into (thus blocking it) governed by the same movement rules. The objective is to acquire as much territory as possible by blocking off board tiles. The player with the most territory wins the game. A board tile is considered to belong to a player if only his/her Amazon(s) can reach the tile.

Author 

Gerald L Quick Jr.

Title

Amazons

Genre

Abstract strategy board game

Platform(s)

Android/iOS

Revenue model

Amazons will follow a mobile advertising revenue model. When thinking of how to implement this model I wanted to ensure that he user experience was not interrupted in anyway, this included having banners present during game play. I personally find banners to be distracting and take away from the game play experience as a whole. The mobile advertising service I selected was unityAds. The reason this was chosen was due to the simplicity of integration as well as features provided such as interstitial video ads (Unity Technologies, "Grow Your Revenues", 2014). If a mobile advertisement is available it will be displayed at the end of the game. From a monetary stand point this is not very aggressive and does not provide the highest potential to generate large amounts of revenue, however that was never the goal going into this project.

Development tools/Language

The primary development tool utilized for the development of Amazons was Unity (Unity Technologies, “Unity- Game Engine”, 2014). The Unity integrated development environment (IDE) simplified development with all tools available in a single development environment.

The primary programming language was C#, with the exception of some third party API’s and SDK’s. The coding was completed in MonoDevelop provided with Unity.

Other supporting tools were utilized in the creation of Amazons. These tools include Adobe Photoshop CC for textures and images (Adobe, "Adobe Photoshop CC", 2014). 3d Studio Max was utilized for creating game assets such as the game board (Autodesk, 2014). Quixel Suite for Photoshop was utilized to assist with the visualization and texturing of game objects created in 3d Studio Max (Quixel , "Quixel Suite", 2014).

Game audience

The targeted game audience for Amazons is the moderate to hardcore gamer that enjoys tactics, strategy, and position board games.

Team

The development team for this project consists of a single developer, Gerald Quick, founder of Quickstudios LLC.

 

Copyright/Reference

Amazons ©2014 Gerald L Quick Jr.

 

Backstory:

According to Wikipedia, the original game was first published in Spanish in 1992, appearing in an Argentine puzzle magazine (2014). Michael Keller wrote the first approved English translation of the game rules in 1994 which appeared in World Game Review (Wikipedia, 2014). Michael Keller also wrote the first computerized version of the game in 1994 as well. The first rendition was written in VAX Fortran, he later wrote a Visual Basic version of the game in 1995 (Wikipedia, 2014).

Sound Bite

“Dominate your enemy! Take and defend territory to emerge victorious!”   

Executive Summary

Amazons is “…a member of the territorial game family, a distant relative of Go and chess.” (Wikipedia, 2014). The mobile version attempts to recreate the board game version of the game “The Game of the Amazons” which is a trademark of Ediciones de Mente (Wikipedia, 2014). According to Wikipedia usually an Amazons tournament is held at the annual Computer Olympiad (2014).

Inspiration

The inspiration for the game came about out of desperation in deciding what to do for the capstone project; the idea was suggested by Todd Smith, PhD. Once I started development on the project and conducting research on the game, I was inspired by the potential of having a mobile version of this game. 

Ideal

The ideal version of this game would be a completely socially integrated game. Allowing turn based and real-time multiplayer complete with player matching and tournaments. Game based tutorials showing how to play the game as well as suggested strategies depending on the situation. I imagine the suggested strategy mode to be similar to practicing picking up spares in bowling, where you would select a situation and play out the game from that point. Game history, keeping track of all movements made during matches in order to replay for later review. Lastly it would be ideal to have a truly difficult challenging artificial intelligence for single player that pushes the limits of current mobile technology.

  

The Critique: What went right…

Design & Aesthetics

Menu user interface (UI). The menu UI was a lucky but huge success. The reason it was lucky was because the art assets were bought from the Unity asset store and just so happen to match the vision planned out for the UI exactly. I knew from the start that I wanted a clean and consistent UI for the menu and game play. I researched a lot of UI’s trying to decide on a good color scheme. I ended up turning to World of Warcraft, I have always loved the color scheme of the UI and the art in general; See Figure 2. for an example of the World of Warcraft UI. I then searched the Unity asset store and found the Tribal UI asset and knew that was the one. I expected to find something close that I would have to modify but this was not the case, no modification needed. This was a great success in deed, mostly because I did not have an artist. Figure 1. Shows examples of the Amazons UI.

UI controls. The design of the UI controls for the menus and game were a success. The UI camera controls worked as planned and are simple and intuitive. All the menu controls are consistent throughout the game.

3d models. The 3d models purchased to represent the Amazons were exactly what I had envisioned for the game. This is largely in part by the different color texture variations provided with the models which happen to have a white and a black variation.

The 3d model for the game board was created and not purchased. Even with my limited artistic ability, I knew enough about modeling and texturing to create the simplistic game board I had envisioned. The main reason this asset was not purchased was because it became difficult to find a chess or checker board model that was European style (10x10). Figure 3. Shows the game board rendered in game.

Project Management

Overall the project was managed very well utilizing Underdog for project management and source code management. The simplicity of the platform allows me to communicate effortlessly with my project managers (the faculty) and keep all stake holders (the faculty) abreast of any issues and current progress of the project.

Project resources. All the resources I identified for the project were clearly defined and appropriate. I was able to acquire the art assets with no issues and helped support the look and feel of the game that I was targeting.

Development

With the exception of third party API’s and SDK’s the only mentionable success was the actual speed at which development was conducted. This is largely in part to the selection of Unity as the game engine. As a single developer I consider this a big success when looking at the actual amount of time that was spent on the project and how much was actually completed.

Third party API’s and SDK’s. The integration with Google Play Game Services (GPGS) and Game Center were a success. These services are utilized for the leaderboards in Amazons. Depending if the device is Android or iOS, GPGS or Game Center is utilized to keep game scores respectively.

Testing

A/B Testing was very successful and easy to integrate into the project using Leanplum web service (Leanplum, Inc, 2014). This is an awesome web based service where you can actually change variable values for your tests in real-time and they are updated on the devices without having to recompile the game.

 

The Critique: What went wrong…

Design & Aesthetics

Design documents. The original design document was not updated frequently throughout the project to reflect design and develop changes. There also was not enough detail provided in the design document to understand what needed to be completed. Even though I was the only developer and I knew what needed to be completed, if I gave the design document to another developer they would not know how to proceed. It would have been very beneficial to have a detailed and updated design document. A few months or years from now it would be good to look at the document and understand why I made certain choices or implemented things in certain ways.

Platform choice. Upon deciding to support both Android and iOS devices was not really a bad choice however I should have further refined the platform to tablets. Due to the small screen size of phones, any device smaller than 7 inches and the game suffers. As of this writing there were no controls in place to facilitate the zooming and panning of the camera on smaller devices. This makes game play very difficult for selecting Amazons and move locations.

Project Management

Milestones and activities. Not all project activities took place on schedule. There were several delays in implementing certain functionality due to bugs in previous activities. Other issues included under estimating the time it would take to implement a feature. I found that a majority of the bugs that were introduced into the project were due to poor code structure and coding practices in general. When the project started it was built off of the prototype which turned into the final project. This is probably ok for some projects especially if the prototype is well design and solid. For me however, it would have been better to start a new project and use the prototype as a reference when needed.

Sustainability and scalability. The project is somewhat sustainable but not very scalable. Looking back this is due to poor development choices. I found a better way to implement the game logic that would be much easier to maintain and provide unlimited scalability. I plan to rewrite this game logic, this will not only improve the performance of the AI but allow me to implement other features easier, like multiplayer for example.

Time management and scheduling. When planning development time for a game project I would make sure that you have counted the little things as well. Sure you can sit there and give an estimate based on the game play but forgetting the little details like menus and settings. I have found these to be very time consuming import aspects of the game. I spent almost double the amount of time I estimated working on my simple menu and settings. Always overestimate time for unforeseen issues. I did plan for this however I should have doubled the amount of time for this. I have found that even though I had experience implementing some of the game features with no issues in the past, which ended up not being the case for this project. So bottom line, always add a bit of extra time for the unknown no matter how many times you have implemented something.

Development

Third party API’s and SDK’s. The third party SDK’s and API’s were easy enough to acquire however implementation was another issue. I did not see any compatibility issues during my research when choosing the SDK’s and API’s I chose. I was able to work some of the issues as other have came across the same issues and provided solutions. Some had to be abandoned because they did not perform as imagined. One example is Marmoset Skyshop. This was going to be used to provide high quality High Dynamic Range (HDR) rendered game scenes but the performance (or lack thereof) was not very good on the mobile platform.

Testing

General. I wish I would have known more about unit testing and A/B testing prior to writing a single line of code in my project. There are a lot of mixed feelings about test driven programming but I would recommend some form of it. If I would have went into design and development with this mindset I think it would have saved me time and provided a better quality code in the end.

Game testing. Do not under estimate the value of early user testing during development. I showed people the project early and throughout development but they did not get a chance to play the game until late in beta. I plan to allow user testing throughout the project and not wait till beta. For example, when I finish a menu screen I will have it tested to ensure that it makes sense and is easy to follow. One thing I like to do is just give the game to my daughter (she’s 11) and ask her to start the game or change the settings. If she can figure it out without any issues I at least know that my design is intuitive enough for an experienced gamer. The reason I bring this up is because in my project I did not have a tutorial to teach the game. This left the beta testers confused on what they were supposed to do.

 

Summary:

Overall the project went well however it does differ from the original design considerably due to missing features. Some of the features that did not make it in to the final project include multiplayer, social integration (Facebook, Google+ and Twitter), and Augmented Reality (AR).

 

References

Autodesk. (2014, January 1). 3D modeling, animation, and rendering software. Retrieved November 4, 2014, from http://www.autodesk.com/products/3ds-max/overview

Adobe Photoshop CC. (2014). Retrieved November 4, 2014, from http://www.adobe.com/products/photoshop.html

Blizzard Entertainment. (2013, October 12). World of Warcraft®. Retrieved November 9, 2014, from http://eu.battle.net/wow/en/blog/11941666/Introducing_the_New_Shop-10_12_2013

Leanplum, Inc. (2014, January 1). The only fully-integrated optimization solution for mobile apps. Retrieved November 9, 2014, from https://www.leanplum.com

Quixel. (2014, November 1). QuixelSuite. Retrieved November 4, 2014, from http://quixel.se/

Unity Technologies. (2014, January 1). Grow Your Revenues. Retrieved November 4, 2014, from https://unityads.unity3d.com/monetize

Unity Technologies. (2014, January 1). Unity- Game Engine. Retrieved November 4, 2014, from http://unity3d.com/

Wikipedia. (2014, January 11). Game of the Amazons. Retrieved November 4, 2014, from http://en.wikipedia.org/wiki/Game_of_the_Amazons

Figure Captions

Figure 1. Amazons UI examples.

Figure 2. World of Warcraft example UI (Blizzard Entertainment, 2013).

Figure 3. Amazons game board rendered in game.

Capstone Game Post Mortem: Jettisoned

Game Summary:

Author

Brandon Jones

Title

Jettisoned

Genre

Sci-fi Dungeon Explorer/Builder

Platform(s)

Android devices

Revenue model

The game is using the Freemium model. My monetization model was supposed to be to sell in-game currency which unlocked skin packs for dungeons as well as for traps/obstacles. However that didn’t quite make it into the game due to limited assets. In order to quickly add in monetization I can integrate Google’s AdMob service.

Development tools/Language

I am using the Unity2D engine in C# for this project. I have used Unity Tools for Unit and Integration Testing. If I use AdMob I will also be using Google’s Google Services API acquired through the Android SDK Manager. 

Game audience

My target demographic is a 20-30 year old male who would be considered to be a Killer according to the Bartle Player Type model. Since the game primarily focuses on competition this target demographic makes sense although there will be game elements that might also appeal to an Explorer by the Bartle Player Type model.

Team

I worked with 3 other people on this project: Anna Di Masi, Seth Jones, and Nick DeMarc.

Anna was the Lead Artist for this project. Her work includes: All obstacles and traps in the game, the safe and teleporter objects, and the player assets including animations.

Seth Jones composed the music for the game including the music for the menu, fortification phase, and infiltration phase.

Nick DeMarc did all of the audio effects in the game including: Player Walking, Menu Sounds, Player Actions, Mini-game sounds, selection sounds, and activation/deactivation sounds.

Copyright/Reference

© 2014 by Brandon Jones. All rights reserved

Backstory:

Sound Bite

Two sworn enemies are stranded on an uninhabited planet and are forced to outwit, deceive, and steal from one another in order to escape.

Executive Summary

Jettisoned is a Sci-Fi themed strategy game where players are forced to outwit, deceive, and steal from each other in order to escape the planet on which they have been stranded. In Jettisoned players fortify their crashed space craft with various traps and obstacles before setting out to steal the opposing player's Fuel Cell. Players must use whatever tactics they can to make it off the planet.

Inspiration

With Jettisoned I wanted to prove that it was possible to have an intense competitive multiplayer experience on the mobile platform. I wanted players to strategically place their traps and obstacles around their dungeon in creative ways that challenged their opponents. During the Infiltration Phase of the game I wanted players to feel a sense of urgency. I wanted these players to each be racing through the play area not knowing what would or wouldn't be around the next corner. It is this feeling that I love in competitive games and I wanted to capture that in a clean and simplified way on the mobile platform.

Ideal

If everything had worked out perfectly I would have at least 4 mini-game types with 5 different obstacles and 5 different types of traps for the player to play with. Also the player would have all of its animation ironed out and I would have my brief opening intro still shot “cinematic”. I would also have a tutorial mode and a bit more polish on the game overall.

The Critique: What went right…

Design & Aesthetics

The mechanics in the game were designed to be meaningful and simplistic. That way a player was able to quickly understand the game and focus on competing against his/her opponent rather than the game itself. This worked out well with some tweaks to the UI to reinforce the game controls.

Project Management

The project was very well scoped in my opinion from the beginning. This worked in my favor since I wasn't in over my head from the start and was able to work at a comfortable pace. This allowed me to work overtime to catch up if I was behind without missing any additional deadlines.

Development

Using the Unity2D engine worked very well for my project. It allowed me to quickly add game-play features to my project including: game objects, player actions, map creation, and networking. Using C# as my primary language was also good since I have a strong background in C style programming languages. I structured my code so that it was easily expandable which allowed me to quickly iterate on systems that weren't working optimally as far as the player experience was concerned.

Testing

Unity’s testing tools were extremely useful. I consistently play tested myself to be sure that the game was bug-free and flowing properly. I also did some third party play testing to make sure that the game was readable and intuitive. Through this process I was able to pinpoint issues in the game and address them quickly.

The Critique: What went wrong…

Design & Aesthetics

The UI in the game has undergone the most drastic changes within the game and is still not perfect. The UI within the Fortification Phase in particular has caused some of the most issues. There were several actions that needed to be given to the player within this phase which was challenging. There are still a few visual and audio assets missing from the game that didn't quite make it in including final animations, cinematic still images, and game music.

Project Management

While the project was well scoped for a three month project, I was not remarkably successful at managing my time while also working a full-time job. As a result at fell behind on a few tasks that I should not have and as a result I did not fully make some of the features I had hoped to get into the game. I also did not do an amazing job at managing those within my team and as a result I am also missing some final assets.

Development

I was not very effective with keeping up with my documentation and as a result I did not update my Technical Documentation or development schedule. This caused my issues later on which led to my inefficient time management.

Testing

Unfortunately I only started using Unity Tools towards the end of my project. If I were using Unit Testing and Integration Tests from the start of my project I could have discovered issues earlier on and saved some development time. In the future I am going to be sure to use these tools from the start of my projects.

Business Model/Plan

I did not properly manage my time for game-play features behind my monetization plan and as a result was unable to integrate the in-game currency. I also was unable to get the assets necessary to sell different asset packs for dungeons/game objects.

Summary:

The final version of the project was a little less expanded than my ideal. Although I am glad that I sacrificed an expanded version of the game rather than the quality of the core game concept. I would personally rather have a smaller complete product rather than a large project with holes in it. As a result I completed my A-List features and had to partially cut down some of my B-List Features. I intend to take this project and expand on it in the near future. Since I have a solid foundation for the game I feel like I can definitely make it happen without any reworks. With the core of the game complete, all that’s left is to expand on the current game objects, add more mini-game types, and clean up the game interface. Other than that a game can always use polish. Perhaps I’ll add in some visual effects. I was excited about this project because I wanted to see what I could create on my own and I am not disappointed with the results. However I have learned that when I am working alone I might need to create more formal deadlines and schedules for myself. That way I can hold myself accountable and keep myself on track. If I could go back I think that I would have created a day-to-day schedule for myself so I understood just how much time I had left. I would also have created a prototype of my UI a bit more so that I wouldn't have to rework it later on. As a high-point, I really enjoyed working on the player mechanics and the tile-based room structure. I was a lot of fun and I learned a lot about how to build and expand complicated data structures. As a low point it was finding out just how much more time I had to work on the project towards the end. I felt kind of demoralized and as a result my work faltered a bit. I don’t think I’ll release the game just yet, but I plan on expanding the game and eventually making something out of it.

References

Jones, B. (2014). Jettisoned [Android Game].

Lead Artist: Anna Di Masi

Lead Music Engineer: Seth Jones

Lead Audio Effects Engineer: Nick DeMarc

Kyatric, (Feb 18, 2013). Bartle’s Taxonomy of Player Types.

Retrieved from http://gamedevelopment.tutsplus.com/articles/bartles-taxonomy-of-player-types-and-why-it-doesnt-apply-to-everything--gamedev-4173

Capstone Game Post Mortem Template

Capstone Game Post Mortem: (The Name of Your Game)

Game Summary: (Sub Heading - Centered)

Author (Minor Heading)

Your name (Normal)

Title

What is the title of the game?

Genre

Identify the most appropriate categorization for your game.

Platform(s)

What is the mobile platform for this game?

Revenue model

Will you be releasing your game for free or for a small charge? If for free, briefly summarize your plan to monetize the game; if for charge, list your intended price.

Development tools/Language

What development tools or programming language do you intend to use to develop the game? Do you plan on working with 3rd party APIs or other tools?

Game audience

Who is your intended audience or demographic for this game? Provide a short player description that includes age range, gender, player-type (from Bartle or Vandenberghe), and any other relevant characteristics that you have considered.

Team

If you worked with a team or contracted others to help you design and develop your capstone project, provide names and work assignments for each member.

Copyright/Reference

Provide the reference for your game and a brief statement of copyright.

 

Backstory:

Sound Bite

Synthesize your game proposal as a sound bite in 20 words or less. This should sound good and be something you might hear as a voice-over for a commercial or trailer. Check out http://socialtriggers.com/sound-bites-traffic/ as a starting point. Test this out with a couple people from your demographic group to make sure it works.
Examples:
·It's a bird. It's a plane. It's Superman..
·From the TV series Friends describing Joey’s role on a TV drama called Mac & Cheese: "One's a hard-bitten detective, one's a robot. They Fight Crime!"
·Plant Liberation II: In a world of potted houseplants, one woman will embark on a journey and fight for the liberation of them all, and this time it’s personal!

Executive Summary

This is your elevator pitch. Expand on your game a little more, explaining what it is in a short paragraph of a couple sentences. This should alert players to the game genre, and major gameplay elements. Make sure to indirectly address: What is novel or different about your game? Why should players play it? Express this in 3-4 sentences maximum.

Inspiration

What was the inspiration for your game? What were your motivators or drivers to develop this game? What was the context for the game?

Ideal

If everything had gone perfectly according to plan, what would your game have looked like? Provide a brief description of the ideal you hoped to achieve initially with your capstone project.

 

The Critique: What went right…

Where possible be sure to include artifacts from the game or it’s development to exemplify and substantiate the written text.

Design & Aesthetics

Evaluate the merits of the design document(s), mechanics, balancing, graphics, audio, narrative, UI screens, UI controls, etc.

Project Management

Evaluate the merits of the project scope, planning, preproduction, Agile/Scrum, choice of tools, timing, sprints, etc.

Development

Evaluate the merits of the code structure/architecture, documentation, challenges, choice of AI/algorithms, databases, network functionality, engine/code choice, etc.

Testing

Evaluate the merits of the testing you conducted: debugging, Q&A, usability, play-testing, unit tests, etc.

Business Model/Plan

Evaluate the merits of the revenue model you chose (For Pay/Fremium), Lite/Full Version, and other business aspects: In App Store, In Game Economy, etc. You can also evaluate your intended marketing plan or strategy if you have one.

Other

Evaluate the merits of any additional elements that may have played a role in the outcome of your capstone project that were beneficial to you or a point of success not indicated above.

 

The Critique: What went wrong…

Where possible be sure to include artifacts from the game or it’s development to exemplify and substantiate the written text.

Design & Aesthetics

Evaluate challenges or problems attributable to the design document(s), mechanics, balancing, graphics, audio, narrative, UI screens, UI controls, etc.

Project Management

Evaluate challenges or problems attributable to the project scope, planning, preproduction, Agile/Scrum, choice of tools, timing, sprints, etc.

Development

Evaluate challenges or problems attributable to the code structure/architecture, documentation, challenges, choice of AI/algorithms, databases, network functionality, engine/code choice, etc.

Testing

Evaluate challenges or problems attributable to the testing you conducted: debugging, Q&A, usability, play-testing, unit tests, etc.

Business Model/Plan

Evaluate challenges or problems attributable to the revenue model you chose (For Pay/Fremium), Lite/Full Version, and other business aspects: In App Store, In Game Economy, etc. You can also evaluate your intended marketing plan or strategy if you have one.

Other

Evaluate challenges or problems attributable to any additional elements that may have played a role in the outcome of your capstone project that were detrimental to you or a point of failure not indicated above.

 

Summary:

Wrap up your evaluation. Some questions to consider for this section are:
How did the final version of your project differ from your initial ideal? Was it better or worse? What design and development trade-offs did you need to make? Where do you intend to take the project from here? What is still left to do, and how long will it take you accomplish your goal? What did you learn along the way? What take-aways do you have from the experience? What would you do differently if you had the opportunity to redo the project or to start over? What was the high point of the project? What was the low point of the project? Do you plan on releasing your game? What are your plans for the future?

 

References

Please list any references you referred to in this post mortem. This can include textbooks, academic articles, player-type descriptions, asset locations, or any other outside source material. Be sure to include the reference to your game in the list. Be sure to include your game as a reference with proper APA citation.

Capstone Post Mortem Instructions

Readings

Atwood, J. (2007) Game Development Postmortems at

http://blog.codinghorror.com/game-development-postmortems/

This article is a bit dated but has some good suggestions. Not all of the links are current though.

High-Level Project Goal

This month you will put together a final evaluation of your game and present your final project to the faculty for review and critique.

Your post mortem has 3 parts: A written project evaluation document addressing the merits of your project including success and failure points; a visual presentation based off the written document using presentation software (PPT, Keynote, Prezi, etc); and the oral delivery of the presentation to the faculty with question and answer.

Assignment

Part 1: Written Documentation:

You will produce a final self-evaluation critique of your capstone project called a post mortem. The document should be written in APA format and address all of the elements listed below (an editable template is provided to help you complete this).

A brief description of each section is included in the template. If you are having difficulty completing any of the sections, or if you believe a section does not apply to your game, please reach out to your instructor for assistance. You should plan to spend at least 3-4 hours each week over 3 weeks working on the written proposal for a total of between 9-12 total hours, assuming that you have a finished capstone project and have considered many of the topics below already in the discussion posts that accompany this class. Keep in mind that if parts of your project are incomplete, your completion time may be significantly greater.

Capstone Post Mortem body content:

Game Summary:

Title

Genre

Platform(s)

Revenue model

Development tools/Language

Game audience

Team

Copyright/Reference

Backstory:

Sound Bite

Executive Summary

Inspiration

Ideal

The Critique: What went right

Design & Aesthetics

Project Management

Development

Testing

Business Model/Plan

Other

The Critique: What went wrong

Design & Aesthetics

Project Management

Development

Testing

Business Model/Plan

Other

Summary:

References:

Sample Post Mortem Documents and Additional Resources:

PacMan Post Mortem Presented by: Toru Iwatani – Tokyo Polytechnic

http://www.gdcvault.com/play/1014631/Classic-Game-Postmortem-PAC

Mobile Game Postmortem Ngame’s Chop Suey Kung Fu Presented by: Matt Kelland

http://www.gamasutra.com/view/feature/131881/mobile_game_postmortem_ngames_.php

Postmortem Trearch’s 2002: Spider-Man Presented by Jamie Fristrom

http://www.gamasutra.com/view/feature/19485/postmortem_treyarchs_2002_hit_.php?page=1

Postmortem Q-Games’ Pixeljunk 4am Presented by Rowan Parker

http://www.gamasutra.com/view/feature/189359/postmortem_qgames_pixeljunk_4am.php

Various other selections of Postmortems from Gamesutra: http://www.gamasutra.com/features/postmortem/

GDC Vault Classic Game Postmortem: Pitfall Presented by David Crane

http://www.gdcvault.com/play/1014632/Classic-Game-Postmortem-PITFALL

GDC Vault Classic Game Postmortem: Doom Presented by John Romero and Tom Hall

http://www.gdcvault.com/play/1014627/Classic-Game-Postmortem

GDC Vault Classic Game Postmortem: Myst Presented by Robyn Miller

http://www.gdcvault.com/play/1018048/Classic-Game-Postmortem

Note

Students retain ownership rights to student-projects completed as part of an educational program at Full Sail University. However as part of enrollment Full Sail University does have the right to use student projects for marketing purposes to demonstrate student accomplishments. If you have concerns that your project may be chosen to highlight activities within the MGMS program or game studies for promotional purposes, please discuss these with your instructor or the program manager.