A Retro Game Made with 21st Century Thinking - Gamedev The Hard Way

[ncot-tech]

Video Link Here
Github Repo

[Feyerabend]

I think you could benefit from slightly narrowing your goals--at least for a while.

Right now, you're juggling several fascinating concepts simultaneously, but the combination may be confusing for a viewer unfamiliar with your perspective. On one hand, there's your aim to code in C, a language strongly associated with systems programming and low-level control. On the other hand, you're also interested in what we might call retrocoding: recreating or reinterpreting coding styles and constraints from earlier computing eras, possibly with a spirit of historical reenactment. This includes not just the syntax, but the assumptions, habits, and limitations that shaped how people wrote and thought about code in those days.

Then there's a third element: the integration of large language models (LLMs) into your workflow. This is distinctly modern, a tool that introduces automation and a kind of dialogue with contemporary AI into the creative and technical process.

So the question arises: what is the nature of this project? Is it a historical reenactment of 1980s coding practice--faithfully replicating how it was? Or is it a modern reflection on those practices, using today's tools to comment on or reimagine the past? Right now, it's hard to tell, and that ambiguity may dilute the impact of your message.

For me, what bridges the 1980s and the present is simply this: code. You're still writing C code, just as many of us did back then. But everything around that act has changed dramatically. The context, the tools, the available knowledge--they've all evolved. Back then, information was scarce; we learned from sparse books, patchy documentation, and terse magazine articles. We struggled to get compilers working, and debugging often meant poring over hex dumps or deciphering cryptic linker errors.

Today, the challenge isn't a lack of information, but an overwhelming abundance of it. Compilation takes seconds. Knowledge is instantly accessible--but in such volume and variability that the challenge is no longer discovering facts, but filtering signal from noise. In that sense, coding has shifted from an exercise in endurance to one of discernment.

So perhaps your project could clarify its direction by making an explicit choice. Are you trying to recreate the limitations of the past, as a kind of experiential archaeology? Or are you using the past as a lens to reflect on the present--with LLMs serving as both a foil and a facilitator?

There's richness in either path, but trying to walk both at once might blur your message. Narrowing your focus, at least temporarily, could help the audience connect more deeply with the intent behind your work.

There are several points of your thinking that I do like a lot. One such example is separation of coding as product and coding as thinking. I have the same approach, and I think it can and will benefit from todays approach of programming in the world of LLMs. This and much more I describe at my repo.

Thanks for your efforts!

/Set

[ncot-tech]

You make a good point, I'm not entirely sure what I'm trying to do. Figuring this out is something I am trying to work on. I think now I've got DOS C programming working, and seem to know Agon Light programming more thoroughly that I'll stick to those two platforms.

DOS programming can be some good old school programming - doing all the things I wanted to do as a kid, but neither had the skill nor understanding to actually work on. And then on the Agon Light I think I'll try to make increasingly challenging games. I feel I can "get away" with using LLMs for making a game because it can help me work out what to do, but asking it to write me large quantities of DOS code feels like cheating.

And yeah, there is a distinction between making a finished program and thinking about what you're writing. This is why it is a bit tedious seeing people write off LLMs completely. They're just a tool. If you don't know how to think your way round a program, it won't help you very much. They're good tools for asking "how do I make something wiggle using a sinewave" and getting a quick answer compared to looking on Stack Overflow or places.

[Feyerabend]

I the following I've used ChatGPT to formulate the English better--as I am not a native speaker.

I believe I understand your ideas, concerns, and overall goal. The Agon Light 2—of which I also own a unit—is certainly an alluring platform. It has several appealing features, particularly its design as a high-speed terminal directly interfacing with the VDU. The trade-off, of course, is that communication between the processors is constrained in terms of bandwidth, though the latency is very low. In short: it’s well-suited for vector graphics, but ill-equipped for pixel-level manipulation.

As for programming in C under DOS, I never really got into it. I did some programming in CP/M during the early 1980s (I’m 61 now), but at that time, games weren’t part of it—I was already too old for that scene. I more or less stopped engaging with games around 1981 or 1982. I returned briefly to 8-bit computing in the mid-80s, primarily to explore memory banking on the Swedish ABC80, a machine already well past its prime. So no, games never really became a major focus for me. I did experiment with applet-style games in the late ’90s and early 2000s, but those were mostly Java-based.

What I really want to convey is that—even back then—we didn’t just write code impulsively. We usually had some sort of plan. My experience became particularly complicated when I tried to clean up a piece of Z80 assembly written by a skilled but rather undisciplined hacker for the ABC80. That experience left such a strong impression on me that I never pursued professional programming again. Life is simply too short.

Back then, we used tools like flowcharts, and sometimes JSP (Jackson Structured Programming). We printed out code listings and taped them to the wall. If we used BASIC, we created cross-references for variables. In assembly, we often documented subroutine behavior in detail. Looking back now—never again.

Yes, tools like large language models are fundamentally changing how programming is done. Andrej Karpathy has spoken extensively on the topic (Karpathy). I agree with some of his points, especially regarding the transformative impact of LLMs. But I disagree on others—such as the notion that LLMs will inevitably lead to an entirely new operating system paradigm. There’s certainly a broader discussion to be had on that front.

Back in the 1980s, I had this idea that the humanities could be meaningfully combined with technology—a vision I pursued for years, even decades. One of the avenues I explored was artificial intelligence. I studied philosophy, where logic played a central role; in fact, my professor believed formal logic was not just a part of philosophy, but its very core. That’s a longer story, so I’ll keep it short: AI has been a topic I’ve thought deeply about for a long time—through both the winters and summers of AI.

Large Language Models, I believe, are perhaps the most promising development we’ve seen so far. But they are not AGI. Still, they are extraordinary tools and will undoubtedly revolutionise how programming is practiced today. That transformative potential is something I try to capture and describe in my (upcoming) book. And I must say, I think your approach and attitude toward all this are very constructive.

I also want to commend you for your YouTube videos! They are not only entertaining, but they also offer a valuable window into how you think—and that is something I greatly appreciate. I think also others do that.

Rgds!
/Set

[SumikoMei]

While I haven't tried it yet specifically for helping write code, apparently Gemini 2.5 is the best model for writing code as I've heard from someone I trust who uses it for this quite often. I'd recommend giving it a try for these kinds of uses over ChatGPT.

Also I've been learning quite a lot of theory and principles lately while not actually writing any code in a while, and I've been leaning more and more lately toward writing close to the metal, and more or less as optimized as possible instead of today's trend of managed languages and over-engineered object-oriented programming. Your videos have been inspiring me lately to get more into that, so cheers for that. 💕