VERTICAL SLICE

SCOPE

The scope of the vertical slice is essentially a big asset list of what is needed for it to come into existence. In other words, it's a way of breaking the whole project down into parts, to make it more manageable. It also allows one put the varying areas of development into perspective, to figure out what and how many resources will be needed. As time passes, the scope can be altered based on certain unpredictable circumstances. It is important however, not to succumb to scope creeping. Scope creeping is when insufficiently justified changes are made resulting in the misalignment of scope and vision. Taking things out of the scope is less risky, however one should always double check that the core aim is not affected.

​

In the case of Wild Wild animals, our scope is up for every group to read as a Trello card: 

​

- Design, create and implement three 3D battle maps
- Design, create and implement four 3D weapons (revolver, rifle, shotgun and dynamite)
- Design, create, texture and animate five characters
- Implement sound effects and music
- Implement in-battle UI
- Design humorous narrative / text / character speech
- Make cutscenes for narrative
- Create appealing western lighting for battles

-Apply particle effects for aesthetic appeal

-Create UI to structure the vertical slice
_________________________________________________________________________
Things taken out so far:
- Implement customisable character traits
- Make menus for each core building (gun shop, saloon and church) and the town.
- Implement weapon upgrades
- Implement character customisation
- Implement skill trees

- Design and Implement post battle looting UI

​

WEEKLY BREAKDOWN

The weekly breakdown is essentially a further dissection of the vertical slice. Once the scope is decided on, and the resources available, people need to know what they are working on, and within what time frame. This also allows for a better understanding of how long the project will take to create. Creating a weekly breakdown is also useful when it comes to coordinating the sub-projects. Some parts of the vertical slice are stand-alone until the end when everything is put together. Other projects have several steps to them and different people with different skills must collaborate to make them happen. For example in out case we have a map creator who's work is dependent on the creation of assets. He cannot make the map without the assets. In this case, the team leader must orchestrate the weekly breakdown in a way that the assets are ready for the map creator. This may seem easy, but can prove to be quite challenging when the goal is to keep everyone busy at all times for budgeting reasons.

Click the button below to see all weekly breakdowns created so far.

BUDGETING

Although the weekly breakdown changes as time passes, having an idea of how long the entire project will take allows for deadlines to be set. With deadlines in place, we know how long we will need which resources for. This includes employees, software subscriptions and hardware purchases. With a set deadline for the project we can also measure which software and hardware would be most cost efficient for their required purpose. It is also smart to take into consideration potential future projects that could reuse such products. 

​

You can read more on details of how this project was budgeted in the Week 2 reflection in my blog. I have also created an Excel sheet where I did all the calculations in a more structured way. To see this document click the button below.

QA TESTING

QA testing is an indispensable part of producing a vertical slice. It is essentially a breakdown of the games functions. This doesn't only include the game mechanics, but other functions such as buttons, the order and running of scenes, animations an a lot more. The first step to creating a QA Smoke alarm test is making a list of everything that is required for the game to run as intended. These processes need to be defined in a way that anyone testing it will immediately know whether the function is working as intended or not. With each time that the test fails, the reason for failure must be documented. If the failure is potentially replicable by a user, the consequences must be noted as well. A version history of attempted fixes should be documented with the names of the testers and screenshots for future reference.

​

As of now the QA testing has not properly begun for Wild Wild animals since the project has not yet been assembled in its entirety. Nevertheless I have created a QA testing Excel sheet with the help of the team coder Safwan.

To look at the template click the button below.