Per quanto tempo e quale tipo di complessità sarebbe stato coinvolto in Chris Sawyer nella stesura della maggior parte del magnate delle montagne russe nell'assemblatore?

Da questa domanda , ho un'altra domanda su ...
Quanto tempo e che tipo di complessità sarebbe stata coinvolta in Chris Sawyer nella stesura della maggior parte del magnate delle montagne russe nell'assemblatore?

Al fine di specificare e suddividere questa domanda, sono interessato a;

1. Approssimativamente quante ore uomo (indovinate) stimate che Chris avrebbe dovuto scrivere il gioco da solo? Oppure, in alternativa, fornire una percentuale approssimativa del rapporto delle ore di codifica dell'assemblatore, scrivendo il tutto in C / C ++.

2. I programmatori che conoscono l'assemblatore lo considerano un compito eccessivamente complesso per un'astrazione linguistica di così basso livello? A parte i benefici in termini di prestazioni, questa è solo un'abilità naturale strana che Chris ha, o una competenza degna di imparare fino a quel punto? Sono interessato se le persone pensano che la cosa complessità / prestazioni valga la pena di imparare l'assemblatore così bene (per scrivere), o è "degno" solo se hai molte abilità naturalmente sviluppate nell'assemblatore (presumibilmente lavorando con l'hardware / driver hardware / elettronica / ecc.).

Dalla lettura della sua ruvida biografia , sembrano due anni (dall'inizio del 1997 alla fine del 1998). Dato che sembra essere una persona "un progetto alla volta" e che il set di strumenti e il periodo di tempo non sono grandi per lo "sviluppo del team", assumerei 24 mesi di programmazione.

A quel punto era un programmatore di giochi professionale che lavorava in assemblea dal 1983, quindi non avrei equiparato "due anni Chris" a "due anni" di lavoro.

Dato che la maggior parte dei giochi professionali impiega circa 25 persone per svilupparsi in una squadra, due anni per un gioco leader del settore è un risultato sorprendente, dando fiducia ai detti:

• Un grande programmatore è 10 volte più produttivo di un buon programmatore
• Il programmatore è più importante della lingua per la produttività

Quindi, in questo caso, quanto più velocemente sarebbe stato scritto Rollercoaster Tycoon se Chris avesse usato C o Java o Javascript o ...? Probabilmente non sarebbe importato altro che il fatto che avrebbe potuto essere un po 'più lento usando un linguaggio di livello superiore che non aveva 14 anni di esperienza con ...

Se pensi a C poco più di un assemblatore "di alto livello", e supponiamo che Chris non abbia fatto ottimizzazioni pazze al suo codice assembly in ogni routine, allora immaginerei in termini di% di tempo in più, quindi potrebbe non essere molto di più per un programmatore di assemblee esperto.

L'assemblaggio diventa complicato quando stai facendo tutte quelle ottimizzazioni pazze (operazioni di vettorializzazione, utilizzo di set di istruzioni speciali (SSE, ecc.) Che twiddling, ecc.) Che semplicemente non puoi fare da C. Se stai facendo queste cose, allora il tempo è effettivamente nel ciclo "suonare questo bit, assemblare, misurare ... suonare questo bit, assemblare, misurare ..." e non nella codifica effettiva. Con un buon assemblatore di macro e un programmatore esperto, la scrittura di assembly non è un grande passo in avanti rispetto alla scrittura del codice C.

Tuttavia, non sarei stato in grado di farlo! Rabbrividisco al pensiero di provare a inizializzare DirectX direttamente in assembly! ( Modifica: Wikipedia mi dice che ha scritto alcune parti in C per "interfacciarsi con il sistema operativo Windows", quindi suppongo che non inizializzasse DirectX in assembly, quindi ... phew!)

Un'altra persona nota per aver scritto molti programmi Windows in assembler è Steve Gibson, autore di SpinRite, ShieldsUp! e altre utilità. Discute il suo amore per il linguaggio assembleare qui .

Randy Hyde (che conoscevo da tempo quando entrambi scrivevamo il codice assembly 6502 per Apple II) ha un nuovo libro online chiamato Windows Programming in Assembly Language . È un grande sostenitore dell'uso di macro fantasiose (inclusi costrutti di loop) per rendere la programmazione degli assiemi più simile all'uso di un linguaggio di alto livello. Sawyer probabilmente ha usato un approccio simile per essere più produttivo.