Как долго и какого рода сложность была бы связана с тем, что Крис Сойер писал большинство магнатов на американских горках?

От этого вопроса у меня есть еще один вопрос о ...
Как долго и какой тип сложности был бы вовлечен в Криса Сойера, пишущего большинство магнатов американских горок на ассемблере?

Для уточнения и разбора этого вопроса меня интересует;

1. Приблизительно сколько человеко-часов (есть предположения), как вы думаете, потребовалось бы Крису, чтобы написать игру самому? Или, в качестве альтернативы, укажите приблизительный процент соотношения между часами написания ассемблера и написанием всего этого на C / C ++.

2. Считают ли программисты, которые хорошо знают ассемблер, это слишком сложной задачей для такой низкоуровневой абстракции языка? Помимо преимуществ в производительности, это просто причудливые природные способности, которыми обладает Крис, или набор навыков, достойный изучения в такой степени? Мне интересно, если люди думают, что сложность / производительность стоит того, чтобы хорошо изучать ассемблер (для того, чтобы писать), или это только «стоит», если у вас есть много естественно разработанных навыков в ассемблере (предположительно, от работы с оборудованием) / аппаратные драйверы / электроника / и т. д.).

От чтения его грубой биографии это выглядит как два года (с начала 1997 до конца 1998). Учитывая, что он, кажется, человек «по одному проекту за раз», а набор инструментов и сроки не подходят для «групповой разработки», я бы предположил, что у программистов будет 24 месяца.

В то время он был профессиональным программистом игр, работая на ассемблере с 1983 года, поэтому я бы не стал приравнивать «два года Криса» к «двум мне годам» работы.

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

• Хороший программист в 10 раз продуктивнее хорошего программиста
• Программист важнее языка для продуктивности

Так что в этом случае, насколько бы быстрее был написан Rolcocoaster Tycoon, если бы Крис использовал C, Java, Javascript или ...? Вероятно, это не имело бы значения, кроме того факта, что он мог бы быть немного медленнее, используя язык более высокого уровня, с которым у него не было 14 лет опыта работы с ...

Если вы думаете о C как о чем-то большем, чем «высокоуровневый» ассемблер, и мы предполагаем, что Крис не делал сумасшедших оптимизаций для своего ассемблерного кода в каждой подпрограмме, то я бы представил, что с точки зрения% времени больше, тогда может быть, не так много для опытного программиста на ассемблере.

Сборка усложняется, когда вы выполняете все эти безумные оптимизации (операции векторизации, использование специальных наборов команд (SSE и т. Д.), Битовое перемешивание и т. Д.), Которые вы просто не можете сделать из C. Если вы делаете это, тогда время фактически находится в цикле «возьмите этот бит, соберите, измерите ... возьмите этот бит, соберите, измерите ...», а не в фактическом кодировании. С хорошим макро ассемблером и опытным программистом, написание ассемблера не является огромным шагом вниз по сравнению с написанием кода на C.

Тем не менее, я бы не смог этого сделать! Мне страшно подумать о попытке инициализации DirectX непосредственно в сборке! ( Правка: Википедия говорит мне, что он написал некоторые части на C для «интерфейса с операционной системой Windows», поэтому я думаю, что он не инициализировал DirectX в сборке тогда ... тьфу!)

Другой человек, известный тем, что пишет много программ для Windows на ассемблере, - Стив Гибсон, автор SpinRite, ShieldsUp! и другие коммунальные услуги. Он обсуждает свою любовь к языку ассемблера здесь .

У Рэнди Хайда (которого я знал еще тогда, когда мы оба писали ассемблерный код 6502 для Apple II) появилась новая онлайн-книга под названием « Программирование Windows на языке ассемблера» . Он большой сторонник использования причудливых макросов (включая циклические конструкции), чтобы сделать программирование на ассемблере более похожим на использование языка высокого уровня. Сойер, вероятно, использовал аналогичный подход, чтобы быть более продуктивным.