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.
|
visit our homepage |
||
| Please join us here too: | ||
|
|
|
Good work on the map, by the way, are you guys using the dark mod ambient light system? If not i recommend it because some ambient light on that shot would do wonders. ;)
Agreed, some properly done ambient light greatly cuts down on the hard edge shadows the engine makes. You guys do great work though, looks like ID quality stuff there.
We dont minde the hard shadows really. It was a part of Doom 3's art style. And we'd like to keep that :)
Yeah what geX said. Also, we're not 100% satisfied with the lighting in the shot and this will be addressed once the second phase of our internal demo starts :)