Comments 58
Последние два трюка взял на вооружение!
Последняя история напомнила рассказ "Мне не хватило одного байта"
Спасибо за ссылку! Не читал подобного ещё. Но прочитав, вспомнил дела 10-12-летней давности, когда проектировал всякие штуки на pic16f84a, и некоторые тоже с жёсткими временными рамками, почти реалтайм. Приходилось высчитывать (вручную) каждую команду, сколько она тактов займёт, сколько выполняется процедура, сколько это будет в миллисекундах, и т.п. Но там не было такого адского сочетания ограничений — места хватало, время можно было выкроить ещё, чуток оптимизировав код.
На одном из форумов в интрасети (РЖД) как-то устраивали соревнования по определённым задачам. Например, простейшая задача — бегущая строка с заданным текстом. Требуется минимизировать размер кода. И вроде бы уже нормальный код — но тут же кто-то выкладывает ещё короче, а потом ещё короче. И после сотни доработок, когда всем уже кажется, мол, всё, вот и победитель — оказывается, можно ещё сократить! Вот уж там простор для всяческих уловок.
В то время мне ох как надоел этот машинный код, и я просто забросил тему микроконтроллеров. Ограничился использованием готового кода, благо, уже тогда была уйма наработок.
На одном из форумов в интрасети (РЖД) как-то устраивали соревнования по определённым задачам. Например, простейшая задача — бегущая строка с заданным текстом. Требуется минимизировать размер кода. И вроде бы уже нормальный код — но тут же кто-то выкладывает ещё короче, а потом ещё короче. И после сотни доработок, когда всем уже кажется, мол, всё, вот и победитель — оказывается, можно ещё сократить! Вот уж там простор для всяческих уловок.
В то время мне ох как надоел этот машинный код, и я просто забросил тему микроконтроллеров. Ограничился использованием готового кода, благо, уже тогда была уйма наработок.
А сейчас в это можно играть: Shenzhen IO
UFO just landed and posted this here
были когда-то конкурсы
давноооо это было
Познавательно) С удовольствием прочитал.
загрузил в базу кода
заменёна чем-то немного более хорошим
Что случилось, у вас же были всегда хорошие переводы?
Некоторые комментарии к оригиналу статьи просто восхитительны. Например, этот:
ссылка
Back on Wing Commander 1 we were getting an exception from our EMM386 memory manager when we exited the game. We'd clear the screen and a single line would print out, something like «EMM386 Memory manager error. Blah blah blah.» We had to ship ASAP. So I hex edited the error in the memory manager itself to read «Thank you for playing Wing Commander.»
ссылка
UFO just landed and posted this here
Ну тогда уж и еще одно
Skeeet> Играл в Сталкера. Так и не понял что курили девелоперы, но навесные замки на дверях начинают неплохо кровоточить, если их побить ножиком… Напомнило старый боян про кенгуру и рефакторинг.
Повторное использование объектно-ориентированного кода (в программах) вызвало головную боль у Австралийских Вооруженных Сил. Т.к. симуляторы все активнее используются для тренировок боевых действий вертолетов, от программистов требуется постоянное повышение реализма используемых сценариев, включая детальные ландшафты местности и — в случае операции Феникс — стад кенгуру (т.к. испуганные животные могут легко выдать расположение воинских частей). Hачальник отдела симуляций наземных операций Defense Science and Technology Organization приказал разработчикам смоделировать перемещения кенгуру и их реакцию на вертолеты. Будучи грамотными программистами, те использовали готовые программные объекты, описывающие поведение пехоты в аналогичной ситуации, заменив изображения солдат на изображения животных и увеличив их скорость. Желая продемонстрировать свое мастерство перед посетителями — американскими пилотами — горячие австралийские парни «разбудили» кенгуру, пройдя над ними на малой высоте во время симуляции. Кенгуру разбежались, как и предполагалось, и американцы понимающе кивнули: А затем сильно удивились, т.к. кенгуру, перегруппировавшись, появились из-за холма и выпустили тучу стингеров по злополучным вертолетам. (Программисты забыли удалить соответствующий кусок кода из «пехотных» объектов). Hачальник симулятора отметил, что пилоты с этих пор боятся кенгуру как огня, для чего, собственно, и нужен был этот кусок кода в симуляторе.
Была такая игрушка Jagged Alliance. Нечто вроде квеста с вкраплениями пошаговых боёв-перестрелок.
Так вот, в процессе боя можно было (если хватало AP — очков времени) подбежать к противнику, и попытаться отобрать у него оружие. Успешность отбора, конечно, зависела от значений «сила» и «усталость» обоих персов, причем помочь врагу «устать» помогал удар-другой кастетом или монтировкой.
И все было бы правильно, если бы не чудеса наследования.
В игре были еще и враги-нечеловеки: тигры-людоеды. Естественно, основанные на классе «враг». Так вот, надавав тигру по черепу монтировкой, у него можно было отобрать оружие «челюсти». Такая вот челюстно-лицевая хирургия в полевых условиях.
Еще (в «фантастическом» режиме игры) были жуки-монстры наподобие «Чужих». Тоже, как вы догадываетесь, основанные на классе «враг». Надавав жуку по панцирю монтировкой, можно было отобрать у него оружие «плевалка». Только в отличие от челюстей тигра, которые были нормальным игровым объектом (после смерти тигра он оставался на трупе и мог быть продан некоторым неписям за бабки), плевалка была dummy-объектом наподобие свинского «Люгера». А у dummy-объектов картинка в инвентаре показывалась дефолтовая. А дефолтовой картинкой был миномёт. Вот так вот: избив жука, из него можно было достать миномёт. Не стреляющий, правда, поскольку боеприпасов для плевалки предусмотрено не было.
Но и это не конец. В конце игры были ещё танки. Да-да, тоже основанные на классе «враг». И, набравшись наглости, вся команда чаров подбегала к танку, стучала монтировками по броне, пока, видимо, экипаж не оглохнет, и… правильно, вырывала у танка пушку...
И ещё из Блицкрига: Ввиду нелётной погоды крылатая ракета вернулась на базу
Что ж вы делаете, я на работе, расползаюсь по столу, коллеги косятся подозрительно!
ААААА две полоскиии
Омг ) в закладки!
Д: а потому что у воды плотность большая! (прим.: больше, чем у ртути)
П: а почему плотность такая большая?!
Д: а чтобы ящики деревянные плавали!
П: а почему они иначе не плавают?!
Д: а потому что у них масса 50 кг!
Вообще-то, деревянные корабли и в 500 тонн, нормально плавают в воде => исправьте реализацию закона Архимеда в игре!
Да, но в законе Архимеда стоит объем тела.
Плавает тело или нет зависит от его плотности, а плотность у корабля и ящика с завышенной плотностью разные.
Плавает тело или нет зависит от его плотности, а плотность у корабля и ящика с завышенной плотностью разные.
А вот тут история про вагон метро из КДПВ. Если вкратце, то по рельсам бегает специальный NPC, а вагон заменяет его правую кисть. По ссылке есть восхитительная анимация работы!
Эмм. По ссылке в третьем же абзаце написано, что это не НПС, а сам игрок. В момент, когда игрок сидится в поезд, ему принудительно надевается броня в виде поезда (но выгладит это так, будто игрок внутри поезда), которая до кучи! заменяет правую кисть!, и включается анимация передвижения игрока. Такой способ привязать объект к игроку используя уже существующий способ, без разработки механики транспорта.
The truth is even stranger still: the train is in fact an armor piece that replaces the player character’s right hand entirely and gives the impression the player is inside a train. This also means it isn’t an NPC that powers the train, it’s the player themselves. A unique camera animation then plays along the track the ‘train’ takes.
(удалено)
ой, не успел
Построить дедупликацию на CRC32 — это сильно!
Я в этом месте тоже чаем поперхнулся. Не задаться простым вопросом «что будет, если сумма совпадет?» (а ведь совпадет, ибо принцип Дирихле).
Когда вы при загрузке уровня или во время игры по сотне раз проверяете ресурс (как раз проверка по хэшу), вы по-другому воспримите данный ход. Crc потому и выбирают, что он быстр.
Софтверный CRC32 совсем не быстр. См например тут https://github.com/rurban/smhasher
http://www.commitstrip.com/en/2017/02/27/the-sha-1-alternative/
В статье было написано, что там CRC не только от содержимого, но и от имени ресурса. Как у них совпало имя, я не совсем понял, но тем не менее они могли добавить к проверке третий параметр — размер данных ресурса, тогда вероятность совпадения была бы ниже. Ну либо считать два разных хэша, например CRC и MD5
Очень интересная статья, наглядно показывает, что многие даже не понимают насколько сложен и порой непредсказуем труд разработчика, и на какие ухищрения приходится идти, чтобы все работало)
В этом рейтинге говнобыстрокодеров забавно выглядит человек, многословно переживающий, что заюзал неиспользуемый void* под int.
Пока читал про Липкий баг — аж вспотел.
Точно та же ошибка была у меня в 2002г, когда делали игру для КПК. Точно так же решал каким то кривым хаком.
Точно та же ошибка была у меня в 2002г, когда делали игру для КПК. Точно так же решал каким то кривым хаком.
По-моему, подобные проблемы возникали у многих, кто писал свою физику.
На сколько я помню (лет 10 назад), у нас в гоночках был похожий баг. В большинстве случаев коллижен обрабатывался вполне адекватно. Но в некоторых местах на трассе стояли заборы, к которым можно было намертво прилипнуть. Причина оказалась банальной. Коллижен шейп на нём был двусторонний и бесконечно тонкий. В результате на солвер приходило две абсолютно идентичные точки столкновения с прямо противоположными нормалями, и он не мог решить — куда же объект надо выталкивать. Пришлось этот случай обрабатывать отдельно.
На сколько я помню (лет 10 назад), у нас в гоночках был похожий баг. В большинстве случаев коллижен обрабатывался вполне адекватно. Но в некоторых местах на трассе стояли заборы, к которым можно было намертво прилипнуть. Причина оказалась банальной. Коллижен шейп на нём был двусторонний и бесконечно тонкий. В результате на солвер приходило две абсолютно идентичные точки столкновения с прямо противоположными нормалями, и он не мог решить — куда же объект надо выталкивать. Пришлось этот случай обрабатывать отдельно.
Вы только что решили мою проблему…
В бытность учебы в колледже была у нас проектная работа по OpenGL и прочим 3d. Понятное дело я, как и большинство, делал a la бродилку без какого-либо движка: в большом кубе куча деревянных ящиков, подгружаемых из файла. Опционально, на ящики действовала физика: они могли упасть на землю, либо висеть в воздухе.
Собственно «игрок» мог перемещаться и прыгать по ящикам. Так вот, если встать под висящий ящик и зажать пробел, для прыжка, камера прилипала к ящику, пока не отпустишь пробел. Можно было с зажатым пробелом подлезть к краю ящика и запрынуть на него, будто ты руками цепляешься.
В общем я решил, что это не баг, а фича.
Собственно «игрок» мог перемещаться и прыгать по ящикам. Так вот, если встать под висящий ящик и зажать пробел, для прыжка, камера прилипала к ящику, пока не отпустишь пробел. Можно было с зажатым пробелом подлезть к краю ящика и запрынуть на него, будто ты руками цепляешься.
В общем я решил, что это не баг, а фича.
Это как знаменитый глич-прыжок в Ларе Крофт. Правда там механизм несколько иной
Ну, у меня без телепортов было )
Там физический движок не слишком удачно обрабатывал коллизии и когда игрок прыгал, то получалось, что он находился в стене и корректировал позицию до ближайшей свободной позиции — в итоге Лара "запрыгивала".
Я вижу, да.
У меня тоже с коллизиями фигня была. Точнее с определением возможности прыжка. За давностью лет точно не помню подробности, но кажется там считалось, что если есть нет скорости по вертикали, то можно прыгнуть, соответственно пробел задавал моментальное ускорение вверх. Вверх нельзя и камера прилипала: ускорение прыжка больше силы тяжести. Отпустишь пробел — сила тяжести возьмёт свое, а подойдёшь к краю, ускорение прыжка поднимет тебя вверх.
У меня тоже с коллизиями фигня была. Точнее с определением возможности прыжка. За давностью лет точно не помню подробности, но кажется там считалось, что если есть нет скорости по вертикали, то можно прыгнуть, соответственно пробел задавал моментальное ускорение вверх. Вверх нельзя и камера прилипала: ускорение прыжка больше силы тяжести. Отпустишь пробел — сила тяжести возьмёт свое, а подойдёшь к краю, ускорение прыжка поднимет тебя вверх.
За последний трюк я бы убил!
Последним способом пользуюсь постоянно.
Делаю электронику на STM32. Когда начинаю новый проект, всегда подключаю к нему свои самописные библиотеки. И в них как раз и расположен тот «балласт» в виде различных буферов, которые по умолчанию довольно велики. Если вдруг не хватает памяти и некуда оптимизировать основной код, я просто убираю буферы для неиспользуемых функций, и всё сразу становится хорошо. Хотя, производители микроконтроллеров часто предлагают модели, отличающиеся только по объему памяти и полностью совпадающие по остальным параметрам, что позволяет на время разработки взять самый толстый микроконтроллер из серии, а потом, если удалось ужаться, выбрать модель поменьше и подешевле.
Делаю электронику на STM32. Когда начинаю новый проект, всегда подключаю к нему свои самописные библиотеки. И в них как раз и расположен тот «балласт» в виде различных буферов, которые по умолчанию довольно велики. Если вдруг не хватает памяти и некуда оптимизировать основной код, я просто убираю буферы для неиспользуемых функций, и всё сразу становится хорошо. Хотя, производители микроконтроллеров часто предлагают модели, отличающиеся только по объему памяти и полностью совпадающие по остальным параметрам, что позволяет на время разработки взять самый толстый микроконтроллер из серии, а потом, если удалось ужаться, выбрать модель поменьше и подешевле.
Когда делали прототип Blood&Gold: Carribean! на движке Маунт-Блейда для того что бы не решать задачи поиска пути, контроля скорости и ввода «просто» заменяли модельку игрока и лошади (sic!) моделькой кораблика — так оно и ушло в релиз. Хє-хє :)
Последнюю байку следует вставлять в начало документации и каждого туториала по React, Angular и Electron. Чертовы хипстеры со своими топовыми маками и стомегабитным интернетом, всё равно ведь не поймут, наверное…
Sign up to leave a comment.
Грязные трюки в коде игр