Нужны советы по разработке игр

Здравствуйте,Я давно мечтаю создавать свои онлайн игры, Сейчас освоил базу си, покопавшись в нем понял что игр хороших на нем не слепишь, ни один день скитаюсь по форумам, читаю статьи и Решил. Начну изучать C++. Я знаю что разработка игр это нелегко и мне много чего нужно узнать, Я не знаю с чего начать. Сейчас любой совет на вес золота.
А больше мне нравится кодить и придумывать сценарий. Для моих будущих игр я уже придумал частичто свою историю.
Может это и покажется странным, но когда я смотрю прохождение игр, у меня включается во мне разработчик, и я начинаю думать с точки зрения разработчика. Как какая то механика могла быть реализована в коде.

Вобщем Буду очень благодарен вашим Любым полезным советам!

0

Сообщение от Fulcrum_013 Требует эпизодических знаний того что изучают на первых двух курсах универа.

На первых двух курсах универа изучают научные статьи по графике? Это где, например?

0

Сообщение от Jzx На первых двух курсах универа изучают научные статьи по графике? Это где, например?

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

0

Сообщение от Jzx Это где, например?

например в курсе под названием "Вычислительная геометрия" - аккурат второй курс. И вот в свете этого очень странно звучит рекомендация "написть свой софтверный растеризатор" - реально это набор лаб первой половины оного курса. А еще страннее звучит

В первую очередь сосредоточьте внимание именно на прикладной математике

Как бы у квалифицированного программиста именно это в дипломе написано - специалист прикладной математики.

Добавлено через 7 минут
Так что советы там для неквалифицированных горе-кодеров, хотя в общем то в правильном русле.

0

Сообщение от Fulcrum_013 Как бы у квалифицированного программиста именно это в дипломе написано - специалист прикладной математики.

Необязательно.

0

New man, Ну раньше "информатики" писали в скобках после "и вычислительной техники" а теперь наоборот пишут - информатики а в скобках "прикладной математики и вычислительной техники".
Ну а вобще программистов как готовили спецами именно по прикладной математике так и готовят даже если название как то поменяли. Что у нас что у них программа примерно одинаковая и примерно та же что и 40 лет назад. Потому что в разработке матобеспечения ЭВМ без прикладной математики ловить нечего по определению.

0

Сообщение от Fulcrum_013 На этапе реализации парсера плюсов и завершения постановки задачи для редактора моделей и системы предсказания коллизий.

Зачем, если можно сделать на Lua?
Ну, бизнес-логику (код геймплея) не стоит писать на плюсах, ведь из геймдизайнеров плюсы не знает почти никто.

0

Сообщение от New man Зачем, если можно сделать на Lua?

Зачем там всякие примитивные тормозисторы если все это можно делать на плюсах?
При этом еще раз для особо одаренных - парсер нужен для автоматического получения таблиц RTTI. Без них никуда ничего автоматически не привяжется, в том числе и объекты к их скриптовым оберткам.

Сообщение от New man Ну, бизнес-логику (код геймплея) не стоит писать на плюсах, ведь из геймдизайнеров плюсы не знает почти никто.

А никто и не говорит что эта штука будет предназначена для использования быдлокодерами. Доверять разработку моделей поведения повреждений и т.д. людям которые не отбивают дупля даже в основах профессии - ну более идиотскую идею придумать сложно.

0

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

Сообщение от Fulcrum_013 Зачем там всякие примитивные тормозисторы если все это можно делать на плюсах?

1) Чтобы было быстрее разрабатывать;
2) чтобы было меньше возможностей выстрелить себе в ногу;
3) чтобы не писать кучу мусорного кода, которую нужно писать на плюсах (выделение-удаление памяти, например);
4) а почему Lua должен тормозить? Профилировщик наш друг и товарищ, да и плохой алгоритм от того, что он написан на C++, а не Lua, сильно быстрее не станет.

Добавлено через 3 минуты
Конечно, код графического рендера, расчёты коллизий и т.п. должно быть на языке вроде C++, конечно, но часть кода удобнее писать на чём-то вроде Lua или даже декларативно.

0

Сообщение от New man я к тому, что далеко не весь код пишется программистами. И некоторые вещи в играх делают лучше непрограммисты.

Ага. А типа кухарка операции на сердце делает лучше кардиохирурга.

Сообщение от New man И да, хорошие программисты очень большая редкость и они очень дороги, даже если найдутся.

Чем дороже стоит программист тем дешевле он обходится для компании. (с) Билл Гейтс.

Сообщение от New man Чтобы было быстрее разрабатывать;

Вы всерьез считаете что разработка на примитивных быдлоскриптах может быть быстрее чем на высокоуровневых языках профи-уровня?

Сообщение от New man чтобы было меньше возможностей выстрелить себе в ногу;

Это точно не про скрипты. И тем более не про GC. Это реалтайм. Так что все эти скриптошняги не что иное как миниган аккуратно нацеленный в ногу с запущенным таймером спуска.

Сообщение от New man чтобы не писать кучу мусорного кода, которую нужно писать на плюсах (выделение-удаление памяти, например);

Вы ничего не перепутали? Это GC не способен производить автоматическую уборку в графах ссылок характерных современным ООП паттернам (особенно смеси паттернов композит (коей и есть на самом деле ентитит систем) обсервер и лигхтвеигхт характерными для самоуправляемых иерархий объектов) и требует рукописного кода разрыва взаимосвязей. А С++ обеспечивает полную автоматику в этом плане минимумом библиотечного кода. Вообще ручной вызов delete пользуется исключительно под капотом смартпоинтеров, что позволяет строить автоматы подходящие к любому графу ссылок используемому в ООП и при этом не требующие трассировки ссылок на рут. GC не есть какая то новая технология. Это анахронизм созданный в 50-х для примитивных задач которые в наше время практически не встречаются. А С++ это первый ООП язык которому удалось успешно избавится от этого анахронизма.

Сообщение от New man а почему Lua должен тормозить?

Потому что во скриптовый код имеет квадратичное время выполнения по сравнению с нативным. Плюс еще GC который вообще не при делах постоянно граф ссылок перелопачивать вынужден.

Сообщение от New man да и плохой алгоритм от того, что он написан на C++, а не Lua, сильно быстрее не станет

Для того чтобы писать алгоритмы хорошо нужно понимать их математический бэкграунд и вообще принципы проектирования алгоритмов. Люди которые в теме всего этого плюсы знают априори. Потому что плюсы учат 1 семестр на первом курсе, а все это - все 5 лет универа.

Добавлено через 4 минуты

Сообщение от New man но часть кода удобнее писать на чём-то вроде Lua или даже декларативно.

Не вот просто интересно откуда такие вот мифы о том что примитивные языки,имеющие средств создания абстракций уровня начала 60-х, могут быть продуктивнее профессиональных языков имеющих самые высоко развитые средства создания абстракций? Или вы продуктивность в строках меряете?

Добавлено через 1 час 24 минуты

Сообщение от New man но часть кода удобнее писать на чём-то вроде Lua или даже декларативно

То что нужно делать декларативно кодом находится на самом нижнем уровне библиотек. А то что можно делать декларативно в плане сборки готоых компонентов нужно делать вообще без кода дата-драйвен методами и визуальной разработкой. Ни там нм там места для скриптов нету в принципе.

0

Сообщение от Fulcrum_013 Ага. А типа кухарка операции на сердце делает лучше кардиохирурга.

Плохое сравнение. От геймдизайнера требуется править баланс, продумывать UX, делать так, чтобы в игру было интересно играть. По моим наблюдениям, очень редкие программисты такое умеют, наш мозг заточен больше на то, чтобы делать программы быстрыми, поддерживаемыми, но привычное для программиста взаимодействие с компьютером для нормального пользователя — пытка.

Сообщение от Fulcrum_013 Чем дороже стоит программист тем дешевле он обходится для компании. (с) Билл Гейтс.

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

И да, почему бы просто не взять и воспользоваться трудом профессионалов, которым успешно пользуется вся индустрия? Я про интерпретаторы/ВМ/компиляторы более высокоуровневых языков, которые были написаны и проверены кучей профессионалов.

Сообщение от Fulcrum_013 Это GC не способен производить автоматическую уборку в графах ссылок характерных современным ООП паттернам (особенно смеси паттернов композит (коей и есть на самом деле ентитит систем) обсервер и лигхтвеигхт характерными для самоуправляемых иерархий объектов) и требует рукописного кода разрыва взаимосвязей. А С++ обеспечивает полную автоматику в этом плане минимумом библиотечного кода. Вообще ручной вызов delete пользуется исключительно под капотом смартпоинтеров, что позволяет строить автоматы подходящие к любому графу ссылок используемому в ООП и при этом не требующие трассировки ссылок на рут.

Эм? Какие проблемы для GC? Ни разу не встречался с ними в C#.
А с умными указателями любой циклический граф ссылок утечёт, если вручную его не разорвать weak_ptr. Лишняя работа.

Сообщение от Fulcrum_013 Это анахронизм созданный в 50-х для примитивных задач которые в наше время практически не встречаются

Правильно я понимаю, что чем сложнее задача, тем проще её писать?

Сообщение от Fulcrum_013 Потому что во скриптовый код имеет квадратичное время выполнения по сравнению с нативным. Плюс еще GC который вообще не при делах постоянно граф ссылок перелопачивать вынужден.

Квадратичное относительно чего?

Сообщение от Fulcrum_013 Для того чтобы писать алгоритмы хорошо нужно понимать их математический бэкграунд и вообще принципы проектирования алгоритмов. Люди которые в теме всего этого плюсы знают априори. Потому что плюсы учат 1 семестр на первом курсе, а все это - все 5 лет универа.

За один семестр плюсы на должном уровне не выучить. Да и за пять лет универа они прекрасно забудутся, если писать на чём-то другом. Я вот любой язык забываю за полгода, если не пишу на нём постоянно. Вот был у меня в универе семестр F# и два семестра Java, но сейчас я ничего не напишу на них без повторения основ (пусть и быстрого).
А математический бекграунд одинаково применяется и на Python, и на C. Можно просто посмотреть топов на всяких хакерранках: там часто питонисты спокойно соседствуют с плюсовиками.

Сообщение от Fulcrum_013 Не вот просто интересно откуда такие вот мифы о том что примитивные языки,имеющие средств создания абстракций уровня начала 60-х, могут быть продуктивнее профессиональных языков имеющих самые высоко развитые средства создания абстракций? Или вы продуктивность в строках меряете?

Можно измерять в time to market. Вот есть фича, которую можно написать за день на шарпах и за пять на C++. Угадай, что выберет владелец компании и игроки.
Ещё можно вспомнить время на поиск багов. Что быстрее: просмотреть 50 строк в одном файле на Python или 500 на C++?
Да и про примитивность интересно. Рефлексия из коробки, юнит-тесты из коробки, сборщик мусора и синтаксический сахар вроде асинхронных функций или propery не считаются? Я уж не говорю про всякие jit и т.п., при помощи которых всё это получается даже не слишком накладным.

Сообщение от Fulcrum_013 То что нужно делать декларативно кодом находится на самом нижнем уровне библиотек. А то что можно делать декларативно в плане сборки готоых компонентов нужно делать вообще без кода дата-драйвен методами и визуальной разработкой. Ни там нм там места для скриптов нету в принципе.

Да-да, только вот именно благодаря скриптам можно создавать моды, которые очень сильно повышают ретенш игроков и очень сильно увеличивают количество контента в игре бесплатно для разработчиков. Стоит посмотреть на TES, игры от Paradox Interactive, Warcraft (можно вспомнить карту DotA), везде эти скрипты очень были кстати для мододелов. Или все, кто делают моды, тоже должны пять лет в техническом универе просидеть?

0

Сообщение от New man Я уж не говорю про всякие jit и т.п., при помощи которых всё это получается даже не слишком накладным.

Вот как раз за счет JIT и GC все это тормозит.

Сообщение от New man Квадратичное относительно чего?

относительно времени выполнения нативного кода.

Сообщение от New man Эм? Какие проблемы для GC? Ни разу не встречался с ними в C#.

Гигантская с ним проблема. Понятие мусор которое для GC абсолютно не совпадает с правилами ненужности объектов по реалиям задачи. Соответственно эти правила объясняются GC вручную каждый раз для каждого объекта. В плюсах один раз и библиотечно, при этом трассировки от рута не требуют.

Добавлено через 1 минуту

Сообщение от New man А с умными указателями любой циклический граф ссылок утечёт, если вручную его не разорвать weak_ptr. Лишняя работа.

А при чем тут вобще искоробочные смартпоинтеры которые имитируют GC, до смартпоинтеров вообще? Есть и более продвинутые концепции и т.д. которые справляются с тем с чем GC справится не в состоянии.

Добавлено через 4 минуты

Сообщение от New man Правильно я понимаю, что чем сложнее задача, тем проще её писать?

Вы это о чем вообще?

Добавлено через 3 минуты

Сообщение от New man Вот есть фича, которую можно написать за день на шарпах и за пять на C++

Таких фич не существует.

Добавлено через 5 минут

Сообщение от New man Да и про примитивность интересно.

Средства создания высокоуровневых абстракций отсутсвуют.

Добавлено через 57 секунд

Сообщение от New man юнит-тесты из коробки

юнит-тесты используют только те кто в разработке софта вообще нифига не смыслят.

Добавлено через 1 минуту

Сообщение от New man Или все, кто делают моды, тоже должны пять лет в техническом универе просидеть?

А что они вообще могут сделать в плане поведения ботов и т.д. без ТАУ, теории игр теории принятия решений и т.д.?

Добавлено через 57 секунд

Сообщение от New man синтаксический сахар вроде асинхронных функций

Это вы про корутины как я понимаю? Ну и кому эти неуправляемые обрубки классов нафиг нужны? Не достсточно притянуть в язык весь хлам выброшнный на помойку в 60-х чтобы у него появились средства создания абстракций. То же касается анахронизмов под названием ФП и т.д.

Добавлено через 3 минуты

Сообщение от New man Правильно я понимаю, что чем сложнее задача, тем проще её писать?

На самом деле придется писать именно ту задачу которую нужно. Поэтому средства для задач уровня 50-х типа GC и ФП оказываются бесполезными.

Добавлено через 14 минут

Сообщение от New man если вручную его не разорвать weak_ptr. Лишняя работа.

ЗАчем тогда слабые ссылки нужны в языках с GC? Вообще их наличие в яве и шарпе - четкий показатель ненужности GC.

Добавлено через 3 минуты

Сообщение от New man Рефлексия из коробки, юнит-тесты из коробки, сборщик мусора и синтаксический сахар вроде асинхронных функций или propery не считаются?

Каким образом они относятся к средствам создания абстракций? В этом плане все эти шарпы и т.п. остались на уровне Симулы-67. А что касается к примеру свойств - изкоропки это означает ущербные (именно поэтому их в стандарте и нету хотя есть во многих компиляторах). Если к этому присовокупить невозможность реализации более другого их варианта библиотечными средствами - ну сами понимаете.

Добавлено через 5 минут

Сообщение от New man Плохое сравнение.

То вас похоже чему то вообще не тому учат. Главная часть работы программиста заключается в постановке задачи - т.е. как раз в продумывании средств решения задачи. И вот как раз для этого все 5 лет и учат математику и т.д. А написание кода - это самая простая и финальная часть разработки, приступать к которой без готовой постановки бессмысленно. А все ваши наблюдения основаны всего лишь на реалиях быдлоскриптинга который действительно живет именно так как вы описываете, а не профессиональной разработки.

Добавлено через 5 минут

Сообщение от New man А математический бекграунд одинаково применяется и на Python, и на C.

Только основная ниша питона ни разу не разработка программного продукта. Это так сказать программируемый калькулятора для представителей других наук, предназначенный для прикидочного счета матмоделей самостоятельно. ну типа в духе как в 60-ых была актуальна шутка - любой физик может на любом языке писать на фортране. Опять же все что делается на питоне ограничено наличием либ которые дделаются на плюсах.
Если же либ нет или они не совсем в дугу без плюсов на питоне вообще ничего сделать нельзя.
При наличии же либ пользующий их код на плюсах имеет свойство быть гораздо коротче чем на любом другом языке.

Добавлено через 11 минут

Сообщение от New man Рефлексия из коробки

Которую опять же присобачить к чемуто нужному малореально. В шарпе даже сериализатора/десериализатора толкового нет даже в рамках искоробочного фреймверка. В плюсах все это вообще на откуп фреймверку отдано. Именно потому что генерация RTTI должна быть управляема под реалии задачи. Соответственно либо внешний генератор либо отсутсвие возможностей использовать рефлекшин так как нужно для задачи а не так как задуали создатели искоробочного фреймверка для своей задачи ограничивающейся обеспечением фреймверка.

Добавлено через 15 минут

Сообщение от New man Можно измерять в time to market

только нужно отличать Time to market от time to epic matket fail. К примеру у ААА маркет вообще закончился как таковой - у всех ААА которые в прошлом году окупились рекламный бюджет в 3 раза превышал бюджет разработки. Epic fail по определению. Гуано которым завалены плеймаркеты и т.д. - ну там вооще практически сплошной фейл который бюджеты не отобъет никогда. И все потому что вместо изготовления по наукам которое в конечном итоге гораздо быстрее и надежней бесконечный твикинг людьми не понимающими что они вообще твикают.

Добавлено через 5 минут

Сообщение от New man Попробуйте нанять десяток программистов на проект

Даже пытаться не буду. Это слишком дохрена народа чтобы получился толковый движок.

Сообщение от New man Вы найдёте кучу воннаби профи, которые на плюсах разведут вам дичайшее багло

Точно так же они разведут это багло на любом языке, особенно на скриптовых и манаджед. Либо они понимают смысл термина реалтайм и бест практиклы с которыми его едят либо будет как у всех. Еще раз - ключ в постановке задачи. А постановка говорит что для задач игроделия по определению подходят только нативные языки.

Добавлено через 2 минуты

Сообщение от New man Я про интерпретаторы/ВМ/компиляторы более высокоуровневых языков

Уровневость языка определяется наличием у него средств создания абстракций. Так что те кто называют все это интерпретируемое убожество каким то более высоким уровнем квалификацию имеют вообще нулевую. Если это языки более высокого уровня то С++ - язык 80-го левела как минимум.

Добавлено через 4 минуты

Сообщение от New man За один семестр плюсы на должном уровне не выучить.

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

Добавлено через 6 минут

Сообщение от New man так как остальных уже разобрали, а сумма, за которую можно увести их к себе,

А зарплаты платят не за знание того или иного языка, а за знание бекграунда предметной области и умение решения задач, которое для гейм-дева тоже самое что для САПР, промавтоматики и софта по наукам.

0

Сообщение от Fulcrum_013 относительно времени выполнения нативного кода.

А что там является N? Покажите пример кода на C++, который выполняется за O(N) на C++ и за O(N^2) на C# или другом промышленном языке с Jit.

Сообщение от Fulcrum_013 Понятие мусор которое для GC абсолютно не совпадает с правилами ненужности объектов по реалиям задачи.

Мусор для GC — это объект, недоступный по графу ссылок. Даже если этот объект программисту и нужен, он не сможет к нему обратиться.
А если у вас есть доступ к некоторый ссылке, которая невалидна, так как вы где-то решили, что это мусор, то это dangling pointer. Что даёт кучу возможностей для всяких use-after-free и т.п. Чем это лучше?

Сообщение от Fulcrum_013 ЗАчем тогда слабые ссылки нужны в языках с GC? Вообще их наличие в яве и шарпе - четкий показатель ненужности GC.

Не нужны. Оказывается, есть класс для них в C#, но официальная же документация рекомендует их не использовать.

Сообщение от Fulcrum_013 А написание кода - это самая простая и финальная часть разработки

Неа. Финальная часть — это эксплуатация, а перед этим есть тестирование. Программа без поддержки нафиг не нужна.

Сообщение от Fulcrum_013 Добавлено через 4 минуты Цитата Сообщение от New man Посмотреть сообщение Правильно я понимаю, что чем сложнее задача, тем проще её писать? Вы это о чем вообще?

Это я пересказал то, что написали Вы

Сообщение от Fulcrum_013 Даже пытаться не буду. Это слишком дохрена народа чтобы получился толковый движок.

А сколько надо?

Сообщение от Fulcrum_013 Если же либ нет или они не совсем в дугу без плюсов на питоне вообще ничего сделать нельзя.

Mercurial, Sublime Text — это ничего?

Сообщение от Fulcrum_013 юнит-тесты используют только те кто в разработке софта вообще нифига не смыслят.

Ну, окей. Только я всё же прислушаюсь к другим советчикам.

Сообщение от Fulcrum_013 Средства создания высокоуровневых абстракций отсутсвуют.

Давайте конкретную абстракцию, которую можно написать только на C++.

0

Сообщение от New man Чем это лучше?

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

Добавлено через 1 минуту

Сообщение от New man Только я всё же прислушаюсь к другим советчикам.

Вы юнит-тесты юнит-тестами уже покрыли? Прекрасно. Теперь покрывайте тестами тесты тестов. И все равно никакой гарантии надежности не получите ровно как и никакой инфы о том что именно и почему не так.

Добавлено через 31 секунду

Сообщение от New man А сколько надо?

Максимум - до 5 человек.

Добавлено через 1 минуту

Сообщение от New man Программа без поддержки нафиг не нужна

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

Добавлено через 29 секунд

Сообщение от New man но официальная же документация рекомендует их не использовать.

Да что вы?

Добавлено через 1 минуту

Сообщение от New man с Jit

С Jit там вообще все грустно - во первых тормоза при первом запуске метода что для реалтайма недопустимо. В главных оптимизация гораздо хуже чем у нативного.

Добавлено через 5 минут

Сообщение от New man Давайте конкретную абстракцию, которую можно написать только на C++.

Начнем с простейшего - использование операторов аргумента шаблона с проверкой их применимости в компайл-тайме.
Ну а к примеру из очень часто используемого - принудительное удаление объектов с автоматическим разрывом всех взаимосвязей. С GC это тоже делать придется по условиям предметной области задачи. Только все ручками.

Добавлено через 3 минуты

Сообщение от New man Sublime Text — это ничего

А при чем тут IDE к возможности написания на языке эффективных либ для него же самого?

Добавлено через 9 минут

Сообщение от New man Мусор для GC — это объект, недоступный по графу ссылок.

Такой подход для системы защиты от висячих ссылок никогда эффективным не был, а особенно в современных иерархиях основанных на паттерне композит где невозможно существование объекта без трассы на рут, а ненужным по правиламп предметной области объект становится при разрыве какой то одной заранее определенной трассы на рут. А средством защиты от утечек GC не является. Наоборот это средство защиты от висячек путем перевода их в утечки в наивной надежде на то что эти утечки временны. Т.е. GC как средство защиты от висячек устарел лет 40 назад. Наиболее эффективна в этом плане абсолютно другая схема - слабых и слабовладеющих двунаправленных ссылок с автоматическим разрывом взаимосвязей удаляемого объекта. Это позволяет производить трассировку от удаляемого объекта т.е. гарантированно только в его локальном окружении и гарантированно не более одного раза за жизненный цикл объекта. Если же учесть тот факт что набор обратных ссылок нужен и для работы объекта, то такая систем еще и оверхеда по памяти вообще не имеет.

Добавлено через 4 минуты

Сообщение от New man Только я всё же прислушаюсь к другим советчикам.

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

Добавлено через 26 минут

Сообщение от New man Что даёт кучу возможностей для всяких use-after-free и т.п. Чем это лучше?

Даже если не реализована система автоматического разрыва взаимосвязей это выявится при первом же отладочном запуске. В отличии от фигни с GC который будет держать доступными объекты, которые по правилам предметной области корректно работать уже не могут, а соответственно усложнять отладку программы, путем сокрытия ошибок доступа к неработоспособным объектам.

0

Сообщение от Fulcrum_013 какое тестирование действительно эффективно

заинтересовало, можно поподробнее о чем речь?

Сообщение от Fulcrum_013 которые абсолютно никак не защищают от ошибок

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

Сообщение от Fulcrum_013 абсолютно никак не помогают при отладке

ну, так это немного о разном?

0

Сообщение от Azazel-San заинтересовало, можно поподробнее о чем речь?

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

Добавлено через 2 минуты

Сообщение от Azazel-San Дополнительная уверенность в том что я сделал все верно и код работает корректно, не только для меня как для того кто это написал, но и для того кто будет мой функционал использовать.

Корректность теста кто контролировать будет?

Добавлено через 3 минуты

Сообщение от Azazel-San ну, так это немного о разном?

а это уже кто как умеет. При этом еще и конкретно задачезависимо. К примеру для геометрических задач дебаг-отрисовка при отладке показывает сразу что именно не так.

1

Сообщение от Fulcrum_013 Кроме нужного метода выбираются еще два, желательно наиболее простых в реализации.

Не всегда же может быть такая возможность.

Сообщение от Fulcrum_013 в ручную контрольными данными

И не всегда тестируют на получение корректных данных? Поведение может быть разным. Допустим нужно протестировать верно ли рисует моя функция тайлы, при зуме.

Сообщение от Fulcrum_013 Корректность теста кто контролировать будет?

Сам программист же?) Если брать допустим совсем элементарную вещь, нужна функция которая вернет квадрат от числа. Пишу эту функцию и пишу тест, мол есть функция которая должна поднести до квадрата число 1, если в результате вернула 1, то я могу считать что этот тест она прошла успешно иначе тесты упадут.

0

Сообщение от Azazel-San Не всегда же может быть такая возможность.

Ну вот как раз наличием такой возможности применимость тестирования и ограничена.

Добавлено через 1 минуту

Сообщение от Azazel-San Если брать допустим совсем элементарную вещь, нужна функция которая вернет квадрат от числа.

Где гарантия что тест не будет требовать чтобы 2^2 было равно 9,34873544 и в результате отладки не доотлаживают до того что он будет возводить в квадрат именно так?

Добавлено через 3 минуты

Сообщение от Azazel-San Допустим нужно протестировать верно ли рисует моя функция тайлы, при зуме.

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

0

Сообщение от Fulcrum_013 Ну вот как раз наличием такой возможности эффективность тестирования и ограничена.

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

Сообщение от Fulcrum_013 Где гарантия что тест не будет требовать чтобы 2^2 было равно 9,34873544

Это скорее тогда требовние не к тесту, а к поведению самой функции возведения в степень.

Сообщение от Fulcrum_013 и в результате отладки не доотлаживают до того что он бкдет возводить в квадрат именно так?

Но если я и не ожидаю такого поведения, от функции которую я сам и писал, то я смогу такое поведение покрыть тоже, но другой вопрос, а нужно ли такое тогда вообще покрывать тестом?

0

Сообщение от Azazel-San то я смогу такое поведение покрыть тоже, но другой вопрос, а нужно ли это тогда вообще?

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

Добавлено через 1 минуту

Сообщение от Azazel-San Это скорее тогда требовние не к тесту, а к поведению самой функции возведения в степень.

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

Добавлено через 5 минут

Сообщение от Azazel-San Или я просто хочу проверить, а вернет ли она хоть что-то?

Если вызвать то одно из двух - или вернет что то или выбросит экскепшин. А соответсвенно одно из двух - либо этой функция вообще в коде не используется, либо таких тестов и так выше крыши.

0

Сообщение от Fulcrum_013 Причем вероятность допустить ошибку при самой подготовке данных на несколько порядков выше чем в коде.

Окей, да тут не спорю. Хотя все опять же зависит от реализации, тайлы могут и отличатся только зум-левелом, например
[0,0,0] -> [0,0,1] -> [0,0,2] - где z координата наш зум-лвл.

Сообщение от Azazel-San Допустим нужно протестировать верно ли рисует моя функция тайлы, при зуме.

здесь я имел ввиду, например, я сделал зум и хочу отрисовать тайл [0,0,1] смотрю на его прозрачность если она 0, смотрим на родителя, если у него 100 все еще рисуем его, а этому тайлу прибавим на пример 0.1 к непрозрачности. И я хочу тестировать именно эту логику. (возможно я что-то упустил, не хотелось бы сильно вдаватся в конкретику) В таком случае не нужно ничего считать, но конечно человеческии фактор всегда остается.

0