Quake Engine's Commercial Viability

[KillPixel]

This post is directed at programmers (in particular), mappers, modelers, animators and texture artists. This post will likely be lengthy, but I will do my best to stay succinct and not get too tangential, so please bear with me.

A little over a month ago I made this post in which I, fueled by ambition and naivete, declared "I AM going to make a game." After some soul searching and research I'd like to change my statement just a bit: I AM going to make a game IF I can find an inexpensive, capable engine AND produce a commercially viable game ($10 on steam anyone?) in under one year with a small team and a budget of $20,000 or less.

That is a giant if, and I need to know the answer.

THE ENGINE

I've been researching various commercially available engines and their various license agreements. I've learned more on UDK and now I really like it, although I think the license is too prohibitive and the engine itself is more than the project calls for, therefore becoming competent in that complex of a working environment is a waste if resources. Unity 4 is the second runner up, $1,500 for a decent engine? Cool. But like Unreal, it's more than I need. There are various other engines that are similar, but not suitable for the project. Lame. Then I read this, straight from the engine god himself:

The code is all licensed under the terms of the GPL (gnu public license). You should read the entire license, but the gist of it is that you can do anything you want with the code, including sell your new version. The catch is that if you distribute new binary versions, you are required to make the entire source code available for free to everyone.

Excuse me, I wet my pants again, I'll be right back.

Every single thing about that statement makes me giggle inside. This may seem insensitive to some people, especially coders who pour their blood, sweat and tears into a project, but I am very pro-open source. I'd MUCH rather have my engine open than closed, so that requirement to me is icing (and oh so sweet).

THE ENGINE AND THE RUB

Ok, the techno-eroticism has subsided and my heart rate is going back to normal. Now, let's look at this a little more critically.

I've been mapping and texturing, researching (and preparing for) modeling for quake, and I wrapped my around and played with QuakeC. All these things bring up a lot of questions: Here is the big list:

1. What Quake code, exactly, is protected and what is permitted to be resold?
2. Where the hell is the source for the latest progs.dat?
3. What are the fundamental limits of the BSP and MDL formats? (max faces or vertexes, texture info, texture resolution, max animation frames, etc...)
4. Can MDLs be efficiently used for static meshes? Moreover, the liberal usage of?
5. What are the practical limits of QuakeC? How functionally complex can the code be before the fundamental limitations of QuakeC begins to rear its ugly head?
6. How extensible is GTKRadiant 1.5? How easily can it be modified to be suitable for this particular project?
7. There seems to be several methods of modeling, skinning and importing models for Quake, all of which appear to be very ghetto. These methods seem (but I don't really know) nightmarish to use for a project on this level. Am I wrong?
8. I'd want to use a current, but preferably heavily customized source port. With my heavy budget constraints, how feasible is this?
9. Is there, ANYWHERE, in the deepest darkest crypts of the internet, a Quake1 version of ioquake3 and iodoom3?

After asking myself these questions it occurred to me that maybe I should move up a little. Hrm...id Tech 2 perhaps? ...ooh, id Tech 3 looks like it might just fit the bill perfectly. I'd like to steer clear of id tech 4.

Here's a rule I've imposed on myself that I would like to obey: I want to strip the code down to nothing and add what I need, nothing more, nothing less. I don't want a bloated, catch-all engine, I want something tailor made. This is possible because of the low tech and the relatively low complexity of the project.

Trust me, even just the idea of making a game with the Quake engine feels daunting at times, but its somewhat monolithic nature and relative simplicity make it very accessible. I'm really eye-balling Id Tech 3, but I don't know if it would be too complex to deal with and simply too big to strip down and build back up.

So, in other words, I want a custom Quake engine with these features:

1. Support for large, geometrically complex maps with liberal use of high resolution sprites, static meshes and lots of detailed lighting
3. High res textures (although, the design will likely call for a res only double than what is found in Quake)
3. Many animations per model with many frames and limitless duration
4. Higher poly models, double maybe triple, than the ones found in Quake
6. A more robust particle system
5. MORE AUDIO CHANNELS and high bitrate sound

I realize this list depends on several factors: the engine, QuakeC and the BSP and MDL format.

So before I really roll up my sleeves and get down in it, I need to know I'm getting down into the right engine.

THE GOAL

The goal is to make a game. A good one, a real one. After some very careful deliberating I've decided this can only be a possibility in my life if it will at least pay for itself. Therefore, I have to make this a product, not just an artistic expression. That sucks, but that's the way it is. Ideally, I'd be able to assemble and manage a team of 2-3 others. Due to budget constraints, the work likely be contractual and carefully delegated. Aside from myself, I cannot foresee any other team member being utilized the entire duration of the production cycle (unless they volunteer or don't mind saying "pay me royalties if you ever make any money from this"). If I undertake this project I CANNOT just let it end up being another Quake TC or some big mod, otherwise I'm screwed and in debt forever...

Although I've already said it in so many words, here is my goal in summary:

"To create a fun, engaging, high quality, solid PC title built upon nearly 20 year old tech by very few people with little money in a short span of time that is commercially viable."

That one run-on sentence you just read is what I am trying to make into a reality. I'm eager to find out if I can do it.



P.S. I initially intended to have a working prototype and a fairly meaty GDD before making this post so I would be taken a little more seriously. But, it's pointless to spend 3 months making a prototype on an engine I may not even use.

P.S.S I'm going to stop being a douche and upload v0.9 of my fixed quake maps tomorrow. If I recall correctly, there are about 8 known bugs or oversights left to be addressed. woot. I just need to figure out where they are again...lol...

[gnounc]

Oh goody, I got here first.

Okay. Uh somone (I believe it is chip) is and has been stripping down darkplaces to be an engine to suit HIS needs...I'd be willing to bet this version of dp would suit your needs very well indeed.

I suggest you completely forget about quake2 and quake3 as fte and darkplaces can handle pretty much anything desirable from those engines, and have workarounds for many of their downsides.

I also suggest you dont bother stripping an engine down at all. Use fte, or use dp, as they are. Theres probably zero benefit to getting under the hood, its a lot of work and you're very likely to end up creating your own nightmare for something that wont benefit you at all.

Radiant is still being used on AAA titles so...if you're up to the job, it is.

as for modeling, I suggest using blender, export to collada, and use noesis (if you are using windows) to export that to iqm. dp and fte boths upport iqm.

Also fte and dp both have csqc. So you can do lots of 2d work without much trouble. Hudwork, effects, or even a complete 2d game.

also they both have much better particle systems (as shown by seven) and more audio channels.

If you already know quakec and quake mapping, and have a simple game in mind...this is really the way to go.

And let me say it again...because its been said a million times..
Look at steelstorm. that uses darkplaces in a commercial game.

-gnounc out

[Spike]

> 1. What Quake code, exactly, is protected and what is permitted to be resold?

Its GPL. You may resell it, but you have to release source and allow others to resell it also.
If the content is a separate work from the code, the GPL license does not need to apply to the content also, meaning if you sell the content and freely give away the engine/code then its fine.

> 2. Where the hell is the source for the latest progs.dat?

most progs.dat files can be decompiled to some extent, but that's horrible.
v1.06 was the most recent (vanilla) progs release. try the mission packs for later releases.
If you want a real atmosphere for your game, you'll want to replace the hud with csqc, and the monsters are definitely going to be useless. Much of this will be from-scratch.
You can find dp's dpextensions.qc file around the place, or try fte's pr_dumpplatform console command to get system defs for a from-scratch progs, or there are barebones from-scrach mods which don't always employ best practises.

> 3. What are the fundamental limits of the BSP and MDL formats? (max faces or vertexes, texture info, texture resolution, max animation frames, etc...)

the q1bsp format sucks. q2bsp isn't much better. Use q3bsp(which lacks lightmaps) or rbsp/fbsp(which doesn't).
The bsp2 variant of q1bsps will remove any practical limits, but that doesn't automatically make it a good format, just one without noticable limits.

> 4. Can MDLs be efficiently used for static meshes? Moreover, the liberal usage of?

I've a screenshot of fte drawing at least 2000 separate knight models. I know its drawing 2000 knights because its reporting errors about not being able to draw more.
It still manages to vsync (the error has since been fixed of course, but I've not checked to see how many are actually needed to drop below 60fps).
the bigger issue is the lack of precision in the mdl format. Use non-rigged/unanimatable iqm files instead if you want a decent and fast static model format.
However, if you want lighting to be correct, your model must be built into the bsp itself, which requires q3bsp/rbsp/fbsp instead of q1bsp/q2bsp/bsp2.

> 5. What are the practical limits of QuakeC? How functionally complex can the code be before the fundamental limitations of QuakeC begins to rear its ugly head?

General limitations are on the 'numpr_globals' count. xonotic is fecking huge, and comes out at about 20k globals of 65k on full optimisations. there are alternative progs format variations that remove limits much like bsp2, but so far optimisations and improved coding practises have removed the need.
QuakeC (generally) lacks pointers. This means that any object or storage use is restricted to only entities, resulting in heafty ram usage, reduced networking capability, and the need to itterate over these pure-storage entities. A couple of engines provide native support for pointers, which can alieviate this issue.
Fitzquake supports up to 65k entities, DP supports up to 32k entities. I have a patch for FTE that supports up to 4m entities. In all seriousness, if you do reach 32k, you're probably doing something wrong.

> 6. How extensible is GTKRadiant 1.5? How easily can it be modified to be suitable for this particular project?

I can't answer this reliably. I know gb favours greatly radiant, and uses it to create nice fbsp maps. I'm just not sure *which* sort of radiant.

> 7. There seems to be several methods of modeling, skinning and importing models for Quake, all of which appear to be very ghetto. These methods seem (but I don't really know) nightmarish to use for a project on this level. Am I wrong?

Use IQM, and IQM only. Seriously. Use it.
You may still have issues though.
PSK/PSA is an acceptable second/development choice (they are generally easy to export to, thanks to UT), but I'd recommend to convert to IQM for any releases as they can be quite expensive to load.

> 8. I'd want to use a current, but preferably heavily customized source port. With my heavy budget constraints, how feasible is this?

FTE, DP, QuakeForge are all already heavily customized...
For all three, you're probably best off working with the engine project's main developers instead. Give them a list of requirements, and you can probably get some sample code/specs for how to do what you want and an updated engine.
Forking is generally counter productive. LordHavoc necroed a topic on inside3d recently, the fork mentioned in the topic was too outdated to be useful.
You shouldn't need to customize for yourself too much. If a customization is useful to you, it'll likely to be useful to others too, so should be applied to the main project instead.
Code that is not run only really costs at compile time, and the file size. Don't ask about it, and we won't tell you just how many lines of code are sitting idle.

> 9. Is there, ANYWHERE, in the deepest darkest crypts of the internet, a Quake1 version of ioquake3 and iodoom3?

Tbh 'ioquake1' is likely closest to quakespasm. That's not a good thing.



> 1. Support for large, geometrically complex maps with liberal use of high resolution sprites, static meshes and lots of detailed lighting

q1bsp generally has terrible terrible lighting, and the performance just isn't there for large open rooms.
q3map2 (q3bsp/rbsp/fbsp) will have much nicer lighting, and can supposedly do lightstyles also. patches and static meshes etc can greatly reduce batches and boost performance, but beware of the lax vis.

> 3. High res textures (although, the design will likely call for a res only double than what is found in Quake)

double is nothing

> 3. Many animations per model with many frames and limitless duration

the csqc skeletal objects extension allows you to import animations from one skeletal (animation)model and use them on a different (mesh)model.
with csqc bone control, you can blend animations or programatically write your own.

> 4. Higher poly models, double maybe triple, than the ones found in Quake

seriously, use iqm.

> 6. A more robust particle system

dp+fte both have customisable particle systems.
most engines support a range of replacement/nicer effects.

> 5. MORE AUDIO CHANNELS and high bitrate sound

most engines do, when the cvars are set right.

[golden_boy]

> 1. Support for large, geometrically complex maps with liberal use of high resolution sprites, static meshes and lots of detailed lighting

q1bsp generally has terrible terrible lighting, and the performance just isn't there for large open rooms.
q3map2 (q3bsp/rbsp/fbsp) will have much nicer lighting, and can supposedly do lightstyles also. patches and static meshes etc can greatly reduce batches and boost performance, but beware of the lax vis.

q3bsp is still pretty painful, as soon as you have a lot of static meshes in your level the compile time and the size will skyrocket. It is not good for large AND detailed outdoor areas (it's worse at that than Quake 1 is). You still always have to keep visibility in mind to uphold performance while mapping. You're slave to the same machine as in Quake 1, only differently. Same for Doom 3 btw, only it's again different and its visibility stuff is STILL more lax than q3bsp (which isn't good for performance, only for compile time).

You can make good looking maps with a combination of Radiant and (Blender/Maya/Max) - the software isn't the issue in that case. But it will be harder to find level designers / environment artists who are good with Radiant than to find those who are good with Max and UDK.

q3bsp and UDK use different amounts of brushwork (BSP) to create a level; with the latter it is common to create more of the level as models, using an economical modular design. Radiant, on the other hand, offers convenient patch meshes that can be shaped right in the map editor, and you'll use a bit more BSP just because it's comfortable. It's a different style. It's true that Radiant is still used for big productions, however those productions will also have an entire proprietary engine and pipeline that makes Radiant usable like that in the first place. Your best option with Radiant and idtech is either q3bsp or idtech4, both of which are old and made for corridor shooters.

UDK's lighting will be prettier than q3bsp's. Your game will look better. UDK's in-level scripting with Kismet should be nice, while I haven't used it, I have used Cryengine and Flowgraph which is very similar. UDK and Cryengine also allow you to create animations for cutscenes etc. right in the main editor in a very user friendly way. Stuff like that is invaluable.

If you want a good looking game with much of the environments done as modular meshes, and if you want to easily recruit people, you should probably use UDK. There is a reason why it's popular.

If you will be doing large outdoor levels with realistic looking nature, try Cryengine. I have worked with it and it is very good. You will use FMOD designer for sound (unless they changed that?) and Scaleform for the GUI, and it pretty much requires you to export from Max, so be prepared to invest money.

The entire Quake modding scene is pretty dead in comparison, and it is not comfortable to work with, so tbh you should only consider this as a last resort.

idtech4 is another option but personally I don't believe that it's good at large AND detailed environments, even if some people will state that it is. I have yet to see it.

I don't know much about Unity, but I suppose great games are made with it so it must be capable.

Use the right tool for the job. Choose the kit that other, similar games to yours were successfully produced with.

Please get MDL and Q1 BSP out of your head. And don't fall into the trap where you think "I know Quake modding, so I should make a game with Quake rather than UDK". That is dumb. UDK is the better, more user friendly and more mature kit.

[KillPixel]

@gnounc - I think you're right, I felt stripping down an engine could be hellish and ultimately extraneous, I just wasn't sure. I had no idea Collada existed...I will definitely check it out. I also had no idea Steel Storm existed, just bought it and I'll check it out after work. It's cool to see DP used commercially.

@Spike - Whoa, thanks for taking the time to address each question individually, that was exactly what I was looking for and it's very helpful, thank you.

@golden_boy - Damnit golden_boy, why can't you just tell me what I want to hear and not what I need to hear?

And don't fall into the trap where you think "I know Quake modding, so I should make a game with Quake rather than UDK". That is dumb. UDK is the better, more user friendly and more mature kit.

Hrm, that's pretty accurate, I must not be the first person on the planet that you've seen do this (imagine that). I'm aware the trap is there, I haven't fallen in it, I'm just pacing around its edges trying to figure out if I should jump in.

My initial intent was to use UDK (I forgot to mention, I found CryEngine3 to be a very, very attractive option). I acquired over 100 hours of videos tuts and stacks of printed tuts which kept me occupied. I began designing for this particular engine...unfortunately, the prohibitive licenses and costly tool sets started convincing me that this option is beyond my reach at the moment.

My new plan was to put that design on hold and make a good game that can generate income at a low production cost...that's what lead me to idtech. I simply wanted to make a good, SOLID, classic throwback FPS that pushes the very limits of the engine...I can't really see using this engine for anything else. Unfortunately, my heart isn't really in it (at least not to to the degree of the UDK project) which is an extremely dangerous and unwise way to enter a project.

The UDK community is very alive and vibrant and people are always looking for work (which, in a way, is discouraging) so I don't think I'd have to do a lot of hunting for a team (that is, if I present an impressive prototype and kickass GDD).

To more accurately express the intent of this thread the title would be "Please Tell Me The Quake Engine Is Commercially Viable."

*sigh*

Ok, thanks for the reality check. Actually, I'm relieved, in a way that is what I wanted to hear.

Back to square one, I will continue working with the UDK and CryEnigine...

...but UDK's licenses are just so shitty, even if you have 1mil to throw down they just don't give a license to anybody. I have NO body of game design work under my belt...that's what they want.

That means this game will have to be very good to get the attention of investors or the mercy of Epic. I can deal with that.

[MH]

Quake engine viability in the real world is zero - if you are insistent on sticking with the original engine file formats, which suck ****s in hell. The only thing it has going for it is QC, which is a very minor "only thing" and which there are plenty of better alternatives to. But for pure simplicity QC (edit in a text editor, compile on the command line, it works) is just about good enough.

For a new project - don't touch Quake with a 10 foot pole. There are so many things that need to be fixed, and the file formats will kill you. The only atrrraction is nostalgia for the original game.

[damage_inc]

I'll ask your question in a different context: Is creating "fun" commercially viable? I would say yes.
Now, can you create fun? More specifically, can you create fun with a Quake engine? Hrmmm...

I paid 19.95 for this: Mad Skills Motocross it was a blast

Not the most "advanced" game is it! But what "fun" it was If you don't have technology to fall back on, creativity is paramount to success. After that, you'll need a way to advertise your creative and fun game.

Also, if people are still playing Quake today well, there is still some "fun" left in it Jus' sayin'

[sock]

To make a game you will need a lot of extra stuff, model converters, compilers, scripting examples, support forums, active users and testers. Picking the engine is the tip of the iceberg, there is a reason why UDK/Unity are popular and that is because they have the support networks. Quake engines are for hobbies, they are fun to tinker with and there are a few people around who know a crazy amount of information, but the quake engine is not a pro choice.

In your other thread you mention you were going to be doing a lot of scripting, UDK Kismet and Cryengine Flowgraph are amazing tools for game scripting. You can quickly prototype stuff with the visual scripting systems which will save you lots of time before your art pipeline goes into production. Your bottle necks will be resources, modern engines require a lot art assets, animations, effects and scripting to look right.

I would recommend you create a small prototype to see if your idea is fun, use a modern engine like UDK because at least any assets you create can be re-used again. Get your game idea right first, UDK does come with a lot of assets already which will help speed up your prototype phase.

[damage_inc]

WOW, that UDK trailer makes Quake look like pong by comparison! I'm downloading it just to see it in action.

[golden_boy]

In short, while you can build the Notre Dame on your own with medieval tools (if you keep them sharp), it's not necessarily a good idea.

[KillPixel]

I'll ask your question in a different context: Is creating "fun" commercially viable? I would say yes.
Now, can you create fun? More specifically, can you create fun with a Quake engine? Hrmmm...

I totally agree with this principle. The fun aspect is top priority and is what really makes a game, everything else (visuals, sound, etc) is just icing.

Could "fun" be made with the Quake engine? it has before... That's why this option is still nagging me a little.

By "commercially viable" I mostly meant on the technical level and in terms of production.