Category

Development Post

Behind The Scenes: The Music of To-Tum [Updates]

This week I’m once again going to be talking about the music for To-Tum and how things have changed since my last music blogpost (which you can read HERE).

The revisions that we’ve made are in regards to the interactive music system I mentioned last time; our plan is still to use vertical re-orchestration with 3 stems, these layers still being triggered by a player’s progression through a level; however, after playing the game intensively I felt there was more we could do with the music to support the player’s experience!

I have no doubt that many among you will remember (and even own) such popular consoles as Nintendo’s Gameboy and SNES; these consoles along with many others, had a relatively small space in which to store files and game data. Now you may be wondering where I’m going with this, but when developing modern mobile games we can sometimes find ourselves with very similar limitations; less space means less art, a smaller overall game and of course less space for audio than what might be achievable with games for big name consoles like PS4, Xbox One and PC. It has never been more important to get more mileage out of music for games and it is to this end that we’ve revised our layering system!

Like many popular mobile games, To-Tum features a series of levels separated and spread out over certain themes, in our case: sky, forest, ice, desert and fire. Each of these themes defines colour schemes and level decoration, and now thanks to our revisions, each theme is also defined by a particular musical instrument! This instrument will only feature in levels belonging to that specific theme, for example, only in sky levels will you hear the sound of a solo harp.

But instead of writing a completely new playlist of tracks for every single theme, we’ve decided to work with a number of ‘core’ tracks, each split into loopable stems; a base layer, a progression layer and a reward layer. The base layer will play from the very start of the level and will not change with each theme, similarly the reward layer will always be the same for the base layer that it accompanies, however it will only trigger once the player has acquired all the collectables in a level. But, the progression layer, that plays only as long as the player is heading in the right direction, will feature the theme specific instrumentation. It’s through this system that we’re going to be able to get more mileage from each track; the core track will be recognizably the same, but thanks to the variations in the progression layer, will fit with each theme change.

Screen Shot 2015 08 26 at 19 09
(Screenshot of Pro Tools, the lines across the waveforms showing how volume automation can be used with vertical re-orchestration/layering, note how we’re now changing our progression layer with each theme (Ice, Forest, Sky, Desert & Fire/Lava) but keeping the base and reward layers the same!)

Similarly, we’ve also decided to have our main map music change with each successive theme. This way when a player returns to the game after having not played for a little while, the music will serve as a reminder of what set of levels they got to last time.

I hope you’ve enjoyed this little behind the scenes music update for To-Tum. Keep up to date with all my music going’s on over on Twitter (@DougWatersMusic) and be sure to follow Insert Imagination too! (@Team_ii) – we’d love to hear your thoughts on To-Tum!

– Doug

IMG 1293

5 Things I’ve learnt Working in a Team Remotely

Image from: wikipedia.org/wiki/Videophone

–Some of Team ii on a Skype call–

Remote working is growing ever popular for companies, with the next generation of employees being fully comfortable working with instant messaging, Skype and other online-based work tools. This week I wanted to share some of my experience working as part of Insert Imagination remotely, this list is by no means what every single team might experience, but it covers some of the benefits and draw backs to our remote-team-working situation.

Insert Imagination work from 5 locations across the UK; Dundee, Manchester, Kent, Great Yarmouth and Norwich. So we are not exactly having to span our development across time-zones, but we are all working around our own schedules. We began working together as a team during the competition Dare to be Digital in June 2014, 5 of us worked together in Dundee on a game, whilst Doug worked remotely from Great Yarmouth, keeping in touch via phone and email. After the competition finished, we elected to continue working together as a team on a new project, despite us all moving back to our respective homes.

1. Make sure you know who you’re in bed with.

Working remotely on a project requires even more team working skills and trust than any other form of project. Before starting a remote-project with a team, take the time to get to know them, meet them in person if you can and ensure that you can gel well even when there’s just a keyboard between you. The reason that Insert Imagination works well as a remote team is because we have all worked together before in some form or another. Archie and Steven worked on projects at Abertay University during their degrees, Shaun Jess and I had worked on a number of coursework projects, and Doug, Jess and I had worked on small projects before embarking on Dare itself – long before we started working remotely together.

The last thing you would want derailing a project would be a clash of work-ethics or methods, or ever worse – a clash of personalities!

2. Find the right tools and methods – don’t shy away from tech.

It took us quite a while to find the right way to monitor and plan our work together, we used everything from Facebook groups to Producteev – everyone recommended trying a different style, and nothing quite clicked with all the team members. That was until we decided to trial using Slack. However we do not only use Slack as our central point of discussions and updates, we use it as our nerve centre for the project. It was the service-linking quality of Slack that really made it stand out for us as the right tool; we were able to link Slack with GitHub, providing updates on everyone’s progress (particularly great for me as a producer meaning I can keep an eye on progress on the go, checking pushes to git on my phone etc.). We were able to connect our Trello board to Slack, showing to-do list updates and task planning, we connected Google Drive and Twitter (you get the idea).

Having a central point for tracking the progress of your project helps focus your team members to the task at hand. They do not need to worry about having several different apps and websites open and ready, just to stay on top of what is going on. Also it gives team members a chance to catch up on discussions they were not able to attend.

3. Over-estimate, Over-estimate, Over-estimate.

Working on a remote project full-time is very different to working on a remote project on the side. All of our team members work full-time, and this means that we are constantly working around 6 people’s schedules. I would say that by all means set yourself challenging goals, but always over-estimate your time-scale for delivery.

Quite apart from the curve-balls that full-time jobs can throw at you, there is also the responsibility that everyone has to their families and significant others. No-one can predict (or would want to for that matter) what a loved-one might fall ill, or friend needing help, or you needing to move house (or in my case move house and plan a wedding). And so you need to work with a great deal of flexibility in time-lines in order to try and account for this.

At the end of the day, it is passion which brought our team together, so I know that they would not be behind on tasks without good reason. And sod’s law has a way of messing with even the best laid plans, so over-estimation can try to help alleviate some of this.

4. Be conscious, considerate and kind.

When you are working in teams remotely, you will need to be aware that emotions and meaning can often be lost in written communications, and that you need to account for the fact that you do not get to see these people everyday. People may well have a lot going on in their lives outside of the project and so it great if you can try to always try and assume someone’s best intentions.

Similarly, there is a great deal of trust involved in working remotely as a team, and with that trust comes a need for transparency. If life throws you a curve ball which is likely to affect your ability to work on the project (and I’ve pretty much had one of every cliché out there this year) you need to feel comfortable enough to let the team (if at the very least the project manager) know about this, so that they can try and accommodate for the change in work-load.

Being considerate and mindful of the various pressures of real-life on all the team members, and being kind towards them helps you rally together if things get tough on a project. At the end of the day, you are working on the game out of a passion for the project, a combined love of what you are doing, and that will help sustain you when things get tricky. That and remembering it is a true team effort both the wins and the losses, will help weather those storms!

5. Keep a Sense of Humour

And finally, remember to keep a sense of humour when working together. Laughter can help keep you all going when the work-load is high and the time-scales are small. I always try to remember that whilst we are a team, we are more importantly friends in Insert Imagination and that is what helps us all keep going. Posting that meme, or lightly poking fun can be just the thing to keep you wanting to work on that project, and with your team.

—-

I hope that this blog post has been somewhat useful, even if it sort of turned out like a self-help-team-ii-love-in. Have a great week everyone, and please share with us what keeps your remote team together in times of need!

Robin

x

Behind The Scenes: Art and Building Levels!

It’s been 7 months since we first began development under the name of Insert Imagination Ltd. and fully began work on To-Tum, and it has almost been a year since we were Team II with Kuria. A lot has changed during this time, my understanding of companies, how different working remotely can be, but obviously most importantly the biggest changes have been to the game.

Behind The Scenes: The Music of To-Tum

In this, our second blog post, I’m going to be talking about the music I’ve composed for To-Tum. I’ll be covering my musical influences, my first steps when writing a track and how we’re using reactive music techniques to build a better player experience.

Normally as a composer, when starting work on a new video game project, much of the game will already have been completed and you’ll have a wealth of content to creatively inform your music; in some cases this might just be screenshots or concept art, but in others, a playable version of the game.

Behind The Scenes: Development Pipelines and Technical Challenges!

Hi, Steven again! This week I’m here to discuss the change in development pipeline from Kuria to To-Tum, the challenges we faced in recreating the experience of Kuria for a Mobile platform, and several technical design decisions we made to help us stay true to the core of our original game.

During Dare To Be Digital I wrote about the early development stages of Kuria (http://www.daretobedigital.com/d2bd/team-information-2013/blog.php?intStoryNumber=12152&idTeam=2733) and how we iterated upon this throughout the summer (http://www.daretobedigital.com/d2bd/team-information-2013/blog.php?intStoryNumber=12919&idTeam=2733). Working with such a hardworking a dedicated team allowed us to Plan, Develop, and Iterate on Kuria throughout the summer, without being precious of our work, and maintaining this attitude allowed us to make the tough decision to start development from scratch with To-Tum. This was not necessarily an easy decision for us, a lot of work and time had went into Kuria, but we felt starting again gave us a chance to come up with new ideas, including pushing development for mobile and designing the game around a new control scheme!

Work In progress Level

Part of development was to ensure that we were able to load levels quickly, much like Kuria, to allow players to seamlessly play though several levels in quick succession. The solution to this was to create levels as prefabs, and instantiate them at run time. This was fine until we started attaching new components to objects in scenes, and we found that unfortunately Unity doesn’t currently support nested prefabs. The solution we found for this was creating levels using “Building Pieces” that created the actual game object assets when a level had fully loaded. This means that we are able to make large scale changes to art assets, prefabs, and materials without breaking prefab connections between levels!

This system has allowed us several times to change art assets, implement a system for enabling and disabling mesh colliders on pipes when the player object was not near them, and to create levels quickly using our modular assets created by the wonderful Jess Magnus!

Modular Assets for level building

Following this modular principle has allowed us to create a strong pipeline in which to develop To-Tum, allowing artists and designers to create content without the need for features to be scripted, and allowing us to prototype features using basic prefabs before assets had been created and implemented! This freed up a huge bottleneck that features in game development, so that all disciplines would be able to focus on their task at hand without relying on the others, which considering the remote nature of our team has worked out very nicely!

Another Work In Progress Level

This next point might sound like beating a dead horse, but something I’ve personally found important during working on projects is ensuring that development is organised. For me this was met by setting up a specific workflow for the project with the team, specifically following the Git work flow (https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) ,this allows the team and myself to monitor features and test them individually from the main build, something which is crucial to making sure game breaking bugs don’t make it into the game. I know this may not necessarily work for every team on every project, but for us it allows clarity to see what progress is being made on features in development, and allows us to not step on each other’s toes 😀

Thank you for reading my post today! Just a quick shout out to the awesome guys at Teaboy Games (https://twitter.com/TeaboyGames) who we forgot to mention in our Develop Post! The are awesome and you should totally check them out! Please check out our Twitter and Facebook pages. If you have any questions feel free to leave a comment or hit me up on Twitter (https://twitter.com/StevenTaarland)