Тёмная тема
- Alprog
- Модератор
Alprog
> Почему тогда Notepad не использует базу данных?
Юзер работает с одним тестовым файлом
Alprog
> Или Photoshop?
одним рисунком
причем тут это? клоун?
tac
Одной сценой.
Мы же уже это обсуждали. Назови мне хоть один игровой движок, на котором выпущена хотя бы одна игра, который сохраняет сцену в базу данных. Надо быть отмороженным, чтобы так делать.
Велосипедист тут ты со своими базами данными.
Alprog
> Одной сценой
вот это и странно ... сцена в отличии от текстового файла и изображения, не однородна - это не буквы в словах, и не пиксели в изображении
Alprog
> хоть один игровой движок
причем тут движок? у Юнити есть соответствующие проблемы как у движка, концептуально не преодолимые ... и те кто терял результаты своей работы из за такой работы "одной сценой" думаю всегда были довольны таким супер решением ...
но же говорим о другом даже, ты сделал движок в движке ! и мало того, что сделал, так еще думая, что у тебя там какая та аналогия со сценой ...
Никогда не слышал о таком термине как объектно-ориентированная декомпозиция? видимо нет, если у тебя представление работы со сценой как с одним целым.
Декомпозируй текст в слова, слова в символы, символы в биты и сохраняй все по отдельности в базу данных.
tac
> причем тут движок? у Юнити есть соответствующие проблемы как у движка, концептуально не преодолимые
Хорошо, я делаю неправильно. Юнити делает неправильно; Unreal, CryEngine, Defold — все идиоты. Хорошо.
Назови мне хоть одну компанию, хоть один движок, хоть одну игру, где сцены сохранялись бы в бд (кроме ссылок на свои велосипеды, конечно).
Неужели все-все дураки? И Кармак, и Свини, и Пранчкевичус? Неужели только tac во всей вселенной понял, что такое объектная база данных?
> те кто терял результаты своей работы из за такой работы "одной сценой" думаю всегда были довольны таким супер решением
Расскажи мне, как в твоей системе с бд будет реализовано:
— Откат локальных изменений сцены из системы контроля версий;
— Merge изменений, внесённых на одну и ту же сцену с разных компьютеров;
— Тестирование внесённых изменений с последующим откатом обратно;
— Функция «Save as…» с копированием сцены целиком;
— История изменений для Undo/Redo;
— Перенос сцены из одного проекта в другой.
Слушай, расскажи побольше про себя и свой опыт 20+. Мне прям интересно, как можно было столько лет заниматься программированием и остаться настолько невеждой?
И, что самое удивительное, упёртым. Тебе сколько лет-то вообще? Лет 40 же есть? Не стыдно совсем?
Alprog
> Назови мне хоть одну компанию, хоть один движок, хоть одну игру, где сцены
> сохранялись бы в бд (кроме ссылок на свои велосипеды, конечно).
Карта в майнкрафте считается за "сцену"?
Alprog
> Расскажи мне, как в твоей системе с бд будет реализовано:
> — Откат локальных изменений сцены из системы контроля версий;
> — Merge изменений, внесённых на одну и ту же сцену с разных компьютеров;
> — Тестирование внесённых изменений с последующим откатом обратно;
> — Функция «Save as…» с копированием сцены целиком;
> — История изменений для Undo/Redo;
> — Перенос сцены из одного проекта в другой.
В принципе, выглядит всё решаемо, в худшем случае велосипедированием версий поверх таблиц БД; вот только времени на прикручивание такого велосипеда к игродвижку уйдёт больше, чем суммарная выгода при дальнейшем использовании, вот никто из серьёзных дядек и не прикручивает.
Delfigamer
> Карта в майнкрафте считается за "сцену"?
Ой, там много. О чём там вкратце? Подозреваю, что речь идёт о том, чтобы сериализовать карту в json/бинарь и уже ПОТОМ записывать в базу по каким-то своим причинам.
> вот только времени на прикручивание такого велосипеда к игродвижку уйдёт больше, чем суммарная выгода при дальнейшем использовании
Начнём с того, что ни одной системой контроля версий пользоваться будет невозможно. Если БД реализовано в виде огромного бинаря, то мы за пару недель засрём git-репозиторий и LFS.
Если мы работаем в Perforce, то придётся ставить локи на всю базу целиком и тем самым останавливать работу всех остальных. SVN, mercurial? Тоже как-то не радужно там всё.
Придётся изобретать свою собственную систему контроля версий или вообще принципиально новый способ работы в команде изобретать. Не слишком ли круто?
Ради чего? Ради того, чтобы Ctrl+S отрабатывала не за 0.1, а за 0.09 секунды? Не бредятина ли?
Или это чтобы данные не терять? Не проще ли тогда просто бекапить содержимое в AppData периодически и при запуске после аварийного завершения предлагать восстановить из резервной копии?
По крайней мере такая практика существует у некоторых программ, и это явно лучше, чем городить целую инфраструктуру вокруг базы данных.
Alprog
> ни одной системой контроля версий пользоваться будет невозможно
видимо, что такое резервное копирование БД не слышал, да и про логи sql тоже
клоун, у БД и так есть контроль версий через журнал, для того кто в танке, она не нуждается в еще одном
Alprog
> Придётся изобретать свою собственную систему контроля версий или вообще
> принципиально новый способ работы в команде изобретать. Не слишком ли круто?
Ну я и говорю.
Delfigamer
> времени на прикручивание такого велосипеда к игродвижку уйдёт больше, чем
> суммарная выгода при дальнейшем использовании, вот никто из серьёзных дядек и
> не прикручивает
Alprog
> Ой, там много. О чём там вкратце? Подозреваю, что речь идёт о том, чтобы
> сериализовать карту в json/бинарь и уже ПОТОМ записывать в базу по каким-то
> своим причинам.
Вот, нашёл прямо описание.
Alprog
> Не проще ли тогда просто бекапить содержимое в AppData периодически
ага, сделай после окончания ввода свойства и т.п. атомарного действия пользователя .. поржем вместе как скоро юзер нах пошлет такой тормазнутый движок, запись сцены измеряется секундами, а не их долями ... впрочем и так Юнити не блещет в этом, а она лучше всех остальных
Alprog
> Неужели все-все дураки? И Кармак, и Свини, и Пранчкевичус? Неужели только tac
> во всей вселенной понял
сам в шоке :))
Delfigamer
> они не используют БД как БД, им просто была нужна своя файловая система
Как я и подозревал :)
tac
> клоун, у БД и так есть контроль версий через журнал, для того кто в танке, она не нуждается в еще одном
Какую систему контроля версий предполагается использовать для исходного кода и изображений? Каким образом осуществляется их синхронизация?
После того, как два человека поменяли каждый у себя на компьютере одни и те же записи в БД, какие действия они должны выполнить, чтобы смерджить изменения?
А если при этом менялся ещё и код и изображения?
> как скоро юзер нах пошлет такой тормазнутый движок
Сохранять необязательно синхронно.
> запись сцены измеряется секундами, а не их долями
Купи себе комп и SSD.
> сам в шоке :))
Никто так не делал, потому что это в принципе неюзабельное решение. Оно тянет за собой целые ряд не- или почти нерешаемых проблем.
Alprog
> два человека поменяли каждый у себя на компьютере одни и те же записи в БД
база данных одна :) в базе мерджить? совсем основ не знаешь?
Alprog
> Оно тянет за собой целые ряд не- или почти нерешаемых проблем.
все там решаемо .. другой вопрос, согласен, более трудоемко, но и более стабильно. Вопрос тут так сказать в кризисе роста, пока сцена однородна или небольшая, то и простое сохранение в файл будет норм, как только она становится структурирована, растут размеры или доступ становится не 'все или ничего' сразу приходится переделывать под бд ... ну и конечно, когда надо получать разные view /select/ с одних и тех же данных, это уже прямое указание, что на сериализации дальше не прокатишь, от слова совсем
а это наступает достаточно быстро, например если хранятся древообразная структура то еще норм, но как только появляется ситуация, что храним одно, например, связи вида ребенок имеет мать и отца, и надо показать такое родословное дерево, то для отображения уже нужен view над этими данными, и не очень простой, соединяющий в одну запись связь ребенок - отец - дед, и т.п. /это лишь пример как мало надо чтобы возникла необходимость во view над данными
tac
> база данных одна :)
Лоооооол.
Хорошо, а как же тогда быть в следующих ситуациях:
1. Вся команда работает над актуальной версией игры, а программист в течение дня откатывается на версию недельной давности, двух, трёх и т.д.,
экспериментируя с ними и пытаясь определить момент, когда тот или иной баг впервые появился. Как не мешать остальным при этом?
2. Три программиста работают каждый над своей объёмной задачей. Каждая задача занимает несколько дней и локальные изменения
каждого потенциально приводят к неработоспособности билда до тех пор, пока задача не будет решена. Как не мешать друг другу?
3. Главный программист поехал в Перу и хочет продолжать работать из гостиницы, но вай фай не пашет. Как работать?
Это реальные ситуации, возникающие постоянно. Ты вообще в команде работал когда-нибудь?
Тема в архиве.