Я кстати тоже не поливал грязью С++, ибо пишу на обоих языках, мое высказывание связанно с опытом. Я видел кучу людей которые ушли из с++ и не вернутся туда уже никогда. Тем не менее потерял кучу кармы, ну да ладно, дело наживное.
Если прикинуть, то на каждый кадр нужно отдеьно рисовать по 4 рисунка. Из этих 4 рисунков на выходе получается вроде как обычная карта нормалей. Мне кажется легче художнику сгенерить обычную карту нормалей а потом ручками ее подправить под требуемую.
Если «Просто делаешь и все» то опыт не придет =) Нужно развиватся как в програмировании так и в конкретно в геймдеве. Уж очень достали на работе разработчики у которых есть опыт но нет желания двигатся вперед. Любые попытки открыть им глаза натыкаются на «их опыт», никакие аргументы не работают, ведь их задача, «просто делать и все».
Этот подход не тупиковый, нет, он вполне работает там где опыт имеет больше вес чем придерживание какой либо архитектуры, каких либо норм, какой либо документации. И если проект не масштабный, то это немешает его технической успешности. Если же проект большой, игры уровня ММО, там «просто делать и все» обычно кончается неподдерживаемой тонной кода. Что для многих игр подразумеваемых поддержку и развитие, превращается в кошмар. Люди демотивированны, любое изменение ведет к дыркам в еще большем колличестве мест и другие прелести подхода «просто делать и все».
«Собрали игру за сколько то дней» и «Собрал игру один» относятся к гейминдустрии также как и алимпиадники по программированию к реальной разработке. Хорошее начало, но нужны другие скилы, нужны другие знания.
Я не сильно в этом разбираюсь и хотел спросить. Не будет ли ливлок в системе, где приоритет отдается читающим потокам? Ибо написав циклы чтения мы можем ждать какогото изменения. А если увеличить число потоков чтения до большого числа то это только увеличивает такой вариант.
Я уже писал в той статье, проблему решат нультипы. Если объект не найден то вернуть заранее созданый валидный спец объект этого же типа. После этого, можно обрабатывать логику на любом уровне. А все промежуточные слои не трогать, пусть они выполняют только свою работу. Очень полезно при изменчивой разработке, когда логика пишется параллельно с данными. Можно добавлять данные и удалять, менять проверки и все будет работать.
Нет, это тип твоего объекта но содержащий спец информацию, отладочную или пишуший лог. т.е. FindUser будет всегда находить объект, если юзера нет, то вернется спец объект типа User. И проверять нужно не на Null а на, например, User.Empty
Вот например string.Epmty, Guid.Empty это оно и есть.
Мне кажется удобнее использовать нультипы. Во всех враперах можно все равно запросить значние если его нет, и это ситуация, также порождает ексцепшен. Т.е. синтаксически ничем не отличается от проверки на null.
Напишите текст, который я должен написать что бы мое резюмэ устроило модераторов (или ботов) hh. Сейчас моя задача угадать чужие замыслы третьих людей.
Я занят не поиском работы а написанием текста, причем, при написнии документации я знаю цели и средства, а при сотавлении резюмэ, я занят самым сложным тестом тьюринга.
Звездная команда не всегда нужна, иногда это плохо. Если все проектировщики, все очень общительные -> постояные споры. Нужен один два проектировщика, остальные — реализаторы. Реализатор не обязательно тупой и не может проектировать, но обязательно умеющий реализовывать любую придуманую архитектуру, обучаем и покладист. Может быть даже ни разу не социальным, главное управляем.
Даже написав программу на чистых кодах асемблера, можно наткнутся на закладку(или неточность) процессора. А создав свой процессор с нуля можно наткнутся на закладку(или багу) природы.
Этот подход не тупиковый, нет, он вполне работает там где опыт имеет больше вес чем придерживание какой либо архитектуры, каких либо норм, какой либо документации. И если проект не масштабный, то это немешает его технической успешности. Если же проект большой, игры уровня ММО, там «просто делать и все» обычно кончается неподдерживаемой тонной кода. Что для многих игр подразумеваемых поддержку и развитие, превращается в кошмар. Люди демотивированны, любое изменение ведет к дыркам в еще большем колличестве мест и другие прелести подхода «просто делать и все».
Вот например string.Epmty, Guid.Empty это оно и есть.
Я занят не поиском работы а написанием текста, причем, при написнии документации я знаю цели и средства, а при сотавлении резюмэ, я занят самым сложным тестом тьюринга.