Комментарии 58
Последняя история напомнила рассказ "Мне не хватило одного байта"
На одном из форумов в интрасети (РЖД) как-то устраивали соревнования по определённым задачам. Например, простейшая задача — бегущая строка с заданным текстом. Требуется минимизировать размер кода. И вроде бы уже нормальный код — но тут же кто-то выкладывает ещё короче, а потом ещё короче. И после сотни доработок, когда всем уже кажется, мол, всё, вот и победитель — оказывается, можно ещё сократить! Вот уж там простор для всяческих уловок.
В то время мне ох как надоел этот машинный код, и я просто забросил тему микроконтроллеров. Ограничился использованием готового кода, благо, уже тогда была уйма наработок.
загрузил в базу кода
заменёна чем-то немного более хорошим
Что случилось, у вас же были всегда хорошие переводы?
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.»
ссылка
Skeeet> Играл в Сталкера. Так и не понял что курили девелоперы, но навесные замки на дверях начинают неплохо кровоточить, если их побить ножиком… Напомнило старый боян про кенгуру и рефакторинг.
Повторное использование объектно-ориентированного кода (в программах) вызвало головную боль у Австралийских Вооруженных Сил. Т.к. симуляторы все активнее используются для тренировок боевых действий вертолетов, от программистов требуется постоянное повышение реализма используемых сценариев, включая детальные ландшафты местности и — в случае операции Феникс — стад кенгуру (т.к. испуганные животные могут легко выдать расположение воинских частей). Hачальник отдела симуляций наземных операций Defense Science and Technology Organization приказал разработчикам смоделировать перемещения кенгуру и их реакцию на вертолеты. Будучи грамотными программистами, те использовали готовые программные объекты, описывающие поведение пехоты в аналогичной ситуации, заменив изображения солдат на изображения животных и увеличив их скорость. Желая продемонстрировать свое мастерство перед посетителями — американскими пилотами — горячие австралийские парни «разбудили» кенгуру, пройдя над ними на малой высоте во время симуляции. Кенгуру разбежались, как и предполагалось, и американцы понимающе кивнули: А затем сильно удивились, т.к. кенгуру, перегруппировавшись, появились из-за холма и выпустили тучу стингеров по злополучным вертолетам. (Программисты забыли удалить соответствующий кусок кода из «пехотных» объектов). Hачальник симулятора отметил, что пилоты с этих пор боятся кенгуру как огня, для чего, собственно, и нужен был этот кусок кода в симуляторе.
Была такая игрушка Jagged Alliance. Нечто вроде квеста с вкраплениями пошаговых боёв-перестрелок.
Так вот, в процессе боя можно было (если хватало AP — очков времени) подбежать к противнику, и попытаться отобрать у него оружие. Успешность отбора, конечно, зависела от значений «сила» и «усталость» обоих персов, причем помочь врагу «устать» помогал удар-другой кастетом или монтировкой.
И все было бы правильно, если бы не чудеса наследования.
В игре были еще и враги-нечеловеки: тигры-людоеды. Естественно, основанные на классе «враг». Так вот, надавав тигру по черепу монтировкой, у него можно было отобрать оружие «челюсти». Такая вот челюстно-лицевая хирургия в полевых условиях.
Еще (в «фантастическом» режиме игры) были жуки-монстры наподобие «Чужих». Тоже, как вы догадываетесь, основанные на классе «враг». Надавав жуку по панцирю монтировкой, можно было отобрать у него оружие «плевалка». Только в отличие от челюстей тигра, которые были нормальным игровым объектом (после смерти тигра он оставался на трупе и мог быть продан некоторым неписям за бабки), плевалка была dummy-объектом наподобие свинского «Люгера». А у dummy-объектов картинка в инвентаре показывалась дефолтовая. А дефолтовой картинкой был миномёт. Вот так вот: избив жука, из него можно было достать миномёт. Не стреляющий, правда, поскольку боеприпасов для плевалки предусмотрено не было.
Но и это не конец. В конце игры были ещё танки. Да-да, тоже основанные на классе «враг». И, набравшись наглости, вся команда чаров подбегала к танку, стучала монтировками по броне, пока, видимо, экипаж не оглохнет, и… правильно, вырывала у танка пушку...
И ещё из Блицкрига: Ввиду нелётной погоды крылатая ракета вернулась на базу
Омг ) в закладки!
Д: а потому что у воды плотность большая! (прим.: больше, чем у ртути)
П: а почему плотность такая большая?!
Д: а чтобы ящики деревянные плавали!
П: а почему они иначе не плавают?!
Д: а потому что у них масса 50 кг!
Вообще-то, деревянные корабли и в 500 тонн, нормально плавают в воде => исправьте реализацию закона Архимеда в игре!
Плавает тело или нет зависит от его плотности, а плотность у корабля и ящика с завышенной плотностью разные.
И что? Плотность дерева ящика/корабля — меньше воды, плотность пустого воздуха внутри ящика/корабля тоже — меньше воды => должно плавать.
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
В статье было написано, что там CRC не только от содержимого, но и от имени ресурса. Как у них совпало имя, я не совсем понял, но тем не менее они могли добавить к проверке третий параметр — размер данных ресурса, тогда вероятность совпадения была бы ниже. Ну либо считать два разных хэша, например CRC и MD5
Точно та же ошибка была у меня в 2002г, когда делали игру для КПК. Точно так же решал каким то кривым хаком.
На сколько я помню (лет 10 назад), у нас в гоночках был похожий баг. В большинстве случаев коллижен обрабатывался вполне адекватно. Но в некоторых местах на трассе стояли заборы, к которым можно было намертво прилипнуть. Причина оказалась банальной. Коллижен шейп на нём был двусторонний и бесконечно тонкий. В результате на солвер приходило две абсолютно идентичные точки столкновения с прямо противоположными нормалями, и он не мог решить — куда же объект надо выталкивать. Пришлось этот случай обрабатывать отдельно.
Собственно «игрок» мог перемещаться и прыгать по ящикам. Так вот, если встать под висящий ящик и зажать пробел, для прыжка, камера прилипала к ящику, пока не отпустишь пробел. Можно было с зажатым пробелом подлезть к краю ящика и запрынуть на него, будто ты руками цепляешься.
В общем я решил, что это не баг, а фича.
Это как знаменитый глич-прыжок в Ларе Крофт. Правда там механизм несколько иной
Там физический движок не слишком удачно обрабатывал коллизии и когда игрок прыгал, то получалось, что он находился в стене и корректировал позицию до ближайшей свободной позиции — в итоге Лара "запрыгивала".
У меня тоже с коллизиями фигня была. Точнее с определением возможности прыжка. За давностью лет точно не помню подробности, но кажется там считалось, что если есть нет скорости по вертикали, то можно прыгнуть, соответственно пробел задавал моментальное ускорение вверх. Вверх нельзя и камера прилипала: ускорение прыжка больше силы тяжести. Отпустишь пробел — сила тяжести возьмёт свое, а подойдёшь к краю, ускорение прыжка поднимет тебя вверх.
Делаю электронику на STM32. Когда начинаю новый проект, всегда подключаю к нему свои самописные библиотеки. И в них как раз и расположен тот «балласт» в виде различных буферов, которые по умолчанию довольно велики. Если вдруг не хватает памяти и некуда оптимизировать основной код, я просто убираю буферы для неиспользуемых функций, и всё сразу становится хорошо. Хотя, производители микроконтроллеров часто предлагают модели, отличающиеся только по объему памяти и полностью совпадающие по остальным параметрам, что позволяет на время разработки взять самый толстый микроконтроллер из серии, а потом, если удалось ужаться, выбрать модель поменьше и подешевле.
Последнюю байку следует вставлять в начало документации и каждого туториала по React, Angular и Electron. Чертовы хипстеры со своими топовыми маками и стомегабитным интернетом, всё равно ведь не поймут, наверное…
Грязные трюки в коде игр