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

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

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

0

Сообщение от Azazel-San Зачем стремится тогда к "универсальности"? Универсальность всегда идет немного в разные стороны с производительностью

как раз наоборот. Да и кот обычно куда попроще. К примеру определение (и даже предсказание) коллизий что с ним не делай всегда будет работать путем проекции примитива на набор осей. При этом диапазон проекции на свои оси у примитива всегда может быть предпросчитанным. Поэтому стоит сделать универсальную функцию проецирования примитива на ось для каждого из типа примитивов а в самих функциях определения коллизий оперировать уже осями и проекциями, в том числе предпросчитанными при инициализации проекциями на свои оси. С учетом того что такая функция пондобится еще для кучи дел ну имеет смысл просто сделать такой метод для каждого типа примитива. (хотя если реально то он один для всей полигональной геометрии и разный только для курвированных примитивов типа квадрик торов и т.д.).
В результате и кода самой проекции с гулькин нос и кода коллизий кот наплакал.
вот так к примеру тест пресечения 2D ОВВ выглядит в результате.
что тут собственно говоря тестировать то а тем более рефакторить?

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

Сообщение от Azazel-San Не всегда же юнит-тестами тестируют именно алгоритм

А с каких это пор в софте какие то звери кроме алгоритмов завестись успели?

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

Сообщение от Azazel-San Отдельные компоненты. В этом и суть как я понимаю юнит-тестов.

НУ и что там тестировать если оно уже полностью отлажено? Ну и при этом каждый компонент в современном его понимании - то бишь класс это целый пакет алгоритмов применимых к какой то структуре данных. При этом тестировать вот типа на наборе данных можно только какую то отдельно взятую подпрограмму. Но как бы что оно вернет зависит от внутреннего состояния объекта. Соответсвенно такие тесты в общем то бессмысленны или настолько громоздки что будут вразы больше кода компонентов. При этом использование компонета в иерархии протестирует все это гораздо лучше потому что точно так же завязано на внутренние состояния. Именно поэтому и инкапсулируют именно механизмы. Они могут работать только в иерархии обеспечивая взаимодействия 2+ компонентов. А соответсвенно какое либо тестирование их по отдельности абсолютно бессмысленно.
Вообще юнит-тесты соответсвует выборочной проверке таблицы истинности функции по одному тесту для каждой возможной внутренней ветки. Но как бы для объектов имеющих внутреннее состояние построение таблиц истинности не возможно в принципе. Если же это механизм зависящий еще и от других компонентов имеющих внутренние состояния то тут с тестами вообще алес ховайся .

0

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

Ну вот, в итоге вроде не такой уж и универсальной ее необходимо делать. А иногда бывают случаи когда функция используется только в 1м конкретном месте и более нигде (сейчас говорим не о пересечениях, а вообще абстрактно), зачем ее делать унивресальной?
И что-то мне кажется наши понимания в "универсальности" немного расходятся или я чего-то не понимаю.

Сообщение от Fulcrum_013 что тут собственно говоря тестировать

Ну, если захотеть то можно)

А вы например книжку Кента Бэка о TDD смотрели/читали?

0

Сообщение от Azazel-San Хотел бы пингануть пару людей, но боюсь тапками закидают за такое.

Реально это зависит только от того кто у него на работе принимает решения технического характера - он или менеджер.

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

Сообщение от Azazel-San А иногда бывают случаи когда функция используется только в 1м конкретном месте и более нигде

Универсальной означает что в своей зоне ответственности она работает универсально. Т.е. для любых возможных входных данных либо даст ответ либо вернет ошибку. При этом как бы не имеет никакого смысла делать функцию которая считает 2*a если можно сделать функцию b * a.

0

Сообщение от Fulcrum_013 Реально это зависит только от того кто у него на работе принимает решения технического характера - он или менеджер.

Всеравно было бы интересно послушать, я же получается тоже в этом верчусь и хотел бы конкретнее разузнать, а может я вообще все не так понял????

Сообщение от Fulcrum_013 Универсальной означает что в своей зоне ответственности она работает универсально. Т.е. для любых возможных входных данных либо даст ответ либо вернет ошибку. При этом как бы не имеет никакого смысла делать функцию которая считает 2*a если можно сделать функцию b * a.

А, вот вы о чем, тогда да, тут согласен. Хотя опять же если ее функционал сводится до 2*a, то действительно надо ли делать ее b*a?

0

Сообщение от Azazel-San Похоже наши понимания в "универсальности" немного расходятся или я чего-то не понимаю.

универсальная там функция проекции массива точек на ось которая вызывается из верхнего метода. И вот как раз она в алгоритмах определения коллизий всех примитивов используется и далеко не только в них.

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

Сообщение от Azazel-San Хотя опять же если ее функционал сводится до 2*a, то действительно надо ли делать ее b*a?

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

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

Сообщение от Azazel-San Всеравно было бы интересно послушать, я же получается тоже в этом верчусь и хотел бы конкретнее разузнать, а может я вообще все не так понял????

В этом вопросе все очень просто. Получается отладить трассировкой - отлично. Не получается - делается какой то дебаг енвайронмент в котором что то на подобие тестов с визуальным анализом что срослось что не срослось. Ну и проектировать так чтобы не надо было рефакторить. Т.е. по принципу один класс (пара классов если механизм взаимодействи) - один механизм. Следующий механизм уже в потомках. Ну и в результате получается набор кирпичиков которые или собираемые или наращиваемые наследованием для конкретной реализации чего либо а потом из них более крупное собирабельно.
Т.е. по большому счету ключ он в том что при нормальном подходе к проектированию устраняется сама необходимость в рефакторинге корректность коего де и должны проверять тесты. Хотя даже при этом они бесполезны. Переделка интерфейса требует и переделки тестов и это очевидно. Гораздо менее очевидно что и переделка реализации требует полной переделки тестов. Именно потому что они должны тестировать каждую возможную ветку выполнения.

1

Сообщение от Fulcrum_013 жрать то не просит а пригодится может

Обычно просит. Реализация универсального алгоритма обычно сложнее, чем специализированного. То же умножение это несколько десятков операций (раз нам его пришлось писать, готовой инструкции не было), тогда как умножение на 2 это сдвиг влево или сложение, всего одна операция.

1

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

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

0

Сообщение от COKPOWEHEU Реализация универсального алгоритма обычно сложнее, чем специализированного.

Набор частных случаев обычно просит жрать в разы больше чем универсальное решение.

0

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

0

Сообщение от COKPOWEHEU Если у меня в программе часто используется вычисление квадратного корня я не буду искать алгоритм возведения в любую степень, я напишу именно корень.

Для чего в формулу разложения степенной функции в ряд подставите 1/2. Не проще ли один раз написать разложение самой функции и потом сделать функцию квадратного корня передающую в функцию возведения в степень фиксированный аргумент и сразу иметь тул на все случаи жизни? Тут мыслить надо по принципу все что пишем сегодня становится нашим тулом завтра.

Сообщение от COKPOWEHEU Да и отлаживать частные случаи проще, поскольку меньше переменных.

Одни товарищи тут с год назад вопрошали как отладить "сапр для лестниц". Потратить на набор из 8 частных случаев они успели 5+ человеколет, набылокодить 300k+ строк и получить абсолютно неотлаживаемый набор гуано. При этом для сравнения универсальное геометрическое 3D ядро умещается в район 10k строк.

0

Сообщение от Fulcrum_013 Для чего в формулу разложения степенной функции в ряд подставите 1/2

Совершенно не обязательно.

Сообщение от Fulcrum_013 Потратить на набор из 8 частных случаев

Сколько времени вы потратите на написание универсального решателя квадратных уравнений? А уравнений любой степени?

0

Сообщение от COKPOWEHEU Совершенно не обязательно.

Оно черезчур приблизительное

0

Со своей задачей оно справляется.
Причем, как и следовало ожидать, делает это лучше универсального решения.

0

Сообщение от COKPOWEHEU Причем, как и следовало ожидать, делает это лучше универсального решения.

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

Сообщение от COKPOWEHEU Со своей задачей оно справляется.

Ну вообще частные случаи нужно реализовывать только в том случае если они дают какой либо выигрыш по сравнению с универсальным алгоритмом. К примеру то же геометрическое ядро получается настолько большим потому что 90% кода это обработка частных случаев НУРБС поерхностей типа плоскостей, конусов, сфер торов и т.д. пересечения для которых находятся быстрее чем для нурбсов с сохранением точности решения. Но тем не менее в комплекте это дает возможность моделирования любой геометрии, что существенно упрощает алгоритм автоматического моделирования чего то конкретного.

Добавлено через 14 минут
COKPOWEHEU, А вообще универсализация обычно достигается декомпозицией сущностей предметной области на набор более мелких механизмов, которые имеют свойство иметь очень ограниченное количество, но при этом практически бесконечное количество вариантов сборки. Как результат это дает и значительный выигрыш в плане сложности реализации, и оставляет простор для реализации альтернативных механизмов для частных случаев дающих выигрыш в производительности. Т.е. автомат эквивалентный паре автоматов имеет m*n состояний в то время как пара автоматов имеет n+m состояний. Именно поэтому универсализация значительно снижает сложность реализации задачи и позволяет с легкостью использовать нивыгоднейшие оптимизации там где это нужно.

0

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

Если нужно только решение частного случая - пишем именно его. Если еще одного - пишем еще один. Если понадобилось (или велика вероятность что понадобится) обрабатывать десяток похожих случаев - только тогда имеет смысл поискать универсальный алгоритм.
Если общего решения нет в принципе или оно слишком сложное / затратное - пишем кучу частных.
Об этом я и говорю: не надо впадать в крайности. Достаточно ситуаций, когда несколько частных решений лучше одного общего, достаточно обратных. Не стоит всегда и везде лепить общее.

0

Сообщение от COKPOWEHEU Если нужно только решение частного случая - пишем именно его. Если еще одного - пишем еще один. Если понадобилось (или велика вероятность что понадобится) обрабатывать десяток похожих случаев - только тогда имеет смысл поискать универсальный алгоритм.

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

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

Сообщение от COKPOWEHEU Достаточно ситуаций, когда несколько частных решений лучше одного общего, достаточно обратных.

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

0

Сообщение от Fulcrum_013 Вообще то решение пишется для предметной области.

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

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

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

Сообщение от Fulcrum_013 Но набор стоит сделать универсальным сразу.

И затратить на это неопределенно много времени.
Еще раз: сколько времени у вас займет написание решателя любых уравнений? Сумеете ли вы написать хотя бы универсальный решатель квадратных уравнений?

0

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

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

Добавлено через 5 минут
И да, иногда аппетит приходит во время еды ясность задачи увеличивается по мере её реализации. Ну например когда в автомате состояний приходится реализовывать их в 3 раза больше чем предполагалось изначально.

0

Сообщение от TRam_ не говорю уже о постановке задачи.

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

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

Сообщение от TRam_ ясность задачи увеличивается по мере её реализации

Такого быть не может в принципе. Ясность задачи увеличивается исключительно а процессе анализа предметной области. Если она увеличивается с типа при реализации это всего лишь означает что приступили к реализации без соответсвующего анализа. Анализировать же задним числом бессмысленно. потому что анализ зачастую позволяет сократить объем потребного кода в 10+ раз и рефакторинг после анализа задним числом просто превращается в лучшем случае в выбрасывание 90% ранее написанного кода.

0

Сообщение от Fulcrum_013 Такого быть не может в принципе.

Ну вот вы говорите о

на набор более мелких механизмов, которые имеют свойство иметь очень ограниченное количество

с чем не соглашусь категорически. Мелкие механизмы наоборот, имеют свойство плодиться. Хотя зависит от задачи, в части случаев они конечно поддаются унификации на основе обобщённых алгоритмов, но не всегда.
Соответственно не во всякой первичной постановки их всех можно осмыслить и описать.

0