If any of you are going to read my comment, don't take offense to it. In other words... "trigger warning".

so how where games programmed / build before 1993?

"Games were written by programmers who actually knew how to code their way out of a wet paper bag" was the first thing that came to my mind, as only a weak programmer would completely rely on an pre existing engine. What if Unity and UE4 suddenly disappeared? Many of you would simply be f**ked.

But to be more on topic, this is my take on the question:

Languages:

But frankly, in the early days, games were often either coded in pure C or a mix of it with some assembly. Console games before then, such as the NES defintely used assembly. Using C for console games started becoming more common around the PSX era. Even then, knowledge of assembly for the specific processor of that console was required as certain routines could only be done in assembly, or just weren't practical to be done in C. Same for PC (DOS) games back in that era. To initialize ModeX or whatever screen resolution you had in mind, you would use a DOS interrupt service with assembly. Other routines, such as detecting a vertical blank/sync, were also done in assembly or by accessing VGA registers directly. When it came to PC games, the drawing routines were often written in software. You would either call the DOS interrupt service to put pixels on the screen, or you'd have to write to video memory (framebuffer) directly. Obviously, assembly drawing routines were faster than straight C implementations, so it was done that way for most 2D/3D games.

Platforms:

Every platform was different, and often didn't have much in common. Knowledge of how each platform worked was required to write code for each one. Some with different memory requirements, others with different bus and bandwidth speeds. Lots of platform specific code needed to be written (well, it would be alot to the average indie of today who has never worked outside of Unity and UE4). Debugging it was not quite as easy as it is now either.

Hardware:

Similar to what I said above, but I wanted to expand on it in a different way. Every platform's hardware differences had to be known and taken into consideration before you even dreamed of putting a game on it. On top of that, your code had to be *optimal* too. These days, too many terribly inefficient games written because we have the hardware that can run it. Such crappy code wouldn't do so well on consoles in the 90s. For instance, console resources are *tight*, meaning you need every last byte, and to make it count. Also, you often had a very limited amount of CPU cycles at your disposal. This was often true for PC games as well. Back then, you actually had to consider how much memory your data structures were using.

Another thing to note is that you didn't have drivers for everything. Back then, you had to have register level documentation to program hardware directly, as well as setup the proper interrupt handlers. For gfx, if you had a special video card that supported 3D acceleration, you'd be fortunate to even have an API provided by the vendor. Managing video memory, drawing efficiency, and vsync timing had to be done by you. For audio, you would have to know how to program the audio hardware as well. Streaming audio to a Soundblaster wasn't as easy as using XAudio2 or OpenAL like we have now. Input wasn't exactly hard, but it was often more work to setup. Short story, you had to know your stuff.

Misc:

I repeat, you had to know your s**t. There were no pre-written math libraries (at least, not nearly as many as we had now), and if you wanted something like an MMX accelerated math library, you wrote it yourself. Engines did exist back then, but if you wanted to use some middleware engine, such as the wolfenstein engine by id Software, you'd have to pay up for a license. And no, licenses weren't cheap either.

These days, you can write a game and get away without knowing any of the internal stuff. Some say that's a good thing, I say it isn't to a certain degree. Which reminds me of a somewhat cruel idea for a whiteboard test for a game development job interview. Try asking your candidate what they would do to write a function that blocks the calling thread until vertical blank called "BlockUntilVerticalBlank()" for any platform or API they desire, while giving them [unspoken] bonus points for considering the thread's priority level. Watch the majority of them fail miserably. At one point, this was common knowledge, and anyone who has ever programmed a game would know how to do this for at least one platform. But that's just the era we live in. It kinda reminds me of how the average human in the 1st world wouldn't know how to hunt or grow food if the supermarkets all disappeared. Convenience eventually leads to laziness.

Shogun

I think there was a distinction between games and buisness software dev:

Buisness software code bases have to be maintained for decades. This means that the the software would has alot of devs coming in and out of a team over such a long period. You are almost certain to lose a significant percent of your technical leads over such a long period. This means that having clean reusable code is paramount. It is even more important than performance.

Think about it, some businsess codebases that were created at the time of the PS1 are still being actively developed, and maintained. Some actual banks even use code-bases from the pong era. (I know an actual person that owns a small company of COBOL programmers, and they still train young interns!)

With games, that seems different. A game is developed quickly. Even a long triple-A development is in the order of magnitude of 5 years. As such I would expect the teams to be integral. So I would think that that gives you alot of leeway regarding how easy to understand,develop, and reuse the code base. You can probably rely on whoever wrote the code to still be involved in the project. You should very rarely loose your lead programmers over such a short period. That frees you up to spend your time doing platform specific optimisations. Even if you write awesome reusable PS2 code, the PS2 would die out before you switch jobs...

However, now with the new mega-engine era. Engines like Unreal and Unity (and some additional proprietary engines), are being used for a very long time across multiple platforms, by many many teams. As such, their coding standards are starting to become more and more important, and the code quality is becoming more important.

"Games were written by programmers who actually knew how to code their way out of a wet paper bag" was the first thing that came to my mind, as only a weak programmer would completely rely on an pre existing engine. What if Unity and UE4 suddenly disappeared? Many of you would simply be f**ked.

I can't tell if you're trying to be funny, or you genuinely believe that bullshit, so apologies if you were just being sarcastic.

First, Unity and UE4 aren't going to suddenly disappear and if they did, something else would replace them.

Second, who gives a damn? The idea that you need to be able to be an amazing engine programmer to write a good game is patently false. Most people don't give a crap what your programming skills are, they care about the game mechanics, story, graphics, etc.

Being a great programmer != creating a great game. Shigeru Miyamoto was an industrial designer.

This concept is ridiculously flawed. It's like saying you have to be a farmer or a knife maker to be a great chef. You need to understand how to use your ingredients and tools, but you certainly don't need to make them.

"Games were written by programmers who actually knew how to code their way out of a wet paper bag" was the first thing that came to my mind, as only a weak programmer would completely rely on an pre existing engine. What if Unity and UE4 suddenly disappeared? Many of you would simply be f**ked.

I can't tell if you're trying to be funny, or you genuinely believe that bullshit, so apologies if you were just being sarcastic.

He's not entirely wrong. I've met a number of folks who claim to be "game programmers," but are helpless outside of their chosen engine. You ask them really basic but important things - like the differences between various types of data structures (eg. "what is the difference between an array and a linked list"), or the time complexity of string comparisons, or even language features like the difference between a "struct" and a "class" in C# - things that you would expect (as shogun put it) "a programmer who actually knew how to code their way out of a wet paper bag" to know - and you get the deer-in-the-headlights look. Such folks really would be left in the lurch if their chosen engine up and vanished, or changed significantly enough to invalidate their knowledge. It seems entirely plausible to me that some such GDNet members are reading this very post as we speak (hint to them: these are topics for you to research if you want to better yourself! Not to mention that interviewers tend to look for skills in those areas...). Being someone who programs games technically qualifies one as a "game programmer," but that doesn't mean one is a good "programmer."

The claim that "only a weak programmer would completely rely on a pre-existing engine" is definitely false in this day and age, however. Strong programmers do rely on an engine when the engine does what they need it to and they have no need to leave that box.

Being a great programmer != creating a great game. Shigeru Miyamoto was an industrial designer.

That is definitely true, but also not really relevant to either shogun's post or the thread in general. The topic of the thread is "game programming before reusable game engines [became popular]," not "do you have to be a good programmer to make a good game." shogun is addressing the first, not the second. I mean, his post even says "These days, you can write a game and get away without knowing any of the internal stuff."

Tread lightly.


That is all.

Try asking your candidate what they would do to write a function that blocks the calling thread until vertical blank called "BlockUntilVerticalBlank()" for any platform

I'd say "call &bd19" and then ask them which platform that is.

He's not entirely wrong. I've met a number of folks who claim to be "game programmers," but are helpless outside of their chosen engine.

Then they are still game programmers, only with a limited field of experience. Being able to programm a game == being a game programmer... well better call them "game developer" if the programming part falls short, but nevertheless.

Don't get me wrong, versatility is a good thing, but somebody who can only make games with UE4 isn't much different to me than a low-level programmer who only knows C++. You've got a limited toolbox, but if you can make what you want with your toolbox...

You ask them really basic but important things - like the differences between various types of data structures (eg. "what is the difference between an array and a linked list"), or the time complexity of string comparisons, or even language features like the difference between a "struct" and a "class" in C#

Is this all that important if all you do is create a game in an engine? It probably isn't for most parts. If you use linked lists everywhere you might run into performance problems eventually, but probably most of the titles that the type of "game programmer" we are talking about would create, its unlikely this would even be a problem.

=> Knowing those programming basics are necessary if you do a lot of programming, if you just click your game together in an engine, why does it matter?

Such folks really would be left in the lurch if their chosen engine up and vanished, or changed significantly enough to invalidate their knowledge

This is just never going to happen. Even if say Epic games went bancrupt today and pulled Unreal Engine from the public - those people would still have their current version of Unreal Engine, and could make games with it. They only wouldn't get any access to future updates, meaning they will eventually work with outdated technology, but lets be frank... a lot of programmers who know their programming make their games with seriously outdated technology anyways, so again, I fail to see the problem.

(Oh, this is comming from someone who doesn't rely on 3rd-party/external engine support for his programming projects at all, I just try to see it from the other perspective. Yknow, there's still people making games with rpg-maker who don't even know that a thing such as an array or linked list exists...)

If any of you are going to read my comment, don't take offense to it. In other words... "trigger warning".

so how where games programmed / build before 1993?

"Games were written by programmers who actually knew how to code their way out of a wet paper bag" was the first thing that came to my mind, as only a weak programmer would completely rely on an pre existing engine. What if Unity and UE4 suddenly disappeared? Many of you would simply be f**ked.

In the beginning programs had far less scope but programmers had to know how to leverage the system to its fullest. The required skillset of game programmers before 1993 is radically different to today. And i bet if you took those same people and dropped them into a business application their code would be arse and unmaintainable.

If you want to be productive in any time/place you need to learn what is going to make you productive, not some preconcieved nonsense idea of what makes someone a 1337 haxor.

He's not entirely wrong. I've met a number of folks who claim to be "game programmers," but are helpless outside of their chosen engine.

Then they are still game programmers, only with a limited field of experience. Being able to programm a game == being a game programmer...

Indeed. I believe I said that in my post. :P

You ask them really basic but important things - like the differences between various types of data structures (eg. "what is the difference between an array and a linked list"), or the time complexity of string comparisons, or even language features like the difference between a "struct" and a "class" in C#

Is this all that important if all you do is create a game in an engine?

Um, yes. Basic computer science and understanding of one's programming language is just as important in gameplay code built on a commercial engine as it is in gameplay code built on a custom engine. Not knowing these things may not prevent you from making "something" work, but making something work well, and with good performance? That's something else. Making a game in Unity that doesn't incur performance penalties from the garbage collector (for instance) requires some understanding of what the garbage collector actually does, and at the very least that certain data structures will create more garbage than others (if not why).

To be clear, I'm not saying you need to be a "1337 haxor" to be a good game programmer. The stuff I've called out is really basic stuff that any computer science undergrad should have learned by the time they hit 3rd year, never mind by the time they graduate! I would expect even an intern to know this stuff if they wanted to get hired...

Such folks really would be left in the lurch if their chosen engine up and vanished, or changed significantly enough to invalidate their knowledge

This is just never going to happen. Even if say Epic games went bancrupt today and pulled Unreal Engine from the public - those people would still have their current version of Unreal Engine, and could make games with it.

That may be true, but not everyone who works in Unity or Unreal is as self-employed indie. What happens if your skillset is limited to one or both, and your employer decides to switch technologies? Hint: you're going to get left behind. :)

Um, yes. Basic computer science and understanding of one's programming language is just as important in gameplay code built on a commercial engine as it is in gameplay code built on a custom engine. Not knowing these things may not prevent you from making "something" work, but making something work well, and with good performance? That's something else. Making a game in Unity that doesn't incur performance penalties from the garbage collector (for instance) requires some understanding of what the garbage collector actually does, and at the very least that certain data structures will create more garbage than others (if not why).

Well, you've certainly got a point, yet:

Performance is only so much of an issue. Sure, if you're going to make a content-driven quality 3D-game, you've got to know what you're doing, I can totally agree with that. The type of programmer I was thinking of, and still belive would fit this context the best, is the kind of guy that makes some generic 2d-platformer, or whatever. Flappy bird, super hexagon, half of the steam library... pretty much every game that doesn't do something really extensive with its gameplay, especially in 2D. I'm pretty convinced that you can make such a game in a proprietary engine without having the aformentioned programming skills. Thats just with existing game engines though - OFC, if you have to code graphics, physics, etc... all yourself, then naturally if you don't know how to write performant code you're probably be hardpressed to show 30 sprites on the screen without lag.

(on the contrary, the first C++ project I wrote, where I knew DICK about stuff like O(n) and barely knew C++, I still managed to write a 2D Super Mario World clone in C++ that managed to simulate 300 enemies, with O(n^2) collision detection... so thats kind of the direction I'm coming from)

Overall I think the discussion hereby boils down to "at which point, and on what scale does it become a problem if you don't know how to properly programm"? I belive we both agree that you can write somehow games without knowing too much, and you also need to have a good knowledge for anything remotely complex. We probably only differentiate based on where we draw the line for what can be done for a terrible coder.