¿Cuánto tiempo y qué tipo de complejidad habría estado involucrado en que Chris Sawyer escribiera la mayor parte del magnate de la montaña rusa en ensamblador?

De esta pregunta , tengo otra pregunta sobre ...
¿Cuánto tiempo y qué tipo de complejidad habría estado involucrado en que Chris Sawyer escribiera la mayor parte del magnate de la montaña rusa en ensamblador?

Para especificar y desglosar esta pregunta, me interesa;

1. Aproximadamente, ¿cuántas horas hombre (supongo) estima que le habría llevado a Chris escribir el juego solo? O, alternativamente, proporcione un porcentaje aproximado de la proporción de horas de codificación del ensamblador para decir, escribiendo todo en C / C ++.

2. ¿Los programadores que conocen bien al ensamblador piensan que esto es una tarea demasiado compleja para una abstracción del lenguaje de tan bajo nivel? Además de los beneficios de rendimiento, ¿es esta una habilidad natural extraña que tiene Chris, o un conjunto de habilidades dignas de aprender hasta ese punto? Me interesa si la gente piensa que la complejidad / rendimiento vale la pena aprender tan bien el ensamblador (para escribir), o solo "vale la pena" si tienes muchas habilidades desarrolladas naturalmente en el ensamblador (presumiblemente por trabajar con hardware / controladores de hardware / electrónica / etc.).

Al leer su biografía aproximada , parece que han pasado dos años (principios de 1997 hasta finales de 1998). Dado que parece ser una persona de 'un proyecto a la vez' y que el conjunto de herramientas y el marco de tiempo no son excelentes para el 'desarrollo de equipo', asumiría 24 meses programados.

En ese momento, él había sido un programador profesional de juegos trabajando en asamblea desde 1983, por lo que no equivaldría a "dos años Chris" a "dos años yo" de trabajo.

Dado que la mayoría de los juegos profesionales tardan alrededor de 25 años para que un equipo se desarrolle, los años de dos personas para un juego líder en la industria es un logro increíble, lo que da crédito a los dichos:

• Un gran programador es 10 veces más productivo que un buen programador
• El programador es más importante que el lenguaje para la productividad.

Entonces, en este caso, ¿cuánto más rápido se escribiría Rollercoaster Tycoon si Chris hubiera usado C o Java o Javascript o ...? Probablemente no habría importado más que el hecho de que puede haber sido un poco más lento usando un lenguaje de nivel superior con el que no tenía 14 años de experiencia ...

Si piensa que C es poco más que un ensamblador de "alto nivel", y suponemos que Chris no estaba haciendo optimizaciones locas a su código de ensamblaje en cada rutina, entonces me imagino que en términos de% de tiempo más, entonces podría no ser mucho más para un programador de ensamblaje experto.

El ensamblaje se complica cuando estás haciendo todas esas optimizaciones locas (operaciones de vectorización, haciendo uso de conjuntos de instrucciones especiales (SSE, etc.), entretejidos de bits, etc.) que simplemente no puedes hacer desde C. Si estás haciendo eso, entonces el tiempo está realmente en el bucle "violín este bit, ensamblar, medir ... violín este bit, ensamblar, medir ..." y no en la codificación real. Con un buen ensamblador de macros y un programador experto, escribir un ensamblaje no es un gran paso por debajo de escribir código C.

Aún así, ¡no habría podido hacerlo! Me estremezco al pensar en tratar de inicializar DirectX directamente en el ensamblado. ( Editar: Wikipedia me dice que escribió algunas partes en C para "interactuar con el sistema operativo Windows", así que supongo que entonces no estaba inicializando DirectX en el ensamblaje ... ¡uf!)

Otra persona conocida por escribir muchos programas de Windows en ensamblador es Steve Gibson, autor de SpinRite, ShieldsUp! y otras utilidades. Él discute su amor por el lenguaje ensamblador aquí .

Randy Hyde (a quien solía conocer cuando escribíamos el código de ensamblaje 6502 para Apple II) tiene un nuevo libro en línea llamado Programación de Windows en lenguaje ensamblador . Él es un gran defensor del uso de macros elegantes (incluidas las construcciones en bucle) para hacer que la programación de ensamblaje se parezca más a un lenguaje de alto nivel. Sawyer probablemente utilizó un enfoque similar para ser más productivo.