The best resources for creating a Quake mod?

[soso]

Hi guys,


I've been doing a little bit of research and I can't seem to find any solid answers on what the best way is to create a Quake mod these days. It seems like there is a plethora of different engines, and QuakeC dialects (SSQC, CSQC, FTEQC) to choose from all with varying levels of documentation. I already have programming knowledge so I'm really just looking for something fairly straightforward and documented. Any tips are greatly appreciated.


Sincerely,
Soso

[Dutch]

Howdy.

You'll want the QuakeC Manual (link below).

This manual will give a lot (not all) of information regarding the built-ins and fields used in SSQC (server-side QC). Remember that QuakeC is a simplified derivation of C. It does not have all of the capabilities of C, and several functions and fields used in QC are referenced by the engine C code during gameplay.

A few quick bits of info:
* SSQC (server-side) is traditional QC. ALL engines will recognize the progs.DAT that is compiled in SSQC.
* CSQC (client-side) is a newer feature. As of now, only DarkPlaces and FTEQW will recognize it. This is useful for making new HUDs, sekeletal animations, etc. You must use FTEQCC compiler to compile this code, IIRC.
* Any engine not Darkplaces (DP) or FTE is generally considered to be 'faithful', or 'vanilla'. The most common faithful engines are QuakeSpasm (easiest to setup, has raised limits but no new effects---VERY common and widespread), MarkV (faithful with some added features like particles), ProQuake (totally bare-bones), and FitzQuake. QuakeSpasm and MarkV are forks of FitzQuake.

Your first goal before all else is to decide what your mod will do and look like. If you want particle effects, custom HUDs and crosshairs, high-res textures, high-poly models, and other features reminiscent of modern games, then you have two options: DP or FTE. I recommend FTE because the author (Spike) is a senior member on this site who knows just about everything there is to know about the Quake engine, and always gets involved and answers questions to people's modding problems.

If you plan to make a simple mod that stays close to the original Quake formula (like Quoth, for example), then you should try to ensure your mod will work with all the common faithful engines. Barring that, at least ensure it runs on QuakeSpasm well, as most people seem to use this client.

My second word of advice is do not dive right in and try to make your mod your very first project. Been there, done that. Start with small things, like modifying existing weapon behavior. Learn the inner workings of the game code. Play Quake and ask yourself things like: when I click, how does it know to fire the weapon? When I step near a door, how does it know to open? When I shoot a monster, why does it bleed? How does it know to change animation frames when a monster dies? All of these things are coded in QC. You should track down this behavior in QC and you'll learn a lot by doing that.

Lastly, head over to Inside3d.com and find the list of QC tutorials. Find ones that grab your attention and do the tutorials.

Good luck, don't be afraid to post any questions, even beginner ones.

[TheKillingJoke]

Some Nice and easy Tutorials can ne found here: http://www.insideqc.com/qctut/

Well at least they helped me to get some basic knowledge of some Things.

[soso]

Awesome write up Dutch that really clears some things up, and yeah I can totally see where you're coming from with the don't start with a project first. I've been reading through the vanilla QuakeC source and making some changes just to see how things change and I can totally say that it doesn't always work the way I would have expected. Certainly not from the C perspective.


Might I ask what are the major differences between Darkplaces and FTE? Like do they share similar systems or work rather differently?


Also, thanks for the link TheKillingJoke!


Oh and is the Vanilla QC even a good starting point for a mod or have people made better bases to begin with?

[Dutch]

The Scratch tutorial that you will find through killing jokes link above is handy, in that it removes everything from the code base the engine doesn't expect to be there. This is helpful because you realize that everything in QC pretty much ties in to a dozen or so functions. I wouldn't recommend doing this for a simple mod, but as a learning exercise.

Regarding your DP/FTE question, there are guys who can answer that better than I can. They share many of the same features but in my experience and from what I've read, FTE is a cleaner package with better code. I recommend NOT starting off modding for these engines, they handle things a lot different. Start your mod for a simpler engine, as it grows you will realize what you can and cannot do with the engine and may decide to dedicate your mod to advanced engines later on down the road.

[Spike]

Firstly, they're modules, not dialects.
[NQ|QW]SSQC, [FTE|DP]CSQC, MenuQC.
SSQC runs on the server, CSQC runs on the client. MenuQC also runs on the client but starts up instantly and doesn't get restarted on map changes (also much more limited).
While you can make an entire mod in csqc (check my 'purecsqc' mod), doing so means that you lose any and all multiplayer support, so its generally not a good idea to try.
The engine provides a similarish API for each module, or at least there's a reasonable overlap... However, as a general rule, CSQC code tends to be more procedural (with much more engine-side state) while SSQC tends to be almost entirely OO where most state is stored inside entity fields. Just be sure to include the correct defs/extensions file...
A while back, I wrote https://sourceforge.net/p/fteqw/code...txt?format=raw as a primer for people wanting to write csqc mods, but it assumes you're familiar with ssqc and coding in general. Others have done the same thing, eg: https://icculus.org/~marco/quakec/csqc/ Stuff for [ss]qc is typically older, hence the 'QuakeC manual' Dutch linked. Just remember that as with most OO, the engine does a whole lot of crap hidden away from you, including physics.
menuqc is really badly documented. its entry points are different, but its builtins are not that different from csqc's 2d drawing ones so it shouldn't be too much of a nightmare.

Regarding engines, there's 4 choices:
1) FTE[QW]. Mine, so I'm biased. Its CSQC is awesome and can do pretty much anything.
2) DarkPlaces. Its CSQC is a bit lame, but its SSQC should be okay.
3) QSS. Also mine. Basically just regular QuakeSpasm but with a range of extra ssqc extensions.
4) Generic... vanilla/quakespasm/fitzquake/markv/etc. These engines don't offer anything for QC modders, at all. Maximum compatibility...

FTE runs pretty much everything, usually even stuff made for DP (with some cvar tweaks). It has presets that approximate other engines, even software-style rendering.
DP can't run QW mods. Has limits on the maximum progs size. Its pretty much impossible to get it to look like regular quake. What it does support is generally special-case stuff that requires lots of hacks to get any real versatility, although assuming you're using only that special case stuff then it can be a little simpler (eg: its shader system only supports a single pass, etc, and makes up other stuff instead, which results in problems for other engines biasing people's opinions of them, grr).
FTE has a compatibility mode for DP's csqc code. If you want to target both equally, then you should probably aim for DP and thus get both engines interpreting things more similarly. You'll find it more annoying, but it should ensure that workarounds for DP's quirks don't cause so many new bugs in FTE. Lowest common denominator and all that. That said, you'd be surprised with what you can get away with using just ssqc, and you don't really need to get comfortable with both main types of module right from the start. This isn't me saying that csqc is harder, but it is larger so focus on ssqc first as that's still the most important module.

FTEQCC isn't the only qc compiler around, and by default they can all compile any type of module interchangably. However, fteextensions.qc includes various keywords that only fteqcc understands, and only FTEQCC supports FTE's extended instruction set, so if you want ints/pointers/massive mods/etc, you need fteqcc+fteqw.
FTEQCCGui combined with FTEQW allows for breakpoints and single-stepping through QC code etc, Personally I dread the idea of making a mod with anything else. That said, for your first mod I wouldn't recommend trying to target anything more than QuakeSpasm's feature set, but running it inside fte instead means you can debug it more easily.
FTEQCC adds a number of new keywords, so okay, there are different dialects... Any reasonable qcc will accept c-like syntax, including for statements etc. There may be disagreements between compilers, but vanilla or c-style syntax is unarguable and thus pretty much universal (where the qcvm can actually support that c-syntax, anyway).
interesting fteqcc pragmas:
#pragma srcfile "foo.src" -- chains compilation to also compile the named .src file after (handy for multiple modules).
#pragma target FTE -- tells fteqcc that its okay to target fteqw only. This gives it access to more opcodes, enabling pointers and ints and accelerating arrays and stuff.
for fte, one of fteextensions.qc, csqcsysdefs.qc, or menusysdefs.qc should be included as the first qc file of your module. This ensures that the resulting crc matches the expected module type. You can then remove any conflicting/wrongly-defined builtins from defs.qc. If you wish to instead use dpextensions.qc then you need to include that after your own defs.qc. You can use both, but you'll have to resolve any conflicts yourself, and fteextensions.qc includes all the parts of dpextensions.qc that fteqw understands anyway, but it may be handy to have both to hand as they have different documentation styles (even if you're exclusively targetting one engine and not the other).

One possible learning exercise is to take the vanilla sourcecode and work through the warnings that fteqcc/etc report, fixing them all.
Then you can go through qip's bug list and fix those... which will be more fun...
Its then typical to make a few fancy new weapons, like homing rockets or something.
And then you can throw it all away and start on something that people actually want to play.
If you're comfortable with C, you can always dig through the engine code to see what each field/builtin/etc actually does, although I'd like to think that there's enough documentation already... And by documentation I don't mean engine source, for once.
but yeah, dig in, have fun with it. make stuff change randomly. game programming is quite visual stuff, just be prepared to start again once you're comfortable with what you're doing.
If you want to know about something in detail, just ask somewhere (but please try to ensure you don't ask vague questions that take longer to answer than ask...)

[soso]

Wow thank you all so much for your help, and sorry Spike if my questions have been rather vague so far but you guys have been acting as the flashlights for somebody was rather lost in the dark.