THE DEV DIARIES #5 - Does the code have a soul?
This time Péter, our programmer, talks about the birth of the project, the first steps and the overall beauty of his work.
Péter - I like to be around the birth of something - or someone. It’s a very special moment that can’t be repeated and rarely happens during a lifetime. I had the luck to be around the birth of this project, and I’m very grateful for this opportunity.
Every newborn project starts with careful planning. Ours is no different - we had to pick the right tools and the right people for the project to meet both our time and budget constraints. For every little challenge we had to opt for the most efficient solution that brings us closest to our goal. Surely, down the road, it’s inevitable to make compromises, but if we choose our tools and methods wisely -in the most creative way-, we can spare a lot of time and budget that can be spent on anything else, in favor for the game to give more to the player. As we’re a small team, we not only had to search for the best and most affordable tools, but match the tool to fit each members skills / abilities, and most importantly to reduce or kill repetitive manual tasks from our pipeline.
Lazy programmers tend to automate the smallest tasks that are repeating more than a few times, and that laziness proves to be the best time saver every time. Building up and optimizing the best workflow for each problem was and is the most challenging part of development. Work amounting weeks can depend on a single decision, and that applies to every aspect, from deciding on how to take our photos to how to edit localized texts.
At the beginning, we didn’t even think too much about the game engine, because it was obvious that Unity would be the perfect fit. It enables us to work parallel even on early prototypes and blockouts leaving time for the artists to work out the details. This way, every asset can be replaced any time later. This helps us a lot with not just planning and iterations, but testing out game mechanics and killing bugs in the earliest stages. Everyone on the team feels comfortable with the engine so we’re definitely sticking with it.
We started development by defining the core entities and their relationships. We knew there would be a lot of scenery that would include characters that could have items, dialogs, etc. so it was clear that we had to visualize their relationships in order to bring order to chaos. Once we sketched the hierarchy, the world we were trying to create started to make sense programmatically. Unity makes it easy to create and test different scenes, but we had to build a system around them, that manages the scenes and the things we want to keep persistent, so we designed all the managers for each requirement. Once those worked, we finalized the principles on how we’d edit, store and load all the game data. Then we came up with an idea about how the interrogation should work, but didn’t know yet, how we’ll store all the data. Until then, it seemed like a regular transactional database would do the trick, but managing hierarchical data needs more. So we searched for alternatives, and quickly ended up with a graph database that would match our needs best.
OrientDB provided a lot of client libraries, and we managed to work out an easy way to sync all the data to our Unity project with a single cick in the editor.
At the earliest stage it’s always important to avoid reinventing the wheel as todays development skills are much more about the ability to solve problems by binding existing tools together to match the criteria, than to sit down and spend weeks for implementing something that already exists. The assembling process is similar to playing a game, so we’re already amusing ourselves during the making. Actually it is a lot of fun, and not just that: we’re collaborating in a very democrative way with the team, and that helps us to harness the creativity of each member that somehow always pushes us forward. The tools we’re using to collaborate also make our lives much easier. The list ranges from the obvious Google product stack, Slack, cloud data drive, issue tracking and our own editor, which is built around the graph database. We also have a custom made build server, that creates daily builds in the background and notifies every member upon build completion. This allows us to follow up about the latest developments without any hassle.
Most of us work remotely -we’re more comfortable to manage our time this way- and as we’re also spread across the country (even multiple countries), we use a broad range of collaboration tools, so we can deliver and even crunch occasionally like regular teams do, working under the same roof. There are times though, when it’s best to come together, as sometimes it’s more efficient to sort out creative problems in person.
- Péter
Thanks for your attention, folks!
Stay tuned and don't forget to spread the word:
https://store.steampowered.com/app/1084640/Chicken_Police/
Find our previous updates here:
https://steamcommunity.com/games/1084640/announcements/detail/1593626866163172456
https://steamcommunity.com/games/1084640/announcements/detail/1586870834670163962
https://steamcommunity.com/games/1084640/announcements/detail/1586870834659213636
https://steamcommunity.com/games/1084640/announcements/detail/1589121999170324421