John Carmack's way of coding

[daemonicky]

I looked at his GPL work : Wolf, Quake, Quake 2 and Doom and must say that he makes each iteration of his engine so better i smile.

I looked at AI code in Wolf and Doom and main loop and they were similar but more advanced. I believe that John Carmack iterates his engine. And when I looked at videos of Hovertank 3D and Catacomb 3D I noticed they look visually similar, so I assumed that they might be similar in code and when I saw the difference in codes of Wolf, Doom and Quake I realized that he might have iterated over his old design.

I wonder where he got idea of entities, they are in each of hs GPL work. I wonder how much Mike Abrash influenced him, how much he studied things like object oriented programing ...

In Quake he made practical object oriented languge for FPS games - entities and event handlers (think, prethink, touch ...). Awesome. I mean, practical, I dont see any him doing multi purpose generic stuff, but something which fits to the game and is nicely extensible.

I must say, that I am impressed by this man. Awesome work John.

Id love to hear your opinions on what I may missed, got wrong and about how you like, what is your experience with his GPL engines ...

[Baker]

Entities are just an array or database of world elements. I imagine there isn't another way to do it, except the inverse which would be doing a world array grid (cell based containers) which wouldn't work well in animated 2D or animated 3D.

I have the feeling that John Carmack had quite a bit of 2D game knowledge prior to Commander Keen. I'm not sure how old he was when he did that game, but he didn't just programming then and probably had at least 5 years prior experience or possibly more.

Ironically, I am working on an animation experiment now that pulled me back to entities and QuakeC style "thinks". I'm not working with Quake, just doing some OpenGL experiments.

I am trying to control animation sequences of screen elements and the best way I've found is to give each element a pointer to a function each frame to tell it how to move (if NULL, no move obviously).

In otherwords, I'm kinda doing SV_Physics within Host_Frame with QuakeC thinks and having to work with frame timing stuff --- bizarre how it seems that Quake had "all the answers".

I'm not qualified to say how far or not far ahead of his time John Carmack was, but I can say the execution is a work of art and masterpiece. The more I've learned about the guts of the engine and the QuakeC, the more and more I get impressed.

I also enjoy reading stuff that people like Sajt or MH write about philosophy (Quake designed to not need controls --- push button intentionally did not need +use bind) or map design (mega healths on every level by a map author).

[qbism]

Looking at Quake code years ago got my mind around the philosophy of "state machines". A state machine doesn't need to know entire history to compute the current time slice, it only needs the previous time slice. It's all about how well everything is organized.

Quake is an object-oriented database and I'd agree that's probably the best way to organize the information. But efficiency and multi-threading capability might be improved by a more data-driven method of processing the information.

A short-order cook is a sort of data-driven state machine. He's going to stay just one step ahead of incoming orders, and he's going to batch components of each order by process. For example, the cook doesn't fry each customer's hashbrown order one-by-one; he sums up the hashbrown needs in the current batch of orders and cooks them all at the same time. Thereby the cook could also multi-thread that task to another cook while he fries eggs.

Waffle House, anyone?

[goldenboy]

(Quake designed to not need controls --- push button intentionally did not need +use bind)

This isn't inherently good btw - it's just one way to do it.

There are game design related (non-engine) reasons why a USE button can be good. Imagine DOOM with auto-opening doors.

Basically having an "open door" button increases the immersion for me.

[Baker]

Rather than start a new thread ...

I've already made a distinct mini-engine out of pieces and parts of Quake that allow me to do faster experimentation and play with concepts (and do OpenGL animations and so forth).

And thinking about code re-use, both the console and the command interpreter (and actually the cvar system) are particularly important pieces ... who wants to write that stuff and why not reuse what you've got.

Anyway, some of my recent engine work I had to reverse because I was busting up the "modular design" of the Quake engine and making everything dependent on everything else.

Getting to the point and adding that I have not looked at the DooM or Wolfenstein source code, what often crosses my mind as I'm examining code or tearing things apart to see how they work is the "completeness" of the Quake engine.

Sure this is a 15 year old game, but the engine was written with a lot of capabilities that someone could have just simply not written. The cachedir stuff (to those that know what I'm talking about). -basedir (the ability to specify the game directory). Stuffcmds ... the ability to receive general game commands from the command line (like +map). The QHost stuff. The config, script and alias capabilities. (Obviously, the QuakeC interpreter). The flexibility of setting up the controls, etc.

Maybe not a fair comparison, but if you look at Half-Life you can tell they did not thoroughly vet the engine or the game data like they did with Quake (this is putting GLQuake aside, DOS Quake was the real Quake. WinQuake and GLQuake were after-the-fact rush jobs.)

Half-Life uses all kinds of data formats (.bmp in places, WAD in places, I'm rather sure TGA in places). Gordon Freeman is wearing his HEV suit if you do chase_active 1 in the console before he puts it on. I understand the concept of economic pressure and the need to get the game out and you can live with compromises of incompleteness.

I'm just saying that this is particularly the interesting thing about the Quake engine. Certainly there was economic pressure to get the game done and shipped and Quake, to be fair, isn't as complex as later games, but as I look through the code and you spot all of these extraneous flexibilities, it looks really clear that the intent of proper design was a major factor.