As a small team of five, tasked with proving something experimental when it comes to game development, we set out about three months ago to build a demo that would show Pine's USP in any form. This monday was the deadline for said demo, which we showcased at Indievelopment 2016 in Jaarbeurs, Utrecht, The Netherlands. Exciting times! For the first time ever, actual gamers we didn't know would get their hands on a full Pine experience that lasts between 10 and 25 minutes.



The day went way better than expected - we took home the Unity award for best Unity game and we've gathered a large batch of data to work with in the upcoming weeks. In this small blog we'd like to give a few bullet points of things that helped us create a demo like this while we were almost never in the same room during development.

• Weekly reviews: Probably our saving buoy during the asynchronous, hasty and individual development of parts of pine, were the weekly meetings of about 2-3 hours we did. It's very common in normal Agile game development, but as we didn't utilize a physical scrum it was quite difficult to maintain the tasks sometimes. However, once a week we would meet up and show each other what we did and what we were going to do. As we don't have an office, these hours were also good to just check how everyone's doing and if we're all still on the same line.


• Tight online planning using Google Docs and Sheets: In order to never forget anything, we decided we should write down everything, always, inside Google docs and sheets. Then, during reviews or Skype/Hangout sessions, we could discuss them. It may sound trivial, but it's insane how much information gets lost when you're not sitting next to each other.


• Work on the bigger and smaller picture in parallel: We were always building a smaller demo case next to the bigger demo to be showcased later. This allowed us to test things in small scenes (programmer Marc has a scene called the Lab in which he starts the creation of mechanics/species), while always keeping an eye on the demo that was to be showcased for an audience. Our environment artist would work a lot in the bigger scene while the others nailed the basics in smaller scenes. Quite effective!


• Quick decisions, quick iteration: We have a mantra that we really stuck to during these three months - iterating is easier than creating. Our goal is to quickly make SOMETHING, anything (within what we're trying to achieve of course), and collectively see what can be improved later. Again, sounds trivial, but too often someone gets stuck on a task because she or he wants to deliver it pitch-perfectly the first time around. That's not gonna happen, so put something in the game and we'll see what we can do to improve it as fast as possible.


• Make tools, not content: By building simple triggers immediately, Marc didn't have to be bothered with building events or hardcoding things into the game later. While he was working on small demo scenes with new mechanics, others could quickly iterate and make gameplay chunks using generalized tools/objects rather than scripted events (such as a simple activation trigger to turn on/off GameObjects). Think about this early (which ones you need, for example), it can save a bunch of time later.

To end this with something more visual, we share a video of the development process with you. Although we started out with gifs, making the video a bit wonky, it's fun for us to see the improvement over time. The video ends with parts of a walkthrough of the demo!