Even if you develop your engine based on Quake, would an indie dev be able to sell it? Surely zenimax would get really pissed off about it? 

It's still under the GPL, so no problem. 

Your competition is DarkPlaces, QuakeSpasm, FitzQuake, and the like. The only thing your engine has going over these appears to be the software renderer. But I also expect that using it comes at a cost of performance and platform availability (no Mac OS X, for example). I'm really not sure if the software renderer is enough of an argument to sell an indie dev on your engine.

Regarding a timeline, I understand where you're coming from, it's the same with me and TrenchBroom, but for different reasons. That's why it's free and open source. No one can, and no one does, expect me to make promises as to when a release happens, and what features it contains. You on the other hand want money, but without any commitment. That's not gonna work for a lot of people I'm afraid. It's also why it looks like you wanting others to fund your hobby projects. 

Asking people for sponsoring a hobby that leads to public products is perfectly fine and pretty much what Patreon is. It's a hobby for the receiver of the monetary support, they can justify extra time investment or feel rewarded. It's 'paying' for something nice for the patrons. 

Spirit is basically right. Mankrip is doing exactly what patreon was designed for... it's literally the reason it exists :P 

If mankrip were making a commercial-like product he wouldn't be asking for donations at Patreon.

I don't think it is fair to compare a hobby project to a commercial-like project. 

In this case I believe Strafe 1996 is communicating perfectly to your audience.

Sleepwalkr, patreon is not like crowdfunding. Though I agree there must be a clearer quid pro quo in this case.

I feel like giving some unsolicited sugestions, bare with me: maybe we need more project management here; maybe it should be a code refactoring/doc project, aiming programmers, something like Quake Code Bible. Is there onde already? 

software renderer .. (no Mac OS X, for example*cough* Mark V has a Mac software renderer. 

Though I agree there must be a clearer quid pro quo in this case

... to be more successful, to get more patreons. 

I didn't understand the nature of Patreon. But my other objections stand. 

Typically, Patreons WILL get something in return tho. In your case, maybe you could do a weekly stream or something where you work on the engine in real time and interact with people? Like Handmade Hero does... 

The last bit is also important, because I'm not aiming just for the presence of the features. I'm also aiming to make their behavior consistent, and that's important because the vanilla software renderer behave in awfully inconsistent ways (particles becomes _smaller_ when you zoom in, for example). I just don't know how to make that clear in a more concise way.

As written initially it's a bit vague and leaves people wondering what exactly you mean. Just saying features will behave consistently no matter what screen resolution you are in will just result in a "ok...so what?" reaction.

Giving an actual example of what it fixes is much better. However, details of minor bugfixes like that should probably be left for a seperate section which just lists (in concise bullet points) what it does differently to vanilla quake. 

there are some good ideas about Retroquad. The idea of a quality modern software renderer. The idea of refactoring and documenting a legendary engine's code. The idea of running this legendary game/tech on Android. Lot of potential to explore. 

You get a func post. 

The Func crowd is composed of critics, and rightfully so.

Criticism is the aspiration for excellence.

Although there is no bad "publicity", unless it is specifically criticism and high standards you are looking for, this may not be the kind of feedback you are looking for.

[Translation: when I've posted about highest standards "completed and tangible" projects here, it has gone well --- the others, not very well. I wouldn't even think of posting about a work-in-progress here unless it was very clearly known to be such *AND* I needed a mapper's point-of-view to complete it correctly.]

/Free internet advise. Probably no better or worse than other "free internet advice". Haha ;-) 

However, what's being criticized is not the engine; it's the proposal.

Anyway, if I have to justify it, that's because it was rejected.

I won't dispute this anymore, Right now I just want to write the engine, and writing about it won't help with that. I'm happy with how it's shaping up, and that's enough for me.

Thank you all for your solid reasoning. I'll keep to myself from now on. 

There is lots more to the Quake community than just the nitpicking know-it-all func people. 

Nitpicking is good. The problem is that there's no way to properly nitpick this project yet, and I didn't realize that before. 

A Few FTE-related Questions [EDIT]

Posted by babgo [189.62.72.238] on 2015/12/22 14:46:01
I'm trying out FTE and i ended up with a few questions about the engine.

1) Does it still have a software renderer? How can i enable it?
2) What's the difference between full and minimal OpenGL clients?
3) I've seen some browser versions mentioned. Is that emscripten? Does MP work, or only SP?
4) All rendering in FTE is done through shaders? No fixed pipeline crap?
5) I've seen this engine/common/com_phys_bullet.cpp which seems to be an integration with the Bullet library. How can i enable and explore this feature? Is it available from QuakeC?
6) I've also seen engine/gl/gl_heightmap.c. How can i create a map with terrain?

FTE seems to be an undocumented gem. There's so many features hidden in the code! I'll keep researching and reading more about it. 

1) there no software renderer any more. the 'vanilla' preset gives a faithful enough reproduction via the gl renderer.

2) minimal builds lack a load of optional extras, like the server parts, q3bsp, etc. basically the stuff that you don't need if you just want to play quake on the vast majority of public servers.

3) fte's browser port is compiled with emscripten, yes. there's no real access to udp from web browsers, although it can connect to servers via websockets.
however, this requires 1: a server with sv_port_tcp set. 2: adhere to all the cross-domain blocks that browsers insist on implementing. this means that the only real way to use it would be if someone wrote a proxy. which would suck even more for latency.
so yeah, practically speaking its singleplayer only (you could bind some keys for splitscreen play, but there's no way to deal with multiple mice).

4) webgl support demonstrates that fte can do all its rendering without any fixed pipeline crap.
it can still fall back on fixed pipeline stuff for old devices, but this tends to disable a load of stuff like shadowmaps.
FTE's usage of the word 'shader' refers to q3(+extensions) shaders. All the built-in shaders pull in some glsl as required, and it make some stuff up as it goes along if the shaders neglect to specify any glsl, if fixed pipeline stuff isn't usable.

5) bullet is some experimental feature and is mutually exclusive with ode support (fte's ode integration is more feature-complete). both require extra dlls - ode is partly built into the exe and just needs a libode1.dll (check the 3rdparty zip iirc), while bullet requires some fteplug_bulletx86.dll which is not publically available in a pre-built form due to it being significantly feature-incomplete compared to ode.
this stuff is available to qc, but is a bit too unreliable (with both ode or bullet) for actual use. stuff tends to fall through walls if you're not really careful with it.

6) there's two ways. the original way is to use 'mod_terrain_create foo; map foo' and then paint stuff with the csaddon.dat thingie (some csqc-based editor util thing - you should be able to find a copy on triptohell.info/moodles).
the other way is to just copy the various terrain-specific worldspawn fields from that foo.hmp file and place those into a bsp 'shell' map, and then use csaddon to paint it again.
be warned that both terrain and csaddon need a bit more polish.
obviously, other engines have no chance of displaying any of this stuff properly.

7) play with the apropos command whenever you can't remember the name of a cvar/console command (or want to see if one exists with some word in its name or description).
some cvars+commands will display a description of what they do when you try tab-completing them at the console.
check fteextensions.qc for similar things in regard to qc extensions. the descriptions may be a little terse but they should usually be enough to guide anyone that is vaugely familiar with the functionality.

8) this forum generally favours big huge topics with lots of cross-talk over lots of individual threads, hence why your topic got moderated the way it did.

@spirit.
oops. :s 

It's sad that the software-renderer is gone. What's the latest SVN commit with it? I wonder if i can fork it and remove all the GL stuff. 

FTE 3343 had the software renderer:

http://sourceforge.net/p/fteqw/code/HEAD/tree/tags/build_3343/ 

What is the best software rendering engine in terms of the ability to play modern maps and faithfulness to the proper DosQuake/WinQuake look?