Development Diary. Part 2 (Patreon)

Winner of the giveaway is: lHavikl

And now, as promised, a “few” words from our coders.

Andy is currently not only the developer of our game, but also one of the developers for the RenPy engine, on which numerous visual novels have and are being written.

He himself will the writing the next part about our game development:

Hi everyone, this is Andy. On the Crab team, I'm the core developer, so usually you would only see my work when things don't go as planned. The main part of my work is to create tools (mechanics) that allow the graphics to be alive and the game world to be interactive, and so that separate mechanics remain relatively untangled, so that when we change one thing it doesn’t cause a break in seemingly unrelated part of the game, which would cause the overall development speed to go down.

Unfortunately, over the course of 3 years, certain errors in the architecture were made, and a certain amount of so-called technical debt had been accumulated, which causes delays in releases due to zombie bugs for the last six months (previously fixed bugs came to life again), and some bugs remained in the game for more than half a year. In addition, the language we use (Ren'Py) is geared towards creating visual novels, i.e. games with a linear (and/or branching) storyline, and for the last year and a half, the game has been increasingly moving away from such linear structure, turning into more of a quest-oriented game.

In this regard, we made a decision to fix all this in one big update. For this, during this year, in parallel with the main work on the game, I made a modified version of Ren'Py, more aligned with our needs. After this was finished, the main problem is that we already have all the game code (almost half a million lines) written in the original Ren'Py, and since the update is all or nothing, it takes quite a long time.

But after the full transition to the new engine, many bugs will just disappear, and the further development should be simplified.

In addition, as noted before, I became one of the developers for Ren'Py itself, so I have spent quite a lot of time lately helping to release the next big Ren'Py update, version 7.4. The main benefit of this update is the migration to GL2 (OpenGL 4.2, DirectX 11 and OpenGL ES 3). Without going into too much into technical details, it speeds up the rendering of graphics, in some cases by orders of magnitude. This is most noticeable during transitions between scenes and the speed of interaction with the interface. Unfortunately, for the most efficient operation of GL2, we will stop supporting 32 bit systems and move to 64 bits.

Also thanks to GL2, Ren'Py now will have the ability to use Live2D properly, unlike the workaround way, which you saw in the animation releases. A simple example, the current animation of the main menu with Daphne and Parallax requires 4GB of RAM for proper operation, the same Live2D animation will only require 300 MB, which means that they will work on Android, and because of GL2, loading and rendering of them will happen almost instantly. Beyond that, Live2D is a very flexible tool. Together with Parasitius, we will sure to make you happy.

And now a few words about the future. At the moment, this is not fully implemented, but my ultimate goal is to make the versions backward compatible, so that you can load saves from previous versions, the game will transfer the progress of all quests that have not changed, and only the modified ones will be reset.

Speaking of Ren'Py, the next update is planned it to move to Python 3. This will also simplify development, but more importantly, benchmarks show that even without py2to3 optimizations, a simple switch to py3 reduces RAM consumption by about 30%, and the execution speeds increase by about 40%.

Benq is responsible for a very painstaking part of the development - dealing with our Patrons’ problems (such as, issues with downloads or problems with the save files), fixing bugs and adding content into the game. But if you think that he only works on fixes, mends and inserts, then you are mistaken. Benq is also an ideas generator, about which in more details from the man himself:

So what exactly do I do for the game? It is difficult to give an unambiguous answer to this question, since the range of such activities is quite wide, ranging from user support in Discord to drawing up technical specifications for artists for a newly invented event. Overall, I try to do everything in my power to improve the players’ interactions with the game in all aspects.

For an example, I will briefly describe one of the aspects of the game development - the creation of an event and art for it, from the birth of an idea all the way to the moment that idea becomes an event in the game.

So where does it all start? Some might say that it would be great to come up with all the events in advance and then just add them to the game, adjusting along the way. In part I agree with this sentiment. However, we all know that things rarely go as planned. Which is the case for game development. Of course there is a pre-planned scenario for the main plot, but most of the secondary events, such as mini-games and side quests, are added during development. More so, just so happens to be that some events are added to the chapters for which the main development had already been completed. By the way, this is one of the reasons for incompatible save files, retrospective content addition simply does not allow this.

So, in the course of the development, an idea arises, “Wouldn’t it be nice to add here some interactions between Hermione and Marcus, that would feed into the plot!” But, would that really be the case?

Before we start doing anything, there is a few things to consider:

1.  Does is it break the logic of the story?

2.  Does is it break the gradual corruption of the characters?

3.  How well would it fit into the world?

4.  What value (if any) will it have for the player (Just fan service or something more)?

5.  And other numerous aspects, such as the presence of TS and the complexity of the art in general.

Let's say an idea is so ingenious that it meets all of the possible requirements from the very beginning (Which pretty much never happens in real life, and you need to polish, discuss and document the idea until it meets most of the requirements). Great, now you can write the code, draw art, and presto manifesto, you get something to enjoy! Shouldn’t be too complicated?... Well, that’s at least the general principle, however let's take a closer look at this process.

The code can be written quickly using the so-called "spaghetti" method, or you can follow the lengthy process of properly integrating a new module into the overarching architecture properly. If you choose the first, faster method, the spaghetti of it all will accumulate and then you will spend a huge amount of time untangling this very code for any global change you make, what’s worse even seemingly small changes will cause errors in absolutely unexpected parts of the code. Therefore, in most cases, the second, longer method of coding is preferred, which obviously affects the development speed. Plus, no one should forget about general conventions for code formatting and writing at least minimal documentation.

As for the art creation, it is somewhat simpler, however, there are some pitfalls. To start, artists need a detailed description of what is required of them, since they cannot just see into screenwriters mind to draw what the latter have imagined. For example, try to imagine any game character in your mind, and then try to describe it to someone so that he can accurately capture it and at least come up with a sketch. More than likely, this sketch will only partially resemble what you have wanted to see. This leads to art going through several rounds of adjustments and edits in order to fully capture the idea for the event, it really does take a thousand words to paint a picture. Even after all that, the art may still need some edits as the event is being added into the game, as some new ideas may arise for the interactions between characters.

Hooray! The code is ready, art too and all that is already included into the base game. Time to move to the next task?... Unfortunately, no!

Before moving to a different task, the event needs to be tested. Here you can argue that since you yourself made this event, then you really should know how it should work, and accordingly you yourself can test it best and faster than anyone else. And that would be the case. However knowing how the event works does not allow you to comprehensively test it. It is often very difficult to come up every way to perform all the actions in any event, so as to test all the scenarios for it (especially if you know how the event is intended to work). For example, the use of certain items from the inventory at one time or another, or a combination of several events with each other. In this case, testers come to the rescue. Each of them goes through the event several times, trying to break it, after which testers write all of their observations into the Trello cards. Each card is a detected problem. After the discovered problems are corrected, the fixes are tested and corrected again, and so on and so on, until everything works as intended at least 80% of the time. And we finally get an event that (more or less) works (but that does not mean that there are no bugs left, usually finding all bugs is impossible).

Now you can finally move on and forget about this event? ... Yes! To start this whole process from scratch once again! As a bonus, from time to time even the well-tested and fully implemented events will require additional testing, once some global mechanics are changed or introduced.

Whew... In general, this is how the process of adding new things to the game goes. Naturally, I did not mention more specific points, so as to not drag this overview for another 5 pages, believe me this is far from all that happens behind the scenes. And this is just one aspect of the development. Constant bug fixing, reworks and balancing of existent mechanics, collecting feedback from players and creating tasks based on it, management outsourcing, etc... All in all, fun never stops!

In the end, I would like to thank you for all of your support and criticisms, without all of you this game would not exist. See you on Discord!

Победитель раздачи: lHavikl

А теперь, как и обещали, пара слов от наших кодеров.

Andy - в данный момент не только разработчик нашей игры, но один из разработчиков движка ренпи, на котором написаны многочисленные визуальные новеллы.

Подробнее о разработке игры расскажет он сам:

Всем привет, это Энди. В команде крабов я являюсь разработчиком ядра игры, так что вы видите мою работу только если что-то идёт не по плану. Основным смыслом моей работы является создание инструментов (механик) которые позволяют графике быть живой и миру игры интерактивным, причём так, чтобы вещи не запутывались друг с другом, чтобы изменения одних вещей не ломало другие и скорость разработки из-за этого не снижалась.

К сожалению, за 3 года были допущены определенные ошибки в архитектуре, а также накопилось некоторое количество технического долга, что вызывало последние полгода задержки с выпусками из-за зомби-багов (ранее исправленные баги оживали вновь), а некоторые баги висят неисправленными больше полугода. Помимо этого, язык который мы используем (Ren’Py) заточен на создание визуальных новелл, т.е. игр с линейным (и/или разветвляющимся) сюжетом, а последние полтора года игра всё больше уходит от линейного сюжета, превращаясь в квест-ориентированную игру.

В связи с этим нами было принято решение одним большим обновлением исправить всё это. Для этого я в течении этого года параллельно с основной работой над игрой сделал модифицированную версию Ren’Py подходящую под наши условия. После того как это было закончено, основная проблема заключается в том, что мы уже имеем весь код игры (почти полмиллиона строк) сделанный на оригинальном Ren’Py, а обновление идёт в виде всё или ничего, что занимает достаточно много времени.

Но после полного перехода на использование нового движка одномоментно исчезнут многие баги, и разработка игры должна упроститься.

Помимо этого, как было замечено, я стал одним из разработчиков Ren’Py как такового, так что довольно много времени в последнее время я потратил на помощь в выходе следующего большого обновления Ren’Py, версия 7.4. Главным преимуществом этого обновления является переход на GL2 (OpenGL 4.2, DirectX 11 и OpenGL ES 3). Не вдаваясь в технические детали, это ускоряет рендер графики, в некоторых случаях на порядки. Наиболее заметно это при переходах между сценами и скорости взаимодействия с интерфейсом. К сожалению для максимально эффективной работы GL2 мы прекратим поддержку 32 битных систем и перейдём на 64 бита.

Также благодаря GL2 в Ren’Py появилась возможность использовать Live2D как таковой, а не то что вы видели в релизах с анимациями. Простой пример, текущая анимация главного меню с дафной и параллаксом, для корректной работы требует 4GB видеопамяти, та же самая Live2D анимация требует только 300 MB видеопамяти, что означает что они станут доступны даже на Android, причем из-за GL2 загрузка и  рендер такой модели происходит почти мгновенно. Но помимо этого Live2D это очень гибкий инструмент. Вместе с Parasitius мы еще порадуем вас.

Ну и пара слов о будущем. В данный момент это не реализовано полностью, но моей конечной задачей является сделать обратную совместимость версий, так что вы сможете загружать сохранения от прошлых версий, игра будет переносить прогресс всех квестовых линий которые не изменились, а изменившиеся будут сбрасываться.

Говоря о Ren’Py, следующим обновлением планируется его обновление на использование Python 3. Это также упростит разработку, но самое главное, бенчмарки показывают что даже без py2to3 оптимизаций, простой переход на py3 уменьшает потребление оперативной памяти примерно на 30%, а скорость выполнения увеличивает примерно на 40%.

Benq - занимается очень кропотливой работой, а именно связями с проблемами патронов (не могут скачать или проблемы с сейв файлом), починкой багов и вставкой контента в игру. Если вы думаете, что он только и делает, что чинит и чинит, что-то вставляет, то вы ошибаетесь. Benq - генератор идей, более подробно он напишет о своей работе сам:

Итак, что же конкретно я делаю для игры? На этот вопрос сложно дать однозначный ответ, так как спектр деятельности очень широк, начиная от поддержки пользователей в Discord, и заканчивая составлением ТЗ художникам для только что придуманного эвента. В целом, я пытаюсь делать все, что в моих силах, чтобы улучшить взаимодействие игрока с игрой во всех аспектах.

Далее для примера кратко опишу один из аспектов разработки игры - создание эвента и арта к нему, начиная с идеи и заканчивания конечной реализацией в игре.

С чего же начинается создание события в игре? Кто-то скажет, что неплохо было бы прописать все события заранее, а потом просто добавлять их в игру, попутно корректируя. И отчасти, я согласен с таким подходом. Однако, все мы знаем, что очень редко дела идут так, как мы их запланировали. Так же происходит и у нас. Конечно же, для основного сюжета имеется заранее продуманный сценарий, но все второстепенные эвенты, такие как мини-игры и побочные задания, можно сказать, добавляются по ходу разработки. Часто бывает так, что эвенты могут добавляться в те главы, над которыми основная разработка уже была закончена. Кстати, это один из аспектов, который не позволяет сделать стабильный перенос сохранений из предыдущей версии в следующую, ретроспективное добавление контента этого просто не позволяет.

Итак, по ходу разработки возникает идея, “а вот тут неплохо было бы сделать взаимодействие Гермионы и Маркуса, отлично бы вписалось в сюжет!”. Но так ли это на самом деле?

Прежде чем начинать что-либо делать, нужно убедиться, что данное событие:

1. не ломает логику повествования,
2. не нарушает постепенное развращение персонажей,
3. в целом вписывается в игровой мир,
4. имеет ценность для игрока (наличие контента или просто фан-сервис),
5. другие аспекты, типа наличия ТЗ и сложности арта в целом.

Допустим, идея настолько гениальная, что она отвечает всем этим требованиям с самого начала (зачастую происходит обратное, и нужно полировать, обсуждать и документировать идею до того момента, пока она не станет удовлетворять большинству требований). Отлично, можно писать код, рисовать арт и дело в шляпе! Ведь так?.. В принципе, так то оно так, но давайте разберем написание кода и арта чуть подробнее.

Код можно написать быстро, используя т.н. метод “спагетти”, либо же писать его долго, продумывая структуру и взаимодействие с другими модулями. Если выбирать первый, более быстрый способ, то постепенно такой код будет накапливаться и потом можно потратить огромное количество времени, исправляя этот самый код после того, как в игру вводятся какие-то глобальные изменения. Поэтому в большинстве случаев выбирается второй, более долгий метод написания кода, и это сказывается на скорости разработки. Плюс, никто не отменял соблюдение конвенций по форматированию кода и написанию минимальной документации.

Что касается создания арта, тут несколько проще, однако и тут есть свои подводные камни. Для начала, художникам нужно очень подробно описать то, что от них требуется, так как они не знают всех деталей, которые знают сценаристы, и они не могут прочитать их мысли, чтобы нарисовать именно так, как это видят у себя в голове другие люди. Для эксперимента, попробуйте представить персонажа игры у себя в голове, а потом описать это другому человеку так, чтобы он в точности мог запечатлеть это хотя бы на скетче. С большой вероятностью, этот набросок будет только частично напоминать то, что вы хотели увидеть. Это приводит к тому, что созданный арт проходит несколько этапов корректировок и правок, чтобы полностью соответствовать задуманному в событии и отображать именно то, что нужно. И даже после этого, арт может дополняться по ходу введения события в игру, так как могут возникнуть новые идеи для взаимодействия персонажей.

Ура! Код готов, арт нарисован и вставлен в игру. Наконец-то можно переходить к следующему заданию?.. А вот и нет!

Прежде чем переключиться на другую задачу, эвент нужно протестировать. Тут можно возразить, что, раз ты сам сделал этот эвент, значит ты знаешь, как он должен работать, и соответственно ты сам сможешь протестировать его лучше и быстрее, чем кто-либо другой. И это действительно так. Но знание того, как работает эвент, как раз и не позволяет полноценно его протестировать. Зачастую, очень сложно придумать разные способы выполнения действий в эвенте так, чтобы проверить как можно больше вариантов развития событий (учитывая, что ты точно знаешь, как работает эвент и что в нем нужно делать). Такие события - это, например, применение определенных вещей из инвентаря в тот или иной момент, или же комбинация нескольких событий друг с другом. В этом случае, на помощь приходят тестеры. Каждый из них проходит эвент по нескольку раз, пытаясь его сломать, и все свои наблюдения тестер записывает в карточки Trello. Каждая карточка - это найденная проблема. После чего данные проблемы исправляются, исправления снова тестируются и исправляются, и так далее, пока все не будет работать хотя бы на 80% И мы, наконец, получаем эвент, который (более-менее) работает (но это не значит, что там не осталось багов, обычно найти абсолютно все баги - невозможно).

Ну уж теперь то можно переходить дальше и забыть уже наконец про этот эвент?.. Да! И начинать весь процесс с начала для следующего эвента. А бонусом является то, что периодически даже уже проверенные и полностью введенные эвенты нужно тестировать заново, так как могут изменяться глобальные механики игры.

Фух… В общем, примерно так происходит процесс добавления новых вещей в игру. Естественно, я не упоминал некоторые моменты, чтобы не перегружать читателя, но поверьте, это далеко не все, что происходит за кулисами. И это лишь один аспект разработки. Ещё есть постоянное исправление багов, переработка и баланс текущих механик, сбор фидбека от игроков и создание задач на его основе, менеджмент аутсорса, и тд и тп. В общем, весело у нас!

Напоследок, хотел бы поблагодарить вас за вашу поддержку и критику, без вас этой игры бы не было. До встречи в Discord!