QuakeC framework for indie projects

[motorsep]

Has anyone thought of making a complete, solid QuakeC framework for indie projects using DP engine ? (close-source offered for a fee or GPL)

Something that a developer could grab and build upon. Something like Quake's qc code, but with menu qc, csqc, etc.

[goldenboy]

Yes, one of my goals with my current game is to establish a solid technological base to build future games on. The codebase is called "Salvatrix." I'm writing the code with an eye on keeping it easy to read and modify.

Salvatrix has common RPG features (quests, skill tree, random loot etc.) in addition to FPS features. It also has a mouse-driven CSQC GUI, real rotating entities, and all kinds of other stuff. It will also have things like cutscene cameras and platforming.

The tiny difference is that mine is targeting FTE (and Q3bsp - my code expects things like origin brushes), not Darkplaces. Currently Darkplaces does not run my csprogs.dat (and it probably can't run the progs.dat either since it uses pointers.) The code might use even more FTE-specific features in the future.

I took down the git repo a while ago because I'd like to finish my game before I release the source. Salvatrix will be released alongside the first game that uses it - Scout's Journey.

Its license will be GPL.

[motorsep]

Why did you choose FTE vs DP for your project? (just curious)

[goldenboy]

Why did you choose FTE vs DP for your project? (just curious)

I had worked with Spike briefly during the previous project (Remake Quake) where he added CSQC support to that engine and provided all kinds of helpful feedback. When I dropped out, I initially ported some of my levels to the QFusion engine (Warsow) mostly because of the FBSP map format (512x512 internal lightmaps, lightstyles.) However I was drawn toward Darkplaces/FTE because I had a whole host of legacy QuakeC code from the old project, and QFusion uses Angelscript (IIRC.) At this time, a lot of the old team was still hanging out in some IRC channel, so I was talking to Spike regularly. A few days or weeks later, FTE got support for FBSP, and Spike was also working on heightmap terrain. I tested his heightmap terrain in a few small levels. Some of my levels had a LOT of terrain so this looked like the perfect fit at the time. FTE also allowed me to use my legacy QuakeC code.

I've been using FTE ever since. I think Spike is just a cool guy, and we seem to get along. Spike is also immensely helpful and likes to share his massive knowledge.

What I like about FTE is especially the open-mindedness towards absolutely crazy ideas. Other engine coders I've worked with were often opposed to adding new features. FTE is the opposite of that. It has been called the most promiscuous Quake engine. It supports a few things that other engines don't. The fact that FTE runs several games (Quake 3, Hexen 2) is also a plus since developers can use those games' engine builtins and extensions instead of just Quake's. As an example, FTE supports Hexen 2's hub system and Quake 3's shader language, areaportals and the like. I also like FTE's approach to shaders - everything is a shader. Plus I can extend its functionality with GLSL shaders (which DP probably supports, too.) Other cool things are the Google chat / voice chat support and the experimental walking-on-walls and portal stuff. One of my levels will probably include some gravity switching eventually.

My codebase uses pointers and directly allocates memory from QC in at least one place where it deals with copying structs between arrays. My game also uses multi-stage shaders which DP doesn't support. Another incompatibility is the sending of messages between SSQC and CSQC; FTE provides a way to use multicast() for this (apparently from Quakeworld) which DP doesn't support. I could probably port my codebase, but it is just additional work. DP also does not support FBSP. I don't want to use external lightmaps atm because the external lightmaps created by the q3map2 compiler are buggy.

A drawback with FTE has for a long time been that it is less stable than Darkplaces; however, a large amount of bugs have been fixed, have workarounds or are in the process of being adressed. Bugs are just the price for the engine's very active development.

FTE really has seen tremendous development in the last couple years.

[motorsep]

Aye, thanks for the break down. Interesting insight.

[mankrip]

I've thought about doing something like that, but for teaching programming and game development to kids.

[ceriux]

id personally just like to see a bit more of the scratch qc tutorial to be finished.

[motorsep]

tutorials aren't gonna replace solid and working framework.

[Spike]

I started working on a menu system/framework for csqc/menuqc a while back. However, I keep getting distracted and going crazy with random weird junk. Its not really ready for public release yet as it still contains a few crazy things - if other people are going to take it on, they'll not want to have to fix all the things that I was too lazy to bother with.

It does highlight one issue: the code targets FTE primarily, DP users will probably want to rename/add/delete menu items to match their preferences. This *should* be fairly straight forward, but does require knowing all the various cvar names that they actually want to the user to see.

My menusys stuff also includes a 'goodies' directory which is meant to contain various code samples for crazy things, both to show how to do various things, as well as to inspire people into actually accepting that these engines really can do those crazy things that they might want them to do. Not all of the files in this directory are expected to work in DP.

there's a 'public' project here that is based upon a wip version of the menusys code: http://triptohell.info/moodles/junk/pourtall.pk3 (if you actually run it, you'll see why I said 'random weird junk' earlier). Yes its a pk3. Source for the mod is included inside it.
Yes, its a random mod with extra added crap. This means if you take the code now then you're obviously on your own instead of me getting complaints that its awkward to patch it to whatever latest version later on.
Regarding DP, the menusys stuff itself in here should work fine, but don't expect the csqc (or ssqc, for that matter) to work in DP - while the core menusys stuff is meant to work fine, the rest of this mod simply depends upon FTE-only features. you might also need to set dp_workarounds_allow 1 to enable detection of whether dp workarounds are needed. Yes, I'm also using menusys mod to highlight differences/bugs between DP and FTE. Naturally, versions that I've linked to LH are all pre-configured to exhibit all the issues that I feel are issues with DP, instead of hiding them by working around them (which just results in them getting ignored).

I need to get on with finishing it all. I just lack the motivation cos I'm lazy or something. Or paranoid. Its unfinished. Did I mention that part? Don't yell at me if it wipes your harddrive and kills your girlfriend!

[ceriux]

tutorials aren't gonna replace solid and working framework.

why not? a scratch source with everything it already has, plus a basic weapon or two. maybe some moving platforms and a simple ai monster. i could see it being great for starting an indie project.

maybe redo the quake hud or a basic hud in csqc to go with it, some menu.qc

if there were some kind of non 1.06 qc for indie projects i dont think everything should already be done for you.

also a fte,dp, and vanilla build would be awesome. i say this a lot on my posts here at i3d, but if i knew how to do it myself i'd already have done something like it and released it.

[hogsy]

Interestingly we've developed a simple framework that much of OpenKatana's actual game-code has been structured around, the only issue here however is that all our game-code has been written out in C so I'm not sure it could easily be translated back into QuakeC without losing some of the benefits of the framework. When we initially started on the project and were still using QuakeC, I could definitely see the need for a basic framework that could be used as a basis and we started writing some stuff out but deemed we'd have greater advantages in how we could structure the code-base from writing it all out in C. Amusingly even the Unreal community has been pretty good at developing some basic frameworks in UnrealScript for others to use and additionally this really wouldn't take very long to achieve either, so I'm surprised this discussion has only just arisen.

[motorsep]

No joke hogsy :roll:

We've developed and released Steel Storm 3 years ago, and that's when I wished there was a framework. The main issue is menu QC having no doc, csqc having no docs.

Anyhow, tutorials / docs are welcomed by programmers. However, indies who are artists would benefit from out of the box framework. I have been working with idTech 4 and it's a pleasure to work with (although it not ue4), from artist perspective. So some ideas could be taken from idTech 4 and applied to QuakeC framework.

Oh, and while I am in the spirit of GPL when it comes to engine code, I am not when it comes to QuakeC written from scratch. It's quite useful to keep it closed sourced for commercial projects (source could be released to the public after game's life cycle is over). That being said, I'd love to find an indie dev who is like minded, uses DP or FTE (if using FTE, then QC code should be made DP compatible) for a commercial project. I have a menu QC menu framework with layered menu items, menu screens, KB/mouse/gamepad(not 100% sure about that one) support, sliders, vertical screen sliders, etc. which I like to turn into universal p'n'p QC lib that can be easily expandable.

[gnounc]

Glad to see I'm far from the only one who wants to see a solid quakec framework.
I've been trying to slowly work my code towards that from many angles. But computer issues and lack of focus have hindered me considerably.

I'm hoping to eventually see a qc base with client side things like skeletal animations, and physics seperated out cleanly.
Also some standardized csqc for server admin, mapvote, team rebalancing, voip, text chat, buddy lists, that sort of thing.

I should be getting a new pc later this year, and I really hope to make some headway.
But I'd love it even more if somebody gets there first : )

[goldenboy]

The thing is that it is just a headache to make things work on FTE *and* DP, at least when it comes to doing stuff like a CSQC inventory and similar more involved projects.

I can't really enter into a collaboration to create *another* QC codebase because I'm too busy writing my own... What would people want from it, anyway? Just a basic FPS? We already have that, you can make an FPS with QC 1.01. So I guess it would be "basic FPS features + CSQC GUI (for an FPS) + custom menus" and on top of that? I don't know.

Someone who wants to make an RPG-FPS with dynamic AI factions / AI director and stuff like that would need more than an FPS framework. A lot more.

Someone who wants to make a sidescroller platformer in CSQC? Different framework again.

Also, should it be written using classes? Or is that not newcomer-friendly enough. Hard to say.

Perhaps the most reasonable bet would be QC 1.01 (this gives you the FPS base) + some kind of CSQC GUI/stats kind of thing + a small custom menu. But that leaves a lot to be desired in case someone doesn't want to make an FPS.

[ceriux]

maybe stuff like this?

basic weapon
basic player stuff
basic ai
basic stuff like doors / platforms
basic csqc hud
basic menu.qc

all very plane and simple that way the game isnt already coded for the developer but enough code there to say "okay this is how this is done." leaving everything else for the developer to add on to.

if someone could make stuff like this. i could possibly even find the time to make some simple models and or map/textures to add into a development pack .

(id also have to suggest if one engine had to be decided on it would have to be FTE simply because of network code.)