We're back with a small media update and a note on how the mod is progressing. Earlier this month we finished E1M4 for the internal demo and have moved on to E1M5. M4 was created practically from scratch in, for us, record time. Moving on to the next map is going to be yet another challenge for us as it's a completely different style. The map portrays a dig site with a lot of caverns/ancient styled locations. We have had Gait working on it for some time and now he will be joined by two additional. mappers. There isn't a lot more to say at this time. We're working extremely hard to bring E1M5 up to speed and we'd rather be doing that than writing up devblogs, so instead of a long boring rant we'll throw 5 brand new screenshots at you.
 

 

 






We have taken in a few new members in the last couple of weeks. More to come on these in the future.
 

It has been a while since we finished up a map (E1M2) for the internal demo, but we can now finally add another to the heap. E1M3 was finished up earlier this month. It took us a lot longer than we planned, but the result is pretty good and it lives up to our goal of every map being better than the last. This is a learning process for us. E1M3 brought us a lot of new knowledge and pushed us to our wits end. The map is now playable, complete with puzzles, monsters and mission objectives. Once we kick off the second internal demo phase, we will add the last layer of polish as well as implementing the narrative completely.
Where the first map is pretty linear, E1M3 is a very puzzle oriented level that is bound to cause a few scratching heads. That is how we would like to go. We don't want all the maps to have the same style of progression. We like to mix it up. The method we have used to finish E1M2 and E1M3 has been as follows:

1) The planning of the narrative & layout (this somewhat preceeds the internal demo)
2) Finish the map architecturally. All geometry must be completed.
3) Implement puzzles and obstacles.
4) Make the map playable from start to end.
5) Add monsters and items.

We uniformally finished each stage for the whole level before moving on to the next. The production times for the two levels speak for themselves. It has been way too long. For E1M4 and E1M5 we are going to try a different approach. The problem with the uniform, serial approach is that proof-of-concept is close to non-existant and you get a lot of overhead time working on the correction of something that could have easily been avoided. What we're going to do now is to differentiate the stage progression of each level, meaning that we're finishing at least the first 3 stages for the first areas of E1M4 and E1M5 before moving on. This way we get a much better view of the levels pacing, brushcount and atmosphere. We are going to attempt to keep the level playable at all times, insuring that any tester, mapper or other key personell will always be able to jump right in and get a feel of the level.
 

 
WARNING. Technical rambles ahead:
One of the reasons why the first internal demo phase of E1M3 consumed so much development time was because of a few confrontations with Doom3 itself. One day after several hours of intensive work, I messed around in the map combatting enemies and gibbing corpses. Yes, that never gets old. Unfortunately the game would not allow me to do so. More like Dumb3, eh? The level crashed to console with the error message "Could not load collision model at ####: No free slots". I shrugged off the initial shock and wrote off the error as a "freak accident". Doom 3 has these from time to time. After all, I had played through the map dozens of times without encountering any unfortunate incidents. Sadly, geX later reported encountering the same error, so we couldn't ignore it. In fact, it was even worse for him. He couldn't even load the level whereas I could run around like a maniac. After a lot of research into the SDK and the failed venture on google, I found a few interesting console commands. One of these was "ListCollisionModels". Entering this command in the console gave me the obvious list of Collision Models. The very same type of model that apparently had no free slots. The list claimed that we had 2047 collision models in the massive 27k brushes map. This led to the obvious conclusion that the game has a 2048 limit and gibbing a corpse spawns additional collision models. So I did the natural thing of searching the SDK for this elusive limit. No luck. It seems that the code for this is stuck inside the collisionmodelmanager type that is outside the SDK. After a short crisis meeting we came to the following conclusion; We either had to:

1) Split the map in two or
2) Delete a lot of the details or
3) Delete complete areas

None of these alternatives were attractive to us. The first would break up the progression of the map and be really time-consuming as E1M3 is a tightly connected level. The second would leave the map empty and dull. The third would require the sacrifice a few really interesting areas. We decided to spend some more time researching this error. After going back and studying what kind of collision models claimed the slots of the map, we discovered that a lot of them were actually detail patch meshes. Some of these were patch caps and several of them were flares. The patch caps are automatically turned into func_statics which take up slots in this list. Apparently we had approximately 300 of these scattered around the level. We solved this by writing a method for our personal map loader which spotted these types and turned them into worldspawn rather than separate entities. Success! The level could now load and gibbing was again a possibility. To make sure we weren't dancing on the edge of failure, we went through all the flares in the map and grouped them together per color per room. This bumped down the total to 949 collision models. Phew.

We have also updated our website since the last devblog. We have added a gallery to the main page so you can view most of our previously released screenshot. We have collected a few high-resolution screenshots for you to enjoy. Any future screenshots will also be added to the gallery. Thanks to Manc for this.

Yesterday I played around with monster spawning for Doom 3: Phobos. I wanted to change the teleporter, or spawn-in, effect of the monsters. The problem as I and others on the team see it is that you get too much of a warning in Doom3 when monsters spawn in. A break-down of the effect would go as follows;

1) Start sounds of whispering
2) Show neat and ominous particle effects
3) Strike the ground with a bolt
4) Spawn in the monster

The duration of this process is what bothers me. It takes between 1.6 and 3.6 seconds for a monster to spawn in. This fact alone makes the spawning monsters a useless feature, in my opinion. The player gets a warning as well as a detailed description of where the monster is going to teleport in. AFTER the couple of seconds, the monster will then have to land and scream at you. 4 or 5 seconds can easily pass before the monster is ready to claw at you.

Compare this to the old doom where an imp could teleport in with a "BZZT" and attack you instantly. No warnings, no delays, just 100% surprise and fast action.

I wanted to replicate this effect.

The first place I looked was in the teleport.fx files. These control the sequences of the spawn-in effects. It all made sense in there. There were delays, durations and references to different particle effects, lights and models. "Easy", I thought and for proof-of-concept I tried to delete everything in the fx. No go. While all the particle effects and lights were gone, the imp STILL took its sweet time spawning in. This sent me on a wild goose chase in the SDK. I couldn't find a variable for this delay anywhere and after a couple of hours in the SDK I tried to look elsewhere. Apparently the delay is a hard-coded value inside the base AI script for monsters. Kind of backwards and hacky if I may say so. I removed this delay and finally the imp could spawn into the area in all its instant-action glory.



The reason I've been playing around with this is because E1M3 has reached the internal demo phase where we pretty much just need to place enemies and items. While we already went through this process during the equivalent phase for E1M2, this still feels new for us and we are going to spend some time the following weeks experimenting with it. Even though we have a clear-cut vision of how the mod should play, we still need to spend some time getting there or even learning how to get there. The last thing we want is for the monster placement to become an after-thought. This needs to be done right. Doom3 never really went far in the experimentation of the combination of different monster types. How often did you encounter melee enemies AND long-range enemies at the same time? How often did you need to find cover? Were imps used for mainly melee or ranged attacks? How can we improve on that? These are some of the questions we're exploring the answers to.