Комментарии к статье

Методы контроля целостности ресурсной системы в процессе разработки игры

Системный программист проекта «Аллоды Онлайн» рассказывает о процессе наполнения ресурсной системы, а также о том, как помочь разработчикам в создании объектов, состоящих из десятков и сотен ресурсов.
+65
Отправлено 15.07.2010 в 11:55
Отвечает на сообщение 350381
+2
А как регулировались сложные коммиты? Я имею ввиду например работа одного человека переделать модельки домиков, другого - синхронизировать с изменениями скрипты, третьего - заменить домики на уровнях.. Ключевая проблема что по отдельности все эти коммиты нарушают целостность в любом порядке.
Отправлено 15.07.2010 в 13:36
Отвечает на сообщение 350382
+1
Могу предложить два варианта:
1. Уйти всем кто работает над связанным функционалом в отдельную ветку и потом смержить все одним коммитом в основную.
2. Передавать кому-то одному патчи изменений и коммитить от его лица.
Отправлено 15.07.2010 в 15:23
Отвечает на сообщение 350383
+1
Виталий Чибриков пишет:
>
> 1. Уйти всем кто работает над связанным функционалом в
> отдельную ветку и потом смержить все одним коммитом в
> основную.
> 2. Передавать кому-то одному патчи изменений и
> коммитить от его лица.


т.е. вы действительно их применяете?
Просто есть подозрение что 2 абстрактных дизайнера Васи не могут уйти в ветку - для них это абракадабра непосильная. И корректный патч перенести тоже. Интересует именно накопленный опыт - не было ну и ладно :)
Отправлено 15.07.2010 в 21:07
Отвечает на сообщение 350382
0
Антон Шеховцов пишет:
>
> А как регулировались сложные коммиты? Я имею ввиду
> например работа одного человека переделать модельки
> домиков, другого - синхронизировать с изменениями
> скрипты, третьего - заменить домики на уровнях..
> Ключевая проблема что по отдельности все эти коммиты
> нарушают целостность в любом порядке.


Такие сложные проверки бывают. Хук может проверить не только список измененных ресурсов, ему в общем-то доступны все ресурсы, которые уже лежат в репозитории.

Соответственно, можно сделать проверку, которая по diff поймет, что оно могло косвенно повлиять на другие ресурсы (неизмененные в этом diff) и сделать интегральную проверку. Тогда каждый следующий коммит будет гарантировать целостность.

Реальная проблема не в том, что это невозможно сделать, а в том, что такие проверки могут быть сложными и работать неприемлемо долго. Требуется скилл.
Отправлено 15.07.2010 в 13:41
Отвечает на сообщение 350381
0
Меня интересуют следующие вопросы вопросы:
1. Ресурсы связаны прямо, но как они связаны с кодом? т.е. внутри кода я имею константы прошитые или жду ID с сервера?
2. Чекаются ли связи из кода с ресурсами?
Отправлено 15.07.2010 в 14:09
Отвечает на сообщение 350385
0
1. У нас есть "рутовые" ресурсы - ресурсы на которые ссылается только код (прошитые контстанты).
Таких ресурсов не очень много и они под контролем программистов.
2. Связь кода и данных мы проверяем коммит-хуками только во время коммита данных. Если коммит кода нарушил целостность ресурсной системы мы узнаем об этом из регулярных проверок на билдерах и от тестировщиков.
Отправлено 15.07.2010 в 20:09
Отвечает на сообщение 350381
0
К сожалению, система коммит-хуков борется только со следствиями, она не может предотвратить баги. Поэтому, я думаю, что такая система, по-хорошему, должна работать в процессе работы над ресурсом. Т.е. "Простые проверки", "Проверки над версией", "Работа с метаинформацией" это лучше было бы прикрутить к редакторам ресурсов. Это было бы намного полезней.

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

Вы действительно с таким сталкивались в процессе работы над проектом?
Отправлено 15.07.2010 в 20:54
Отвечает на сообщение 350408
0
Nikolai Lisun пишет:
>
> К сожалению, система коммит-хуков борется только со
> следствиями, она не может предотвратить баги.


Она их именно предотвращает. Хук блокирует коммит с багом и не дает попасть ему в репозиторий.
Отправлено 15.07.2010 в 21:36
Отвечает на сообщение 350412
0
Тимур Бухараев пишет:
>
> Nikolai Lisun пишет:
> >
> > К сожалению, система коммит-хуков борется только со
> > следствиями, она не может предотвратить баги.
>
> Она их именно предотвращает. Хук блокирует коммит с
> багом и не дает попасть ему в репозиторий.


Она не дает в репозиторий залить неправильный данные. Я же говорю про то, что бы она не давала бы сделать баг разработчику.
Антон Шеховцов  15.07.2010 21:50
Nikolai Lisun  16.07.2010 00:38
Антон Шеховцов  16.07.2010 10:02
В ветке ещё 2 сообщения
Тимур Бухараев  15.07.2010 22:21
Nikolai Lisun  16.07.2010 01:05
Тимур Бухараев  16.07.2010 12:58
Владимир Егоров  16.07.2010 13:30
Отправлено 15.07.2010 в 21:06
Отвечает на сообщение 350408
0
> Поэтому, я думаю, что такая система, по-хорошему, должна
> работать в процессе работы над ресурсом. Т.е. "Простые
> проверки", "Проверки над версией", "Работа с
> метаинформацией" это лучше было бы прикрутить к
> редакторам ресурсов. Это было бы намного полезней.


Это как раз то, над чем мы работаем сейчас :р)
Проверки над версией невозможны без учета изменений, которые сделали остальные разработчики. А значит надо сделать редакторам доступ к собранной хуками метаинформации. Если добьемся успеха - напишу что и как получилось.

У вас есть опыт создания подобной системы?
Порекомендуете, что посмотреть, почитать?
Отправлено 15.07.2010 в 23:42
Отвечает на сообщение 350413
-3
Виталий Чибриков пишет:
>
> Это как раз то, над чем мы работаем сейчас :р)
> Проверки над версией невозможны без учета изменений,
> которые сделали остальные разработчики. А значит надо
> сделать редакторам доступ к собранной хуками
> метаинформации. Если добьемся успеха - напишу что и как
> получилось.
>
> У вас есть опыт создания подобной системы?
> Порекомендуете, что посмотреть, почитать?


Я видел и работал с разными системами (специфика моей работы такая), принимал участие в разработке одной подобной системы. Так что опыт есть. )

Успеха вы естественно добьетесь, т.к. задача не самая сложная. И я даже могу попытаться угадать во что превратиться ваша система. Во всяком случае, svn с коммит-хуками вам вряд ли нужен будет.
Отправлено 17.07.2010 в 09:42
Отвечает на сообщение 350381
+1
О, прикольно. Уже пол года в Аллодах не работаю а вижу свою фамилию в статье. Было приятно, спасибо Виталик :) Я бы с удовольствием зашел к вам по флеймить если бы не нежно было для этого лететь 6500 км до Москвы :(
Отправлено 18.07.2010 в 00:21
Отвечает на сообщение 350498
+1
Дмитрий Сидоренко пишет:
>
> О, прикольно. Уже пол года в Аллодах не работаю а вижу
> свою фамилию в статье. Было приятно, спасибо Виталик :)
> Я бы с удовольствием зашел к вам по флеймить если бы не
> нежно было для этого лететь 6500 км до Москвы :(


Ага, будет возможность, заходи.
Заодно и паяльник тебе верну :)
Отправлено 19.07.2010 в 15:16
Отвечает на сообщение 350514
+6
Тимур Бухараев пишет:
> Заодно и паяльник тебе верну :)


Теперь понятно, каким образом у вас разработчиков стимулируют баги фиксить :)
Отправлено 20.07.2010 в 16:36
Отвечает на сообщение 350498
0
Дмитрий Сидоренко пишет:

> О, прикольно. Уже пол года в Аллодах не работаю а вижу
> свою фамилию в статье.


Угу. Я тоже, только после упоминания в этой статье, просмотрел доклад с КРИ про Аллодную ресурсную систему и кодоген. В общем все очень знакомо и созвучно пройденному опыту как-то :)

Только вопрос: а почему все фигурирует в контексте ММО? Вроде обе статьи справедливы для любой игры.
Отправлено 21.07.2010 в 11:47
Отвечает на сообщение 350592
+3
Я бы не сказал что для любой. Вот я сейчас делаю онлайн игру гораздо меньщих масштабов чем Аллоды и тут не все это нужно что описано в статье. Вот если у Вас техпроцесс как в Аллодах - аутсорсеры, внешние студии и и.д. то это нужно. А если вы делаете игру для мобильного телефона из 3 левелов то вам вообще ничего этого не нужно. Все от масштаба зависит.
Comments
Списки доступа
  • Подписчики [581]
  • Черный список [2]
Права доступа
Вы можете читать группу, но не можете отвечать на сообщения и создавать новые темы.
Доступ для остальных:
анонимы : могут читать
новые : полный доступ
постоянные : полный доступ

Copyright © 2017 ООО "ДТФ.РУ". Все права защищены.

Воспроизведение материалов или их частей в любом виде и форме без письменного согласия запрещено.

Замечания и предложения отправляйте через форму обратной связи.

Пользовательское соглашение