Hacker News new | past | comments | ask | show | jobs | submit login

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).




> 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?


> 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.


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.


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...

[2]: https://mastodon.gamedev.place/@gingerbeardman/1110136615210...


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.


I believe the ARM chip in Playdate is 32-bit, but yes to the rest!


ah yeah you're right, my bad


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!


> Yet they managed to crank out code much faster, and with far fewer bugs

That seems like a pretty wild claim, no?


Substantiated only by nostalgia.


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).


> 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.


> 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/115587981172793344... (see also https://tcrf.net/Donkey_Kong_(Arcade)#25m_Jump_Bug, and the "kill screen" was never fixed)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: