I summarize the postmortems for three games. The feedback in these postmortems was gathered straight from the teams.
o Level designers did an excellent job laying out levels early and testing often
o Level designers worked early on the documentation and polished it to a high level
o The designers were able to work independently of other developers but quickly made changes based on team member’s feedback
o The mechanics of the game were very simple and elegant. They all helped emphasize one mechanic: movement
o The programmer fixes bugs quickly before they caused problems
o The programmer designed the code for change because he was working in a new code language
o The artist became very comfortable producing art very quickly
o The artist churned out a high number of placeholders for virtually every asset in the game very early. This allowed level designers to play around in the editor and learn how to make enjoyable levels
o The team had a very strong team culture and dynamic. This helped the team become comfortable with each other very quickly and the added morale helped to produce a higher quality work environment and ultimately better game
o The team communicated at a high level. Any time a team member needed something, they would ask right away. The team kept good communication through email and on facebook when not in core hours.
o Playtesters were about 50/50 on liking the barrel roll. A lot of testers did not want to use it because they could not judge the distance they would travel until they had mastered the mechanic
o Players often purposefully missed speed boosts because they would miss pickups if they speed boosted
o Because of lag inherent to GuildEd, asteroids would load at different start times in their orbits sometimes throughout new playthroughs. This complicated the design
o The untimely theft of the artist’s laptop severely hindered the artist from creating assets efficiently. It stayed this way until he got a new laptop roughly 3 weeks later
o The shield UI overlapped the player model. This was a necessary sacrifice in order for the team to better display the HUD
o The team wasted some time on the fuzzy front end not knowing what was required of each milestone
o The team learned that the players were only looking at the ship and not the HUD in the upper corner. Therefore, the team moved the game’s HUD entirely to the controllable character, the player’s ship. The team learned that it is hard to figure out what level of feedback you need to give the player.
o The team learned the importance of settling with “good enough” on a particular task before moving on to the next task at hand
o The team learned that being part of a team is not always getting your way
o The team learned the importance of scope. Fortunately, they scoped the game very well and never felt overburdened by a milestone. They realized they scoped well when watching all of the other teams run around with their heads on fire before the Alpha milestone. The lesson was still learned.
o It is hard to know how a game will play out before you make it. The levels in the GDD were merely best guesses at level designs.
o Built levels early. Team was able to spend enough time play-testing
o Added experience of learning tools such as Premiere and Audacity
o Having time early in project, a level designer recorded voice overs for the game and took the time to find sound effects and music
o The team added an additional artist halfway through development. The artist quickly fell into place in the team culture and started to produce quality and stylistically similar art
o Communicated great as a team. The entire team maintained high spirits and good humor throughout the project. There was a very strong team culture.
o The team was happy to work overtime voluntarily. This helped to boost team morale
o The team participated in team-building gaming sessions which helped to build camaraderie
o Did not place objects in the same layers
o Did not communicate well. Level designers deleted objects or folders, which corrupted GuildEd. This caused the team to revert or fix the build each time a corruption occurred
o Both levels contained different themes requiring different art and allowing for very little art reuse
o GuildEd caused major rework several times throughout the project due to level designer not knowing the tool well enough
o The artists did not estimate accurately in the beginning of the project causing their actual hours to extend longer than their estimated hours. This ultimately caused features to get cut
o Adding a second artist halfway through development took workload off the first artist. However, it also required the first artist to teach the second artist the game’s style and tone
o Naming conventions were not strictly followed throughout development
o The art team ran into trouble while trying to update the Asset Database on the SVN. This caused rework to be done by the entire team.
o Wishful thinking caused the programmer to always hope he had time to implement features fast enough to leave room for a significant amount of testing
o Early in the project, the programmer worked long hours to implement a dynamic UI element before realizing that it simply was not possible in the editor
o Often committed something without fully testing it
o The team got off-track very often due to a team member watching a funny video or other random things. The break out room was not a very productive environment
o It seemed there was a communication break-down between artists and the rest of the team at times
o The only reason that the team survived feature creep was because they received an additional artist in the fourth week of development.
o Some team members did not manage their time well with other classes at the Guildhall. This forced them to work during core hours on projects for other classes
o Naming conventions are extremely important
o Learned how dependent level designers are on other departments
o Non-artists learned how much artists work to produce the level of content that went into Raging Sushi
o The team benefitted from the transparency of Daily Scrums
o The team learned the all-important lesson of scope and they learned it well. Even small tasks like AI took longer than expected and significantly reduced time for working on the next cool feature. One team member said it best: “Cutting features is a necessary evil.”
o The dodge roll, a feature allowing the protagonist to roll out of harm’s way, was the feature most talked about by play-testers. There was a point when the dodge roll was almost cut. The team learned how powerful one feature can be.
o At times, however, the team cut features in a smart way. Early in the project, the team cut the jump feature because they did not feel that it added enough gameplay to justify the amount of complications it would cause for the programmer
o Feedback is the name of the game. Players always misinterpret what is being communicated in some way. The team learned to constantly reevaluate how good the game’s feedback was
o It is important to listen to feedback from playtesters but the playtesters are not 100% right all the time. The team learned to listen carefully to what they could implement and test easily and what the real problems were
o Level designers did a great job at keeping the vision of the game
o The department communicated greatly when it came to making or polishing levels and adding a tutorial
o The artist created very high quality art and a lot of art
o The artist communicated effectively in asking for feedback
o The team maintained great project visibility through the practice of Daily Scrums o The team maintained a really fun atmosphere and work environment
o Wish could have spent more time implementing features
o The department did not do well estimating hours with great precision
o Working in two levels at once generated a lot of bugs
o The team overscoped heavily in the art department. The artist did what he could to keep up. This also had to do with the nature of the game. Each art asset essentially needed four of the same art piece: a spiritual realm, a physical realm, a spiritual desaturated realm, and a physical desaturated realm.
o The artist had a few medical issues pull him away from school which was a setback
o The team estimated hours very poorly as a whole
o The game was not as intuitive as the team had originally hoped
o The team initially designed too many features for the game
o The team took too long in updating documents
o It is better to overestimate time than underestimate time
o Although the team’s ideas clashed at times, they pulled through and huddled around the same game vision
o Kleenex tests gave the team a clearer understanding into the way players played their game. They quickly found out what was confusing and what was great
o The team spent a lot of time doing things like documentation and learned that development isn’t all working inside code or an editor
o The artist learned to bring assets to an acceptable quality and polish the last 10% as a wishlist item
o The artist learned to develop assets in parallel where possible to keep the same level of consistency in art
o The team learned to reschedule the project immediately after learning that the project was overscoped
Read more about:
BlogsYou May Also Like
