Logo for Sellout Game

For cross-discipline I have made a logo for the student game Sellout. Sellout is a four person bank robbing game in which each player controls two gangsters with tommy guns. You can work with the other players to share the cash or double cross them to get more money. I have tried to capture the core elements in the game though the logo.

Handling Asset Data in Large Projects

As animators, we work with a large amount of data and a multitude of assets. Therefore it is essential that the asset data is handled correctly and organized well in large group projects. In this blog I will look at how I have handled this issue in the Rapid Reboot and Zurvivor projects, and how these methods can be improved for future projects.

Reboot Project

In the Rapid Reboot project we predominantly used Google Drive with communication over Slack. I initially set up this drive and created several different folders to help separate data.

I find that this keeps everything neatly organized and helps when trying to find particular assets. Additionally, Luke established a naming convention that was successfully utilized throughout the project.

The naming convention was as follows:

Name_Asset_Detail

Examples:

This helped us to easily see what had been done and who had done what.

Although the handling of asset data was relatively successful, there are several improvements that could have been made:

1.       A detailed asset list.

Our project lacked any sort of asset list. We just kind of told each other what was needed. This was a very unorganised way to create assets. To rectify this we could have had a detailed asset list which outlined the required assets and who was creating said assets. The list should also include a progress tracker and update box. This would have allowed the team members to mark their progress off (e.g. “Unstarted”, “Draft Done”, “Final Done”) and allows managers to easily see where everyone is up to. An update box would allow team members others that a completed asset had been changed or modified (e.g. “Updated: Version 3”).

2.       Version numbers.

This relates to the above mentioned update box. A version number should be incorporated into the naming convention in order to allow team members to easily see which the most recent version of a particular asset is:

Name_Asset_Detail_V01

This will also allow for roll back. For example, if Version 4 breaks and is completely unusable, the team can simply use Version 3 which works perfectly but is not as polished. This helps prevent a loss of data as early versions are always accessible.

Zurvivor

How we handled asset data in Zurvivor is very similar to the Rapid Reboot project. We use a well organized Google Drive and a naming convention. However, at the start of the project, Rowan created a detailed asset list:

This was extremely helpful to the animators as it clearly showed what the asset was meant to be and what type of asset it is. From here I moved this information to an “Asset List and Delegation” sheet. Using what I had learned in the Reboot project, I added a progress marker, delegation section and update section.

This has noticeably improved the workflow and has allowed Ben, Hamish and me to work quickly to finish assets.

Again, we haven’t yet incorporate version numbers. As these assets are for a game, they are either “Placeholder”, “First Pass”, “Second Pass”, and so on. So far this has been a sufficient replacement for version numbers. However, for larger, longer running projects I will definitely be utilizing a version system.

To the Future

For future projects I will using:

• Organized Google Drive
• Detailed asset list
• Progress marker and update box
• Naming convention
• Version numbers

These should allow for productive and efficient workflow.

Zurvivor: Placeholder Assets

For today’s playtest I made several placeholder assets. These assets were created according to the documented specifications. They are of the correct file size and resolution, follow the set out style and use the colours from the palette.

Corspe

Crate

Cupboard

Fridge

Tree

Zombie

 

Zurvivor: Asset List Delegation and Organisation

Using the list of assets that Rowan created, I made a new asset list that will allow the animators to delegate the tasks, prioritize and check our progress.

Zurvivor: Menu mock-up

For the Zurvivor game, I thought we could use realistic grungy textures, vignettes and possibly even film grain to create a gritty, tense atmosphere. To demonstrate this, I mocked-up the opening title screen. We could even add movement to the camera (make it see like it is swaying).

Zurvivor: Technical and Visual Guides

Currently, I am working on the Studio 2 trust game “Zurvivor”. The game is to be a four person, top-down, zombie survival game with 2D graphics. As we have lots of animators working on this project, I have put together some visual and technical guides to help with production. Hopefully these will speed our workflow and help us to maintain a consistent style.

Below is the initial style guide:

Here are the colour palettes for the different sections:

Here is the font guide:

Finally, this is the technical specification guide. This guide covers the required file type, resolution and sizes. It also covers the relative scale and sizes of the different assets, with images that can be used as reference.

Games Collab: Trust

As part of the cross-discipline work, I will be collaborating with audio, animation and game students as part of the Studio 2 games project. On Wednesday we spent about 5 hours exploring the concept of trust (on which this project is based). The project seems really cool so far and I am looking forward to participating.

This Trimester, the games students must create a game that utilizes and explores themes of trust. The game will be presented and played in an exhibition space. This means that the players will not be able to communicate as they will be wearing headphones. In addition to these conditions, students from other disciplines (me included) are to contribute pieces of work (pictures, animations, ideas etc) which explore trust or a particular aesthetic. The games students then have to draw inspiration from these collected pieces and design a game based around them.

So far I have contributed the following ‘inspiration pieces’:

From this the students could take: blind trust, lack of information, lying, vulnerability, colours, aesthetic or setting.

From this the students could take: trade, betrayal, risks/gamble, lack of information, colours, aesthetic or setting.

From this the students could take: blind trust, forced trust, vulnerability, obeying, colours, aesthetic or setting.

In addition to these pieces I came up with a weird game concept:

• Two player game sharing a single screen.
• Each player wears the old 3D glasses but with a single colour.
• Screen is monochromatic except for the playable characters and obstacles.
• Players will only be able to see the colour opposite to their glasses.
• Will have to work together in situations to get past obstacles but also have an individual score.

I know it sounds crazy but I think it will work. My friend is a programmer and had 3D glasses with just red in the lenses. He wore them while programming once (who knows why) and couldn’t work out why the program won’t build. He was using the dark skin for Visual Basic and couldn’t see part of his program (the thing that’s in red).

I think it would be pretty cool and you could do really interesting things with it. It would just take some adjusting and making sure the colours had the same tonal values.