Week 5 and 6

Week 5 and 6 were the first two weeks of the three-week sprint we’re currently in. This sprint’s aim is creating the “First Playable” of the game we’re working on.

The first day of the sprint was mostly spent on planning. We first had a Sprint Review where the work of our previous sprint was demo’ed to the stakeholders. As we mostly did research on the tech side, the majority of the demo was art and design presentations.

After the Review we had the Sprint Planning meeting. In this meeting we discuss all the User Stories put forward by management and assign Story Points to the user story. These points have an abstract value, summing up the difficulty and importance of the task.

After the Sprint Planning each discipline (tech, art, design) created sub-tasks that need to be done to reach the goal of that User Story. These tasks were assigned hours and put on the Scrum Board. If a task’s length is very uncertain, we put up a timebox task covering the maximum allowed time to be spent on that task.

After the planning we had a Sprint Retrospective meeting, where each person writes down up to five things they thought that went either good or bad in the last sprint. Afterward these were categorized and discussed within the team.

In the two weeks following this planning day, we had Daily Standups where you describe what you did, what you will do and any problems you are having.

In these two weeks I worked a lot on workflow issues and provided a lot of support. I spent most of my time working on a Perforce (version control) plugin with Marin that will improve the workflow a lot and that will prevent merging problems by actively locking unmergable files if someone starts to work on it and that shows warnings when someone changes a file that someone else has changed locally as well. Besides this Perforce system, I worked on improving the asset importer scripts, creating and improving our scene system and gameplay tasks.

For the gameplay tasks we had two meetings where the designers explained the tools they would like to have in place to create gameplay and levels. We decided to use a few middleware solutions. The designers will script the level flow and events using a Kismet-like system with State Machines (FSMs) and we’ll use a Camera Path system.

For the FSM system we’ll create “building blocks” as the designers need them. We will also evaluate their FSMs once in a while and see if there are certain things that can be put into code for better performance and to make the life of the designers easier.

For the Camera system we’ll use a system that has a lot of built-in functionality already, such as easy editing and previewing of paths. However, we have found out that the system is really inefficient and has a few limitations, so we’ll need to redo quite some coding. Still, it will save us time from writing a system from scratch.

So far I have mostly finished the “Perforce and Workflow” tasks and have finished some of the gameplay tasks such as the Health system and most of the Weapons and Damage systems.

In the last week of the sprint, I will focus more on the gameplay systems and hopefully we’ll put the Perforce and Workflow plugins we have created into full use; so far only a selected few have been using them since it would have a big impact if something went wrong.

By thomhurks

Programming Intern at Vanguard Games, Amsterdam.