> It actually took a lot longer to re-write the game in C++ than it took me to write the original machine code version 20 years earlier.
Is the most interesting quote IMO. I often feel like productivity has gone down significantly in recent years, despite tooling and computers being more numerous/sophisticated/fast.
It's possible that "it took several years and a small team of programmers to re-write the entire game in C++" because ⓐ those programmers were not as good as he was, and/or ⓑ they had to duplicate the behavior of an existing program exactly, rather than enjoying Bob Ross's happy little accidents, as long as the game was fun.
I'm pretty sure most programmers who are comfortable in both C++ and assembly language can add working functionality to a program faster in C++ than in assembly. Of course, certain C++ libraries will eliminate that advantage, but choosing to use those libraries isn't essentially different from many other bad decisions you might make about how to write a large program.
> it took several years and a small team of programmers to re-write the entire game in C++. It actually took a lot longer to re-write the game in C++ than it took me to write the original machine code version 20 years earlier.
Expanding the quote because the word "team" is probably relevant to why it took longer to rewrite. At a certain scale there just is a huge advantage in everything being inside one head...
Communication overhead is a big thing in teams. If you have a struggling team, halve the size. It's crazy how well that works. It's not the people but the number of them. Once your people are consumed by the day to day frustrations of having to communicate with everyone else and with all the infighting, posturing, etc. that comes with that, they'll get nothing done. Splitting teams is an easy to implement fix. Minimize the communication paths between the two (or more) teams and carve up what they work on and suddenly shit gets done.
In this case, they probably were trying to not just rewrite but improve the engine at the same time. That's a much more complicated thing to achieve. Especially when the original is a heavily optimized and probably somewhat hard to reason about blob of assembly. I'm guessing that even wrapping your head around that would be a significant job.
Amazingly enjoyable game btw. Killed quite a few hours with that one around 2000.
>Communication overhead is a big thing in teams. If you have a struggling team, halve the size. It's crazy how well that works.
I wish my managers would get this. Currently our product shit the fan due to us being understaffed and badly managed due to clueless managers, and what they did was add two more managers to the team to create more meetings and micromanage everrying.
Chris Sawyer lived and breathed assembly, earlier in the article he states that he just felt more efficient writing it than higher level languages. Then you've got the modern team of devs who probably haven't worked with asm since university, and it becomes difficult for them to review the original source code. Also Chris probably wasn't doing a lot of the actual programming, so instead of one guy working on a passion project, you have a team of devs doing a job.
Found this part strange because in other interviews he seemed to imply (for RCT classic) that there was almost some kind of VM-like structure that was running the original code underneath as-is
I think the real constraint must be market timing - as much work as people can do to meet the market (eg. Have the thing done by Christmas), that much will end up being done.
Is the most interesting quote IMO. I often feel like productivity has gone down significantly in recent years, despite tooling and computers being more numerous/sophisticated/fast.