Well, my initial idea was to grab Quake's QC code, clean one (1.06 by Tremor), add proper weapon system (animation wise), csqc HUD, csqc effects (particles, shells, etc.) to offload networking bandwidth, menu QC (since it's a separate .dat in can remain non-gpl), adjust animation system to use IQM models and there we would have a basic FPS framework.
I made weapon animation system with reloading and all that, for one weapon. But since I am not a programmer, I got confused with the code and dropped it
As far as skeletal animation, it works as is, but since neither per bone control and ragdols haven't been tested / used, and there is no tool to set up ragdolls, I'd advise against using either in DP/FTE. It looks cool, but pain to setup even with tools, not to mention code all the back end of it.
well, I've done most of the menuqc part at least...
a csqc hud isn't exactly hard, although as you'll want to customise that to match your mod anyway, I'm not entirely sure what a framework can actually provide.
csqc shotgun/nails/rockets are part of what csqc was originally envisaged as doing, the issue however is that for this framework to be generally usable, it needs to contain *only* csqc such that it can be dropped in. It can use tutorials to add ssqc stuff, but that will still restrict the extent of the changes possible there.
skeletal animations tends to require some worthwhile skeletal models. none that I've seen really provide the animations that are required for a decent example of it (or even to test the framework code properly). or maybe I'm just making excuses. The previous point is especially painful here - the ssqc needs to be heavily modified for any of this stuff to be even remotely clean.
with builtins like frameforname and frameduration, once you have one weapon animation implement, you presumably have them all.
any sort of ragdoll code will require configuring the various bodies+joints of the doll. there's simply no way around that. doing it via entities was never a practical idea, I agree, and yes, a nightmare. With FTE you can actually enable ragdoll by writing a .doll file (text format... sorry) and setting the ssqc's entity's frame to |= 32768;
If you're refering to the code that xavior wrote for you, then yes, that was an absolutely insane way to do it - but what other choice did you have at the time? I think that was what gave me the motivation to bother testing fte's csqc ode support properly, and certainly helped push me towards doing the 32768 thing too...
Anyway, the jist of all this is that the issue with frameworks depends upon the expectations of the people using them. Most people around here seem to me to want to be able to continue using their existing ssqc code (often people already feel they have a heavy investment in it, and don't want to feel like they're starting from scratch). The people joining the community that I've spoken to seem to want something small they can expand from, and have unfortunatly heard horror storys about csqc having no docs etc, and tend to want to focus on the bare minimum - ssqc. The remaining few mods are so different from quake that a quake-like framework simply won't do much for them (and yes, I regret that there are not more resources to help these guys, 'luckily' they're the ones that will need to learn it all for themselves anyway - or at least one of their programmers will), as a result they're hard to support - all we can really do is provide a few good examples... And that requires stuff.
For comparison, Unreal Tournament (I've not seriously looked at any more recent version, but I assume they're the same) supported mutators - multiple sets of gamecode all running in a single VM. As such, things written for that engine _NEED_ common viable frameworks in order to avoid conflicts/hacks/bugs. Quake never supported that, it is not traditionally object oriented, there just isn't the same motivation for such colaboration. Which is a shame.
That's why I think it should be modernized Quake framework. People, especially the ones who don't code, can build upon it, and showcase their work to attract programming talent to their team. Also, Quake's code is quite simple, so programmers who haven't modded Quake (surprise - most programmers I've dealt with have never modded Quakes ) can get acquainted with it in no time.
Another reason to roll with Quake is that it works. People don't need to worry if framework author didn't design it properly - it just works.
I've seen a ragdoll test by Spike that seemed to work very well. Including this stuff in a framework is a way to make it more accessible. Bring it from the realm of myths into reality.
Also imo any framework that just contains a player, a gun and an AI in a first-person context is an FPS framework... and that is exactly the stuff that QC 1.01 also contains (and is genre specific.)
A custom menu is just icing on the cake. A menu doesn't make a game, it's one of the things you might add after your base game is working. SJ doesn't have a menu yet because of this. From my own perspective, the most helpful thing there would be something like a simple example mod.
A CSQC framework should probably at least include:
- How to draw images and strings
- How to setup clickable/interactable zones on the screen
- Mouse cursor support with mouseover effect
- Mouse drag and drop between zones
- Scrollbars / selectors
- How to capture player input (perhaps a code lock example?)
- How to send and receive data from SSQC (multicast/sendevent roundtrip)
- How to update stats from the server
- Clientside entities, particles
Optionally:
- Custom FOV, widescreen support etc
- Camera perspectives
- Projecting / unprojecting, creating polygons on world objects, something like Doom 3's GUIs
- Screen overlays, postprocessing
- Multiple views, consoles
One thing that I haven't got a good idea about how to do it is text-based dialog fields with automatic line breaks and clickable links.
I think physics objects using ODE also should become more of a normal thing in Quake-based indies and modding, and a framework is a good place to make this more accessible to the public. I've documented how to create simple physics objects in FTE, it's really not that hard.
Also truetype fonts really should see more use. Quake's console font is an eye strain.
If those non-vanilla things aren't available in a framework, then anyone who wants them is again left on their own, just like they are now.
I think you are missing the point. Framework is not needed to just build off it. It's needed so people could make "quake" an release it commercially. Build up some cash and evolve codebase by hiring a programmer or researching the subject on their own. Having bare bone framework isn't gonna help. There is also no need to have all csqc goodies in modified Quake's codebase.
No one will use DP or FTE for a commercial project because all these things we've talked about. No one wants to spend a year or two figuring out QC code. However, chances for these engines to be used commercially are higher if artists can jump start it using out of the box game code, which is Quake.
There are higher chances for a new blood in the community to start making several frameworks with all the goodies, because the 'old' blood busy with their own projects.
There's a few things I think that are important that a framework needs, the first being the most important; documentation.
Secondly, I think somewhat expanding on what motorsep just said, there should be an example game built upon this framework too so that people can easily delve into it and make small modifications if they're looking to do something simple, and creating an example upon the framework would actually be incredibly useful mind you since it'll give a better idea of what the framework will need in order to remain as the reliable base for a game itself. I think there needs to be a level of abstraction between the two...
) can get acquainted with it in no time.