Positive Content
- Added background music to Popcorn Popper, Ram the Planet, and Item Dodge micro games
- Altered the games to reflect better controls & playtest responses
- Was not able to fully test out the newer versions of the games
- Will need to fix for next week
- Was not able fully complete the Item Dodge Variant
- Needs better art from artists for the controls
Work and Hours
Alterations (~3 hrs)
- Added music to Ram the Planet, Popcorn Popper, + Item Dodge
- Edited games to be easier to play + understand
Variant Creation (~1 hrs)
- Finished creating the variant of Item Dodge
- Added music to Ram the Planet, Popcorn Popper, + Item Dodge
- Edited games to be easier to play + understand
Variant Creation (~1 hrs)
- Finished creating the variant of Item Dodge
Total Hours: 4 hrs
GDC Vault Post-Mortem Reaction
Presentation: Far Cry 4: Gameplay Team Workflow, Iteration and Philosophy - By: Marc-André Saulnier
The first thing that struck me with this post-mortem was that a single department for the game had a diverse set of skills collaborating in close proximity to each other. In contrast to us, from the perspective of someone in a similar position to Saulnier, we separately developed parts of the game that was then put together in the end. This includes the fact that the group itself was split into two core teams of art and programming. The difference being the Far Cry 4 developers had people with various skill sets working in the same team, unlike us that divided ourselves because of our skill sets.
The second key item I noticed was how Saulnier kept talking about how the players were important to the game making process. He talked about how the team developed ideas that would give the player a variety of choice where they can accomplish something cool. Feedback would be given to those ideas, be it within the team, from other departments, higher ups, or testing; the department would receive constant feedback on the ideas, features, and the design of the game as it is being developed made. The difference compared our team is that our primary feedback was from playtesting, after the feature was complete. Parts of the feature would be shown, but it would, more than likely, not receiving as much vetting as a complete feature. Every feature was tested at every stage and was given feedback with every iteration, where features were either pushed further or scrapped.
The final topic that caught my interest was the communication within the team. It was not just the fact that members were constantly talking with each other, it was that ideas and troubles that someone might have were dealt with help from other members. The core difference, that was already said before, was that the teams worked together, in the same building. Not only does this allow for better communication, but it allows members to be more proactive with each other. Our team was able to ask for parts from each other, that would later better be integrated. The difference there being the Far Cry 4 developers were able better and more quickly develop ideas for the game on the fly. Beyond that, having the close proximity with each other would allow for more ideas to be thrown around and aid from peers to be available. Saulnier presented a few items that describe how successful games are made by teams whose members are effective at working with each other.
GDC Vault Post-Mortem Reaction
Presentation: Far Cry 4: Gameplay Team Workflow, Iteration and Philosophy - By: Marc-André Saulnier
The first thing that struck me with this post-mortem was that a single department for the game had a diverse set of skills collaborating in close proximity to each other. In contrast to us, from the perspective of someone in a similar position to Saulnier, we separately developed parts of the game that was then put together in the end. This includes the fact that the group itself was split into two core teams of art and programming. The difference being the Far Cry 4 developers had people with various skill sets working in the same team, unlike us that divided ourselves because of our skill sets.
The second key item I noticed was how Saulnier kept talking about how the players were important to the game making process. He talked about how the team developed ideas that would give the player a variety of choice where they can accomplish something cool. Feedback would be given to those ideas, be it within the team, from other departments, higher ups, or testing; the department would receive constant feedback on the ideas, features, and the design of the game as it is being developed made. The difference compared our team is that our primary feedback was from playtesting, after the feature was complete. Parts of the feature would be shown, but it would, more than likely, not receiving as much vetting as a complete feature. Every feature was tested at every stage and was given feedback with every iteration, where features were either pushed further or scrapped.
The final topic that caught my interest was the communication within the team. It was not just the fact that members were constantly talking with each other, it was that ideas and troubles that someone might have were dealt with help from other members. The core difference, that was already said before, was that the teams worked together, in the same building. Not only does this allow for better communication, but it allows members to be more proactive with each other. Our team was able to ask for parts from each other, that would later better be integrated. The difference there being the Far Cry 4 developers were able better and more quickly develop ideas for the game on the fly. Beyond that, having the close proximity with each other would allow for more ideas to be thrown around and aid from peers to be available. Saulnier presented a few items that describe how successful games are made by teams whose members are effective at working with each other.
