Doom3world

As you might know we developed and released Steel Storm using DarkPlaces engine. Tomes of Mephistopheles is in alpha stage and Steel Storm 2 is more in the concept stage (although some coding had been done). I love DarkPlaces, but lately I had a feeling that eventually we have to depart from it for various reasons. Even DarkPlaces author mentioned that Doom 3 is a very solid out of the box engine worth looking into.

However, I have a lot of questions.

DarkPlaces features are listed here: http://modding.kot-in-action.com/

I am thinking that maybe Steel Storm could be moved to Doom 3 engine. Areas of concern are GLSL shader (the game has to look like anime manga or at least the way it looks now with DarkPlaces http://steelstorm2.tumblr.com/ ), ourdoors, AI.

Can Doom 3 handle outdoors as big as DarkPlaces can handle ? (http://www.youtube.com/watch?v=2GmiQsKYPdw 130k x 130k NetRadiant units at 70 fps with per pixel lighting in DP; no enemies or models ofc)

Assuming the game is FPS and not whole a lot different from Doom 3 (just faster pace, not a horror but rather sci-fi action), what would it take coding wise to get it going? (I am not a coder, but I was able to code base mod for Steel Storm 2 in QuakeC)

Is Doom 3 game logic code under GPL? (would I be simply able to build commercial game using Doom 3 with its game logic)

Thank you.

If you are talking about .scripts, they are not GPL.

I don't know Doom 3 engine, so I mean monsters, weapons, triggers, etc.

Too be honest if I was developing games with a smaller team and nothing too crazy I would just use Unreal or Cry-engine 3.

They will last you a long time in terms of technology so you don't need to keep migrating and flushing your development pipeline. If you went with Doom 3 now you'd probably have to go to one of these engines in the future anyway.

At least with the UDK you can dump any spec friendly games to the iPhone or iPad within the tools with one click.

Unreal is faster at prototyping any gameplay you want, it's fast to make content for etc.

Doom 3 is really tool old to make any retail game on because you'd need to add a lot of features to it tech wise which other engines already have, and for some time. I use Unreal at work and it's really sad to come home to Radiant to make stuff, it's just so old. In saying that it's still fun to play with old tech and see where you can go with it, if you're just modding or making a map it's ok.

Doom 3 scripts are just uncompiled c++. The existing scripts do not fall under gpl, which means id still owns them. You could easily write new scripts if you have a half decent coder, and weapons scripts/def could probably be trivially modified from the id ones to make them your own. Of course any textures/models/sound are still id IP and hence of bounds but you already knew that.

Triggers, moveables etc are handled in editor and are gpl, there wouldn't be much point if they weren't. I wouldn't worry about this stuff. Your main concern is going to be getting the engine to run such a large world smoothly. While et: quake wars proves that d3 CAN do it, it really is a whole different kettle of fish from darkplaces, because darkplaces has precompiled lightmaps whereas d3 of course has real time lighting. Imo d3 is not the ideal engine for large outdoor games, at least not in its current incarnation due to lack of proper distance culling and LOD model handling.

As for the cell shading, its no problem and has been done before. See image. There are other rotoscope shaders as well, and I'm sure your team can roll your own.

Most of the QuakeWars megatexture stuff is very close to being identical with the megatexture stuff in the d3 gpl code. If you can wait a few more weeks if you need a large world support idtech4 cdk supports Virtual Texturing up to 65k x 65k with a build in paint tool. Just going to take a couple weeks to get everything 100% but the base implementation is there and working.

blackenmace.com.

Megatexture isn't the be all and end all of open world games. Like I said, there is no LOD support for models. Cryengine and udk use a bunch of optimisations to make huge view distances practicable. I don't think stencil shadows in their current incarnation are really amenable to huge polycounts; there are bottlenecks and wastage on today's multi-core CPUs.

I know yourself and probably others are working on gutting stencil shadows completely to replace with deferred rendering but I'm merely talking about the state of the engine out the box.

Well, DarkPlaces has neither LOD nor any culling for wide open areas. That level you saw on the video is not going to work with AI, models, props, etc. That was just a test. I am looking maybe for max 20k x 20k open terrains and that's still iffy. Plus having huge terrains you need to cross entails having vehicles. And at this moment there might be no vehicles.

I am pretty flexible about environments. If I really have to stay away from outdoors, the game will take place indoors with some small pockets of open areas.

My biggest concern is coding. QuakeC was released under GPL, so I can simply use is a foundation for any game. I have no clue how it's done with Doom 3 and if there is game play logic that is under GPL.

That cel shaded image looks horrible It looks like inks are just inverted hulls of the models.

Yes but darkplaces makes up for that by having baked lightmaps. Thats a huge difference. Coding is only limited by how good your coder is. You can code d3 to hell and back as evidenced by what people have already done, see: the Dark Mod, The Ruiner, Hexen: Edge of Chaos, Into Cerberon etc.

The cell shading is just a proof of concept. If your game is making heavy use of cell shading, your obviously going to make and tweak your own shader anyway. Here is another one.

http://doom3.filefront.com/file/Rotosco ... _v11;68091

Interesting shader. Much closer to what I need.

Well, QuakeC is pretty easy and since there is existing example of whole game with multiplayer written (Quake) developer can cut production time by reusing the code.

I am not a coder, but was able to code base mod from scratch, with some help, in QuakeC.

That has nothing to do with megatexturing/virtual texturing, last time I checked UDK actually uses clipmapping for there terrain entities, and Cryengine also uses a hybrid virtual texturing approach. Stencil shadows are a waste of resources, and as tech advances what we really need to do is do less baking and more research into compression techniques.

QuakeC would be the D3 SDK and scripts combined. All AI, weapons, level events, sounds, material files (and some other smaller stuff) are plain text files the engine reads while things that require more speed are in the SDK. You can replace script with code if you wanted.

While UDK & Crytek have newer stuff, I don't like the look (a personal thing). Games makes with UDK (well, the retail one, mods & stuff with UDK) all have a similar look to them imho. Kind of like how everything made with Quake 2 looks, in a way, like Q2 or something made with Q3A looks similar to Q3A (Half Life being different here, but they rewrote a lot to get that game, most companies don't rewrite the engine code they bought to that extent).

D3 is pretty easy to get stuff in to (easier then Quake 1 imho). For what you did with Steel Storm: BR, I'm betting it could be done with just script work in Doom 3. For ToM you'd need SDK work and engine code to get the network support to what you wanted (that will be a BIG drawback for you). I can't compare the pipeline to UDK/Crytek but like I said, I prefer the look of id tech.

The other killer part for you would be the game logic. since it's not GPL you would need 100% new (maybe Bloodrayne would help with that as he already has done that for his mod/game).

To my understanding all that is still proprietary



Most Source games look the same. In UDK and CE3 it's just a matter of messing with GLSL shader and since it's not a trivial task, a lot of indies don't do that. Thus you have all games look about the same.



Knowing how to code gets job done with any engine For Steel Storm 2 however it shouldn't be too hard. The major issue is achieving manga look via GLSL shader. ToM is bound to stay in DP, unless I ditch the coder and the idea of random dungeons.



Who is Bloodrayne and I wonder if he is up to commercial game dev for profit share?

Either way, I would like to get somehow models from Bulletstorm / UT3 into Doom 3 and see how high quality art looks like in Doom 3 with new GLSL backend. Plus test performance using whatever mods that boost visual quality are available. Don't really want to jump into a new tech if performance will be on par with DarkPlaces. Note that Doom 3 uses relatively low poly meshes and low quality normal maps (or so it seems).

Thats what makes virtual texturing so appealing is the artists have full control over whatever art style you want to use in your game, rather than having to go in and modify a bunch of GPU code to get that independent impressionist style.

I don't see VT as an essential feature to be honest. Having IQM model format along with MD3 model format (for vertex animations), having portal sky and global illumination are more essential features than VT.

What ever makes you happy but a couple model formats(the ladder being a format thats a bitch to export to), portal skies and baked GI aren't current/future gen features.

I figured

How about base mod for Doom 3 (spawning the player, giving him inventory, couple of weapons, and couple of enemies, simple menu, etc.) ?

What do you mean?

What I mean is if I want to make commercial game using Doom 3 GPL, I would need to write the game logic (weapons, monsters, triggers, AI, menu, etc.) from scratch as apparently what comes with Doom 3 isn't GPL (unless I am missing something; someone said scripts, including AI, materials shaders, audio shaders, etc. are not under GPL).

Here is an example. If I want to make games based on DP engine, I have 2 ways of doing it. Way #1 is to take Quake1 QuakeC code and use it as a base game logic code for my game. I would have to release it under GPL, along with the engine. Way #2 is to rewrite whole QuakeC code from scratch.
I used went the second route. There are some built in functions that have to be present in order for engine to load a map and place player into '0 0 0' of the map. So I created minimal code that loads player's model and does exactly what I described. A framework to speak. Then I added functions that handle player's animations. So I was able to run around the test map and see how player's model was animating according to my actions (idle, run, crouch, etc.) Then I add weapons code that would allow me to spawn with a pistol. Then I added ability to shoot. And so on. So the code is different from ID Software's code. And I don't have to release it under GPL because I created it from scratch (but I am thinking to screw that and use some of the Quake's code to avoid re-inventing the wheel and save production time; I would have to release it under GPL, but I don't care to keep it in secret, so I will do that).

Are you with me on the subject?

The stuff that is in scripts isn't much, and im sure if you contacted Id they wouldn't have a problem with you using the scripts. The lack of GPL on the scripts im sure is just a oversight, I think your thinking way to much into this .



Except in Quake 1, QuakeC handled all of the game logic, where as in Doom 3 there isn't that much thats in the scripts so the amount of work to do something equivilant won't be as hard. But again I really think your thinking wayyy to much into this.