Capricia Productions Interviews

Since I’m currently working for a small indie company I thought it best to ask some of the directors about their experiences with game development. First off a bit of backstory on the company and who created it. The company is called Capricia Productions and it is based in Israel, it was founded by 3 people Shai Amoyal, Arnold Nesis and Ben Shmuelof in 2013. Shai and Arnold are the 2 I have interviewed for their opinions on what has went on during the project. 

The game they are creating is called The Birdcage and it is an action adventure music video game. The idea behind it is creating a game that works like an interactive music video.

“Think of a really cool music video you saw once, but now imagine that you’re in it, interacting with the environment that changes according to the music” – Steam greenlight page.

I decided to ask them separately so I can see if there are any differences in what they say.

Their Website -  http://www.capriciaproductions.com/

Their Greenlight - http://steamcommunity.com/sharedfiles/filedetails/?id=485411941 

Their Patreon - https://www.patreon.com/TheBirdcage

First off, what methods did you use to plan out the fundamentals of the game?

Arnold -  Well, for us it was a bit different then your "average developer" - when we started, we were a group of musicians and had no idea about game design and that world (apart from me being a composer for games). We basically decided that the music is going to be the center, and the story is going to be told through the music - the rest is going to support that. From that point, we basically made a lot of mistakes and learned "on the fly". 

Shai -  I Googled A LOT at the beginning! But mostly I asked around about methods other people used and I drew inspiration and what I thought was necessary from each one until I formulated my own. 

It was interesting to find out that this is their 1^st development inside the games industry. Both of them basically talk about how they looked at what was needed and used that research to work out what they wanted to create. A lot of it looks to be trial and error in the early development. 

What major difficulties or pitfalls have you encountered during the project that you think could be avoided? 

Arnold -  Team mismatch. At first we didn't know what people we want with us and how to manage a team. It took a pretty long time to figure out exactly what people we want to work with and how to work within the team. I think this can only be avoided with experience though - it's very hard to understand at first what the specific team needs and what's more important and less important. I think a very big good thing we did is setting the 20 hours/week thing - it works much better then assignment based projects. 

Shai - Always thrice the schedule! You might think you know what's best and how long things will take you to do but unforeseen circumstances are always there, just waiting around the corner and you can never be prepared for them. We have had so many people walking out mid-development or so many things that we thought we finished with them and then a problem popped up and ruined our plans, so what I did was basically just allow some margin of error to everything and I learned that every game goes through it and to just not stress. Everything has a solution, it's only a matter of finding it. 

This point is also based off trial and error but all if comes down to time and team management. Since my project will be a one-man team I will be avoiding the pitfalls of the team members being mismatched or quitting, I’m quite happy I don’t have to deal with those problems with this project. In previous experience, I’ve been on a team where people don’t show up to work or don’t contribute fairly to a project and it is a very frustrating thing. Adding some extra time to allow for problems to be dealt with is a great idea for keeping on top of things and I will be keeping it in mind as I go each week. 

What gameplay elements would advise to stay away from for a small game? 

Arnold - Massive multiplayer elements. No matter how good the game is, indie small games don't have enough users on-line at first and this can kill a game. I've seen a couple of examples for it this happening. 1v1/2v2 can work ok but don't count on many on-line users.  

Shai - Huge open worlds and big multiplayers are such a big pitfall IMO for small games and developers. It's nearly impossible to make these without a big budget so I'd steer clear from them. Although if you think i'm wrong - hell, prove me wrong! I'd be happy if you do :) 

I agree with what they say on this entirely, large scale worlds and multiplayer are difficult things to do because of the amount of time and knowledge required to create them properly. Thankfully neither of these are part of my games plan.

Did you use any time saving tricks in asset or concept creation? if so what where they? 

Arnold - I think the best one is having a few people on the team that have their specific strength, but also can do other things. This is mostly common in people who are working with UE4 - this creates a situation where if there is a bottle-neck, it can be much easier solved by just temporarily moving people from their main assignment to help another. It speeds up the development process significantly  

Shai - Using outside references for assets and sometimes just not spending time on concepts helped us just go right into modelling or just development. Also, using shared documents helped us a lot with being more efficient.

Their replies to this question were interesting for seeing their different ways of speeding up the design work, Shai is the lead for the Art team and his rely reflect some of the tricks used by myself and other people under his direction. An example of this is, when describing characters Shai will always give me a bunch of references for the general look of a character but will also give me some specific references for things he wants the characters to wear. In contrast to this Arnold is the lead for the programming side, so he gets his group to aid each other to speed up the process by bouncing them between different aspects as a group.

What element of the project do you think takes the longest period of time? Could it be shortened in any way? 

Arnold - I think the thing that takes the most time in general is not a specific element but how the whole thing works together. Game development has a lot of elements to it and everything is connected to everything - at least when it comes to delays, if you can solve the bottlenecks, it can speed the thing dramatically

Shai - The conception. Doing pre-production right is key, and should not be overseen as something "You can do along the way". You can, but it will steal the majority of your time and create a dissonance between the development teams. Do pre-production before the actual work. Assess everything and it will save you time later. 

Their views on this are both about making sure that everything is planned and managed properly. I agree that it can get messy if everything isn’t planned out properly, it is easy to end up working on something irrelevant to your current needs if you don’t plan. 

How have you attempted to engage the gaming community to get support for your game? 

Arnold - Patreon page, greenlight and dev forums are the immediate suspects. Every time I see someone on facebook, twitter, or any other media who seems to be into things like our game I try and message him and tell about it, show some links and hope to get them into the community. It's a hard one-by-one work.  

Shai - We did, for Steam Greenlight, and the responses we got were a lot better than I first expected. 

Finally, they mostly use the standard social media platforms to engage the community, but Arnold's extra work into finding people who could be interested and contacting them personally might be something I look towards doing later into the project.

A lot of what they said adds more proof to the pitfalls of indie development and the problems that can happen if anything from teams to time are not managed properly. It was useful to get a bit of insight into how people who didn’t come from a games industry background approached their 1^st game, initially it was all trial and error but once they worked out a method of planning it all, the project began moving at a steady pace.