Still in the first month of development as Introvert Studios, we wanted to share some insight into how we work.
What core roles do we represent?
-”Three developers and an artist. A quadruple of introverts working under the same roof!”
At the moment while working on Gods of the Arena we have subdivided responsibility
of development roles into several key areas.
Role 1 : User Interfaces
The game we are working on requires a lot of time to be spent on the in game UI. The game will have many UI aspects such as the in game world, shop, gymnasium etc.
The UI graphics are created in Adobe Flash CS6 and imported into the project as an SWC file.
This way we can take advantage of the Flash AS3 display list which works really nicely for buttons and such.
Lesson learned #1
- “UI changes often so you must adapt or die.”
This is because the accessibility needs change with the game features, which forces our UI
guy Sam to re-evaluate and re-implement often. (Although this is happening less frequently these days).
Role 2 : Battles
The battle mechanic is the most important aspect of the game and must be fun and exciting.
The main reason players would need to level characters and buy items is so that their gladiators perform better in the battle.
This has had several entire revisions from near ground up to accommodate changes and prototype various ideas we have had.
Lesson learned #2
- “Prioritise most important features early. Roles should accommodate skill-set while keeping everyone balanced.”
James is working on the Battle feature which is not only the most technical feature to implement but also the most important.
Why is this important?
It is the main reason for anyone playing our game to level up their gladiators, or buy items in the shop.
It must be exciting, bloody and bold!
James, the Lead developer, has taken this role so that his expertise can benefit the most crucial aspect of the game.
Role 3 : RPG
The game is full of various stats, upgrades, traits and other role playing elements…
…that imposes a potential problem of balancing them all.
Kevin is responsible for the design, implementation and testing of all RPG like elements. This is a meticulous role which could also change frequently if not careful.
Lesson learned #3
- “Plan thoroughly but do not plan too far ahead.”
It is good to plan all of the high level game design features and mechanics early, but be careful to not plan in too much detail as those details are likely to change and grow and you will end up wasting your time otherwise.
Many developers start from a game design document and build top-down from that design.
We prefer to evolve a game design document over time as it allows change and a focus on planning important aspects of the game.
Although a problem with this idea is that it promotes feature creep…
Role 4 : Creativity
Our project requires a huge amount of art work so a dedicated artist is required to pull it off.
Claire’s role is not just about designing and creating graphics but to solve technical solutions (such as entity resolutions) using her creative skills.
There have been many times where we developers would be debating some issue and Claire quickly sketches something up so we all understand what the hell we are all talking about.
Lesson learned #4
- “Just because developers are different it does not mean artists are not part of the development cycle. Art is expensive, code is cheap.”
Do not manage an artist like a factory.
You will find the work produced far better if you integrate the art pipeline into the development pipeline.
At the start of the project the artist can mock up many in-game graphics, including small animations, at a fraction of the time developers can achieve.
In mid-project the artist can work on a chain of assets that have been concretely decided from the game design. This allows flexibility at the start of the project where its more likely features will change.
What happens at the start of project?
We designed the game for weeks before deciding it was a worthy investment of time. Parallel to that, the Lead developer was busy writing a framework so work could begin rapidly.
Our game design consisted of some short game design documents, many meetings and discussions, followed by paper prototyping and other techniques.
Lesson learned #5
- “Make your team part of the design”
We found that the best form of game design was to make sure every team member knew the game somewhat in-depth before we started development.
The design will, and has, evolved over time which means continuous discussions and presentations will keep the team up to date, solving any issues.
Designing your game at the start and expecting it to work is a setup for fail – instead inspire your team with knowledge on the product they will work on!
Oh – and whiteboards are your closet friend…
How do we manage our project?
We are using an evolutionary prototyping methodology, which means we develop the game overtime by building prototypes and when happy with the result, implementing that result into the game.
This methodology works very well for us as it allows us to become experts within specific domains of the games we make, while keeping up with deadlines.
At the start of each weekly iteration, we have a discussion of where/what stage we are at before
coming up with a new weekly feature set in Pivotal Tracker, a story management tool.
We use Google Spreadsheet to record our daily tasks for each team member.
This cycle will keep repeating until the game is done!
Lesson learned #6
Hopefully that has opened the door to what its like inside our studio and how we work.
If you have any questions or feedback please message us below.
Over and out.