Friday, July 25, 2014

Busy week at Burrito Studio!



Hi everyone!

We’ve been pretty busy here at Burrito, but we still have a little something for you this week again: the colored version of Micah, the youngest brother!


Design by BurritoMo and BurritoElo

Hope you enjoyed! Stay tuned for next week's post!

Friday, July 18, 2014

Official name and first poster!

This week we have exciting news! :D
We are officially revealing the title of our upcoming game: HIGHLANDS

If you're curious about the game premise, here is a little summary:




In a vast world filled with flying citadels,
a royal family is overthrown by an unexpected enemy.
They must then, with the aid and strength of their people, reconquer what is rightfully theirs and discover the mystery surrounding
the siege of its flying castle.




In a more specific way, Highlands is a turn-based strategy game on a 2D isometric map. The story brings us right on the frontlines, where each character you obtain has a strategic value and each combat with the enemy is decisive. 
It's a guerrilla warfare set in a fantasy world: build and fortify your barricades, manage your resources and reconquer the city, sector by sector.


We're also proud to reveal Highlands' first promo poster! 




And of course, here's our amazing team of joyful artists.

 
From left to right: François Coutu, Maude D'Amboise, Élodie Robillard and Loïc Fontaine.

Crazy crazy times. Yeah.


And one last picture for fan service purposes:


François seems to like it.

The blurry part is because we have yet to reveal all the characters, so you'll have to wait a little bit more! 
However, a first playable beta demo will be available in 3 weeks and we can't wait to show you guys what we've build over these past few months!

Have a good weekend y'all!









Friday, July 11, 2014

Programming a video game: The Prequel

***Alert: too much pictures of cats posted lately; it’s time for the programmers to take control of this blog!***


I am Alex (BurritoAl) the programmer of the team.  I will try not to dig too deep into technical details and may start a blog of my own at some point for those interested in the programming challenges involved in creating a game.

It’s been a few month I’ve been programming our game (official name unveiled soon!).  Looking back the first thing I notice is that creating a game really is an organic process and that the design and specs change almost every week.  You cannot get too much attached to your code and need to get into a real prototyping mindset.  Also your team will have a lot of ideas and you cannot get everything done at the same time, so you need to sort out your tasks and prioritize carefully.  Keep things flexible: refact often and early, but not unless necessary.



Tools of the Trade
We settled on Unity as our game engine: simple, cross-platform, big active user community and powerful enough for our needs.  I am not sure how it compares to the big engines for cutting-edge AAA titles, but for our isometric game it is more than enough features (and we took advantage of the new 2D Sprites engine introduced in the 4.x version).

Be wary though that even if Unity is free you will most definitely need to buy the Pro license at some point to (1) have control over the loading screen and remove the Unity logo (2) have access to some automation & advanced build-process functionalities and (3) have access to advanced rendering & debugging facilities when you’ll be in the final stages of development.

But here’s the catch: the Pro license has a per-user and per-platform fee, and you cannot mix free & non-free licenses for the same project.  This can get costly very fast.  For instance, having two developers working on a mobile Android & iOS game quadruples the license cost (not exactly, because you will probably only have 1 build-machine making the mobile-specific versions, but you get the idea!)  For this reason I had to create some editing tools to avoid everyone having to install Unity on their desktop, more on that later.

Also note that even though Unity is cross-platform, iOS is a pain an interesting challenge to develop for compared to Android/PC/Web ports.  Fortunately, we focus on a PC-only release for now!

All-in-all, Unity is an amazing game engine and I’m eager to see what they have done with the version 5 that is bound to come soon.



Our other main tool is a dedicated SVN server which grows exponentially in size as the visual and audio assets are flowing in.  Some tips: try to start using source-control from day-1 of the game development, don't hesitate to branch to test things out, always keep archives of the raw assets and make frequent backups!

For communications / mail, wiki, web-hosting, etc. we are entirely in the clouds.



An Editor within and Editor
Our level editor went from being a plain text-file with some extra scripts, to a text-file with lots of scripts to automate generation, to a more WYSIWYG experience.

It is currently still depending on being run from within the Unity editor, but my goal is to make it completely stand-alone (partly because of the license costs per-user mentioned above).

What I can say is that once you have a full graphics team up & running, they will generate assets like crazy and as a programmer you don’t want to be the integration bottle-neck because you’ll already have a lot on your plate, so having an editor that is somewhat intuitive and efficient to use is the key.

We put the bar quite higher on visual aesthetics as time went by (jumping from a small mobile release to a fully-featured PC release) and the tools have to keep up.  It takes a lot of time to develop and maintain but it also saves a lot in the long run.



Engine Architecture
I will briefly cover some topics about engine architecture:

     - First of all, make sure to clearly separate your data state from the game logic and think about persistence and serialization beforehand.  For example, I added some sanity checks via reflection that raise an error every time they catch a non-persisted data member or field: if a few of them slip through it could be very hard to find bugs after re-loading a game or a map.

-    - Separate internal engine code and make a public interface: the first thing I did is separate into two different modules everything that was internal engine code VS everything that could be scripted on top of it, and I created interfaces to describe the state of every game object.  I have the opportunity to work with talented people that know a little about scripting and I can give them all the tools to create interactive dialogs, triggers and describe a monster behavior without them ever having to modify internal game code.

-     - Game loop & state machines: Unity abstracts the major part of the game events sequencing, game objects management and the actual graphics rendering.  Try to keep the same philosophy by making small independent components.  Think data first (where is the data persisted and what you can do with it).  Don’t create too much dependencies, and magically you will be able to add or remove a whole game mechanics or add a new type of enemy on the fly without breaking everything.



General Development Workflow
    - Always have a playable build;

-          - Set fixed milestones or sprints (for example: a demo or release every 2 weeks);

-          - Stick to your deadlines;

-          - Discuss & clarify ideas: half the work of designing game mechanics and validating gameplay can be done on a whiteboard or pen & paper.  Make sure with the team that the rules are clear: if they are not, define what kind of tests & prototypes can be done to validate the correct direction;

-          - Provide debugging facilities for your team!  Cheat functions, walkthrough statistics, heads-up debug displays, etc.  Anything that can be used to quickly test a situation and understand it.  Take the extra time to develop these, it is well worth the effort;

  - Keep an FPS counter visible somewhere and always be on the lookout for performance drops and memory leaks!



Ok! Enough programming stuff for the day, we’re really eager to reveal some screenshots and actual gameplay descriptions and videos … let’s go back to work and see you soon!

And if you have specific technical questions, please do leave a comment and I’ll be pleased to respond!

 

Monday, July 7, 2014

A (new) Introduction : our first 6 months



As of this week we are 6 people working full time on this game project plus many others doing part time work and a great many others helping us with their time, enthusiasm, opinions and encouragements by testing the game and challenging our decisions every step of the way.

We have built an amazing team and we are so thankful to everyone who has helped Burrito Studio.  Much work still needs to be done, but we can confidently say that we are halfway to a first game release and that things are in full motion!

As we start this blog it seems a good opportunity to take a look back to where we started and the challenges we had to overcome.

For now we will just make a quick overview of the crazy helter-skelter that has been the last six months, but we hope that underlying the process of building a small company from scratch will get people interested and that we will receive many specific questions on the challenges we had or are yet to overcome.  Please feel free to drop some comments and questions; we’d love to read and answer them!




This story has two prologues I guess, two branches that merge together.

At the tip of one branch you have Alex that is in the process of leaving a big game company where he had been a programmer for a little less than 8 years and got promoted into entry-level management.  It was a very big company with AAA productions where dozens or even hundreds of people could be working on a title at the same time.  The challenges were greats and the team he was managing was amazing, but he felt somewhat distant to the real production & creativity issues involved in building a video game.  Without a clear path ahead of him to get more involved and feeling slowly sucked-in into more abstract programming work / middle-management grounds, Alex made a leap of faith and decided to quit and try other projects on his own.

On the other branch leading to this story you have Jonathan and Maude, the two other co-founders of Burrito Studio, that have been living together for a while and shared many dreams & ambitions.  Six months ago, Jonathan had just finished a music degree and was looking to undertake his next artistic project.  As an avid gamer, he always had some game stories and ideas at the back of his mind, and had the idea of positioning himself in the game industry in the sound design field.  As for Maude, she is a talented graphic artist currently studying 2D animation and did some contractual work for game companies.  Maude and Jonathan started sharing ideas about a game world and some gameplay mechanics.  This grew into a pet project.  When the three of them had their first discussions about this game project, they already had some concept art in place, a basic narrative framework and about two dozen pages of game rules ideas.

So we have Alex leaving his game programming job and going freelance on one side, and Jonathan and Maude having their part-time game project on the other. They all lived in Montreal not that far from each other and had some very fun evenings with a few drinks, talking about the good ol’ days and the future days and projects to come. Alex shared his feelings about his job, and Jonathan and Maude shared their game project idea.
 
It seemed there was an opportunity to start something here.   

Back then, we never thought it would grow very big. Alex thought he could maybe kick-start Jonathan and Maude, give them a few pointers about game integration in Unity, maybe work a basic framework with them and get involved in their pet project as a part-time hobby. And that would be a fun side-project.

But as we all started to get slowly involved, I guess we all started to really enjoy ourselves.  That’s as simple as that, the basic cornerstone of our venture.  Having fun.  And the project just grew bigger and bigger and we sank into it head first without even realizing.

Soon we saw we had our hands on something and the work grew exponentially larger than anticipated.  We took a step back and realized that if this pet game project was going to lead anywhere, we needed to focus all our efforts and just go full time into it.  It was a big step to take, but it was a natural decision for all of us.  We laid out a very basic planning and time frame to release a game, formalized our commitment on paper, and also consulted with people having their own small businesses to get their take on it and learn what to expect. 
We knew a little of the indie gaming world and had some ideas on how to start a business, but looking back it really wasn’t much.The process of starting a company is like taking educated guesses one after the other: every time your guesses are better but the question is bigger.

So we had a project we were willing to commit.  The last thing we needed was some kind of catchy name to identify ourselves as a little indie start-up.  That’s when Jonathan and Maude's overexcited cat  jumped out of the corner sneakily and began to play with a roll of toilet paper. His name is Burrito, and the studio got founded.



 Burrito

Photomontage of the year.