Hi everybody,

I would really appreciate if someone would help to unscramble my thoughts... :)

I'm trying to write a short summary about how "game programming" was when there were no reusable game engines. Let's assume (and I know it's controversial) that the DOOM engine was the first reusable game engine - so how where games programmed / build before 1993? When you ask google you'll get "games were written as singular entities from scratch in assembly" about 5.000 times but I don't know what to think about this phrase. Another thing I found was "games were monolithic software systems"...I like this a little more as it fits nicely with the reusable game engine as part of a "modular / component-based game architecture".

What do you guys think about that? If you could name some books (i've already read a few) that cover this topic - please let me know.

Best regards

koS

Mostly the same way. There's nothin special about an engine except that it exists and is mature.

So if you don't have one, you write the things you need for your game directly. Then the next time, you copy and reuse some of that code.

Games were written by reusing code almost from the first time there were games.

I don't know that much about C/assembly, but I can imagine something: There're tradeoffs and generally generalization makes stuff slower, maybe old games were more coupled because of performance. In graphics there're a good ammount of tradeoffs, but that's not what I would call my realm.

Is it possible to implement ECS in C? I only know that it's really a stripped down language. When did C++ become popular in gmaes?

Maybe take a look at the technology that was available at the time and see if you can find out anything about what was involved developing for it.

Is it possible to implement ECS in C?

Yes.

That's a good short answer, Josh. I neither implemented an ECS nor used C, but, some kind of wizardry should be used to get the same reusability from C++ (templates, polymorphism, etc).

That's a short answer, Josh. I neither implemented an ECS nor used C, but, some kind of wizardry should be used to get the same reusability from C++ (templates, polymorphism, etc).

I'd rather avoid derailing the original thread; so I'll just say that neither templates nor polymorphism are required for a component-based entity system. Even in C++.

Getting back to the topic, game engines did exist back in the day, such as they were.

Right now there are a few products that are enormous comprehensive game engines, but that is not the only kind of engine.

Companies would (and still do) build a game as best they could with the resources they have. Then when it is complete, the game-specific stuff is stripped out, the generic useful stuff is cleaned up, and a new game is created with the technology. This process repeats itself several times, and soon there is a central core people call an engine.

Back in the 1970s and 1980s the collection of reusable code was much smaller, and it was often manifest in terms of useful blocks of code for tiny pieces of functionality, but it still existed. People would write nifty code snippets for ray casting, for intersection tests, for DMA transfers, and the code got reused. People wrote algorithms for sorting, for searching, for various types of processing, and they grew into larger and larger libraries of useful code.

Eventually many of those libraries coalesced into bigger software libraries, and over time became things like physics engines, graphics engines, audio engines. Go back a few decades and the things still existed, but when programming on a 4 MHz chip (or slower) and the entire system memory is measured in bytes or kilobytes, such pieces of code are extremely small out of necessity.

That's a short answer, Josh. I neither implemented an ECS nor used C, but, some kind of wizardry should be used to get the same reusability from C++ (templates, polymorphism, etc).

I'd rather avoid derailing the original thread; so I'll just say that neither templates nor polymorphism are required for a component-based entity system. Even in C++.

It isn't just about the ECS. I think the programming paradigm is also a big influence. The paradigm changes the way of writting code, and it's another influence that adds up to the investment time if there's investment at all. And sometimes it's easier to write something in one run, and getting it all aparently messed up, but working, and that is something that changes with paradigm (let's say C and C++). This also tells that economy is a factor.

Also big teams also require more standarized ways of coding. Low budget solo code is different from team high budget structurated code.

ECS sometimes is overkill in this very same sense: A simple extended "strategy design pattern" in which you define fixed actors and interchangable behaviours can do good enough. Which I suppose would be in proportion in a stripped language like C.