7 ms·

Four developers on one computer that had no hard drive. Not uncommon for the time, but looking back it sounds like hell

shiroiuma 3y ago
It's amazing what programmers were able to do back in those days without all the modern programming tools and languages and frameworks we have now. They didn't even have version control! Yet they managed to crank out code much faster, and with far fewer bugs, than today's programmers can seem to manage, and higher performing too for anything that didn't require heavy computation (these days, there's noticeable lag, sometimes up to 1s, between typing characters and seeing them on the screen; this never happened in the 80s).
- jmcgough 3y ago
  > Yet they managed to crank out code much faster, and with far fewer bugs Way way way less lines of code, and they were coding something to run on a single type of machine. They also made heavy use of manual testing before release, because once it was released it was incredibly difficult (and costly) to patch. If you've ever peaked underneath the hood of games like Final Fantasy 4, it's a lot of spaghetti code held together by duct tape.
- crq-yml 3y ago
  In truth, the Atari 8-bits I used from that era had trouble keeping up with fast typing and would drop characters, which is worse than just a delay. The nature of the development process then was necessarily centered on hardware development: the amount of computing logic to run Pong was a small multiple of the amount needed to run a contemporaneous electromechanical pinball, and the amount needed to run Donkey Kong was a few multiples of that for Pong: but the basic premise of "video games" remained close to the pinballs, still built on using timers, state flags and simple lookup tables to do almost everything, which is why the jump arc computation is notable for going into the realm of a real simulation and allowing the software aspect to "flex" a little more. They could have gone with a binary jump using a timer - there were games well after Donkey Kong that did that. The problems we face now are primarily ones of technical dependency in that configuring a system that does well at typing tests or any other specific metric is weighed against being able to access the standards that require a slower path - we generalized everything to USB and Unicode and JSON and other "not all that fast" standards, and we don't want to give them up, but they also lead to software that is complicated and hard to build.
- ZaoLahma 3y ago
  > Yet they managed to crank out code much faster, and with far fewer bugs, than today's programmers can seem to manage The reality is that today's programmers, especially in the big corporations, spend a lot of time not doing programming. It isn't too uncommon that something that takes a half decent programmer a couple of days to bang out is preceded by several weeks of running around trying to get approvals and clarifications on different levels. I guess earlier more trust (and responsibility) was given to the individual developers to decide what to do and how to do it, kind of like in smaller companies nowadays, and with the correct developers that enables a much more productive environment with little to no overhead.
- beAbU 3y ago
  > Yet they managed to crank out code much faster, and with far fewer bugs That seems like a pretty wild claim, no?
  - tmountain 3y ago
    Substantiated only by nostalgia.
    - msephton 3y ago
      In the article they mention only one bug was found in the game, and they fixed it by reducing a bounds check by a single pixel (so, likely an off-by-one error).
- pjc50 3y ago
  > Yet they managed to crank out code much faster, and with far fewer bugs There was simply a lot less of it. An Atari cartridge had 2kB of ROM. ZX Spectrum had 48kB of RAM for programs. Elite was targeted at the 32kB BBC. The normalized bugs/line and lines/day probably don't look as different as you think. The real question is: how much of modern code is really new features, how much is dealing with more complicated and less efficient platforms, and how much is busywork from one faction or another within the company?
- earthboundkid 3y ago
  I think a good comparison is how long it takes for people to make games on the PlayDate. The PlayDate has a weak processor by modern standards, but it also has a lot of modern little touches and a modern SDK. Yoyozo[1] is a recently released PlayDate game. The first toot about working on it on Mastodon[2] is from Sept. 5 and it got into the PlayDate store on Nov. 21. Elsewhere the creator said he put about a month into it. So a lone dev working on a legacy-like platform can launch a game in a month. I think Yoyozo doesn't have quite as much depth as Donkey Kong (not as many screens, no enemies), but it was made by a lone dev, so it probably all balances out. I think people are basically still capable of the same level of output, maybe a little higher, if they're willing to work on a limited platform. [1]: https://blog.gingerbeardman.com/2023/11/21/yoyozo-how-i-made-a-playdate-game-in-39kb/ https://blog.gingerbeardman.com/2023/11/21/yoyozo-how-i-made... [2]: https://mastodon.gamedev.place/@gingerbeardman/111013661521052756 https://mastodon.gamedev.place/@gingerbeardman/1110136615210...
  - adamrezich 3y ago
    Playdate development in C is a ton of fun and I can't recommend it enough. it strikes an excellent balance of constraints to design around (two colors, low resolution, limited Sharp LCD fill speed, no threading, small stack size, ten-second watchdog limit per frame) while still being accessible by modern standards (64-bit ARM architecture, plenty of RAM, extensive API). if you've burned out on modern game development, it's a welcome breath of fresh air.
    - msephton 3y ago
      I believe the ARM chip in Playdate is 32-bit, but yes to the rest!
      - adamrezich 3y ago
        ah yeah you're right, my bad
  - msephton 3y ago
    Fun to see you mention my game as I also submitted this Donkey Kong link! I worked on YOYOZO from September 5th to 27th (23 days) I submitted it to Catalog on 21st. The final week of the stretch was polishing. I did another day or maybe three to add score boards just prior to launch. It was in review/queue longer than it was in development, by far!
- bigbillheck 3y ago
  > far fewer bugs, Donkey Kong arcade had multiple bugs, one of which was bad enough they had to rush out a fix: https://twitter.com/MarioBrothBlog/status/1155879811727933441 https://twitter.com/MarioBrothBlog/status/115587981172793344... (see also https://tcrf.net/Donkey_Kong_(Arcade)#25m_Jump_Bug https://tcrf.net/Donkey_Kong_(Arcade)#25m_Jump_Bug, and the "kill screen" was never fixed)
WelcomeShorty 3y ago
Being from that time: it was't. We spend much "downtime" learning, reading and writing (pseudo) code. Remember, coding was new, access to existing "examples" close to zero, so we had to figure a lot of stuff out. Paper (no whiteboards either) was an excellent way to tinker, show off and bounce off ideas. I still find myself writing / drawing a lot before I actually touch a keyboard.
MarkusWandel 3y ago
Old fart here... when I got into computers it was with Commodore PETs at school. Hard disk? Ha. We shared a single CBM 8050 among a roomful of computers. It could be hotplugged, no biggie, if you needed to save your program you got a turn on the disk drive, put your personal floppy in... What was considered cheap in those days was printer paper. No problem at all to print out your entire program for going through and editing - with a pencil! - on the long school bus ride. Sounds awful now, but it wasn't, it was just different. Besides, at 40x25 character screen resolution, you couldn't keep that much code "in view" anyway.
- prpl 3y ago
  It’s (still) extremely cumbersome to work out complicated math/physics problems on a computer, be it Maple, Mathematica, Matlab, or something else, so this doesn’t sound so crazy. Relatedly, you can’t easily comment code willy nilly even with 120 char lines, so paper still has a lot of freedom anyway

It's amazing what programmers were able to do back in those days without all the modern programming tools and languages and frameworks we have now. They didn't even have version control! Yet they managed to crank out code much faster, and with far fewer bugs, than today's programmers can seem to manage, and higher performing too for anything that didn't require heavy computation (these days, there's noticeable lag, sometimes up to 1s, between typing characters and seeing them on the screen; this never happened in the 80s).

jmcgough 3y ago
> Yet they managed to crank out code much faster, and with far fewer bugs Way way way less lines of code, and they were coding something to run on a single type of machine. They also made heavy use of manual testing before release, because once it was released it was incredibly difficult (and costly) to patch. If you've ever peaked underneath the hood of games like Final Fantasy 4, it's a lot of spaghetti code held together by duct tape.
crq-yml 3y ago
In truth, the Atari 8-bits I used from that era had trouble keeping up with fast typing and would drop characters, which is worse than just a delay. The nature of the development process then was necessarily centered on hardware development: the amount of computing logic to run Pong was a small multiple of the amount needed to run a contemporaneous electromechanical pinball, and the amount needed to run Donkey Kong was a few multiples of that for Pong: but the basic premise of "video games" remained close to the pinballs, still built on using timers, state flags and simple lookup tables to do almost everything, which is why the jump arc computation is notable for going into the realm of a real simulation and allowing the software aspect to "flex" a little more. They could have gone with a binary jump using a timer - there were games well after Donkey Kong that did that. The problems we face now are primarily ones of technical dependency in that configuring a system that does well at typing tests or any other specific metric is weighed against being able to access the standards that require a slower path - we generalized everything to USB and Unicode and JSON and other "not all that fast" standards, and we don't want to give them up, but they also lead to software that is complicated and hard to build.
ZaoLahma 3y ago
> Yet they managed to crank out code much faster, and with far fewer bugs, than today's programmers can seem to manage The reality is that today's programmers, especially in the big corporations, spend a lot of time not doing programming. It isn't too uncommon that something that takes a half decent programmer a couple of days to bang out is preceded by several weeks of running around trying to get approvals and clarifications on different levels. I guess earlier more trust (and responsibility) was given to the individual developers to decide what to do and how to do it, kind of like in smaller companies nowadays, and with the correct developers that enables a much more productive environment with little to no overhead.
beAbU 3y ago
> Yet they managed to crank out code much faster, and with far fewer bugs That seems like a pretty wild claim, no?
- tmountain 3y ago
  Substantiated only by nostalgia.
  - msephton 3y ago
    In the article they mention only one bug was found in the game, and they fixed it by reducing a bounds check by a single pixel (so, likely an off-by-one error).
pjc50 3y ago
> Yet they managed to crank out code much faster, and with far fewer bugs There was simply a lot less of it. An Atari cartridge had 2kB of ROM. ZX Spectrum had 48kB of RAM for programs. Elite was targeted at the 32kB BBC. The normalized bugs/line and lines/day probably don't look as different as you think. The real question is: how much of modern code is really new features, how much is dealing with more complicated and less efficient platforms, and how much is busywork from one faction or another within the company?
earthboundkid 3y ago
I think a good comparison is how long it takes for people to make games on the PlayDate. The PlayDate has a weak processor by modern standards, but it also has a lot of modern little touches and a modern SDK. Yoyozo[1] is a recently released PlayDate game. The first toot about working on it on Mastodon[2] is from Sept. 5 and it got into the PlayDate store on Nov. 21. Elsewhere the creator said he put about a month into it. So a lone dev working on a legacy-like platform can launch a game in a month. I think Yoyozo doesn't have quite as much depth as Donkey Kong (not as many screens, no enemies), but it was made by a lone dev, so it probably all balances out. I think people are basically still capable of the same level of output, maybe a little higher, if they're willing to work on a limited platform. [1]: https://blog.gingerbeardman.com/2023/11/21/yoyozo-how-i-made-a-playdate-game-in-39kb/ https://blog.gingerbeardman.com/2023/11/21/yoyozo-how-i-made... [2]: https://mastodon.gamedev.place/@gingerbeardman/111013661521052756 https://mastodon.gamedev.place/@gingerbeardman/1110136615210...
- adamrezich 3y ago
  Playdate development in C is a ton of fun and I can't recommend it enough. it strikes an excellent balance of constraints to design around (two colors, low resolution, limited Sharp LCD fill speed, no threading, small stack size, ten-second watchdog limit per frame) while still being accessible by modern standards (64-bit ARM architecture, plenty of RAM, extensive API). if you've burned out on modern game development, it's a welcome breath of fresh air.
  - msephton 3y ago
    I believe the ARM chip in Playdate is 32-bit, but yes to the rest!
    - adamrezich 3y ago
      ah yeah you're right, my bad
- msephton 3y ago
  Fun to see you mention my game as I also submitted this Donkey Kong link! I worked on YOYOZO from September 5th to 27th (23 days) I submitted it to Catalog on 21st. The final week of the stretch was polishing. I did another day or maybe three to add score boards just prior to launch. It was in review/queue longer than it was in development, by far!
bigbillheck 3y ago
> far fewer bugs, Donkey Kong arcade had multiple bugs, one of which was bad enough they had to rush out a fix: https://twitter.com/MarioBrothBlog/status/1155879811727933441 https://twitter.com/MarioBrothBlog/status/115587981172793344... (see also https://tcrf.net/Donkey_Kong_(Arcade)#25m_Jump_Bug https://tcrf.net/Donkey_Kong_(Arcade)#25m_Jump_Bug, and the "kill screen" was never fixed)

WelcomeShorty 3y ago

Being from that time: it was't. We spend much "downtime" learning, reading and writing (pseudo) code. Remember, coding was new, access to existing "examples" close to zero, so we had to figure a lot of stuff out. Paper (no whiteboards either) was an excellent way to tinker, show off and bounce off ideas. I still find myself writing / drawing a lot before I actually touch a keyboard.

MarkusWandel 3y ago

Old fart here... when I got into computers it was with Commodore PETs at school. Hard disk? Ha. We shared a single CBM 8050 among a roomful of computers. It could be hotplugged, no biggie, if you needed to save your program you got a turn on the disk drive, put your personal floppy in... What was considered cheap in those days was printer paper. No problem at all to print out your entire program for going through and editing - with a pencil! - on the long school bus ride. Sounds awful now, but it wasn't, it was just different. Besides, at 40x25 character screen resolution, you couldn't keep that much code "in view" anyway.

prpl 3y ago
It’s (still) extremely cumbersome to work out complicated math/physics problems on a computer, be it Maple, Mathematica, Matlab, or something else, so this doesn’t sound so crazy. Relatedly, you can’t easily comment code willy nilly even with 120 char lines, so paper still has a lot of freedom anyway