Doom 3: Phobos is a 1 episode project which continues the story in Doom 3. It is set in between Doom 3 and its expansion pack, Resurrection of Evil. Doom 3: Phobos will feature more variation than the original 2004 game, and will bring back more of the traits that made the original Dooms successful. Doom 3: Phobos has evolved into a very extensive and ambitious project. We are well on our way of creating an unofficial expansion pack of top quality.

Report article RSS Feed Devblog #10 - Uncharted Worlds

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....

Posted by shaviro on Feb 22nd, 2010

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.
 

User Posted Image


 
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:
ModDB icon Twitter icon Twitter icon

Post comment Comments
Argoon
Argoon Feb 23 2010, 7:11pm says:

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. ;)

+1 vote     reply to comment
-Str!ker-
-Str!ker- Feb 24 2010, 9:03pm replied:

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.

+1 vote     reply to comment
geX
geX Feb 25 2010, 4:02am says:

We dont minde the hard shadows really. It was a part of Doom 3's art style. And we'd like to keep that :)

+1 vote     reply to comment
shaviro
shaviro Feb 25 2010, 4:18am replied:

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 :)

+1 vote     reply to comment
Post a Comment
click to sign in

You are not logged in, your comment will be anonymous unless you join the community today (totally free - or sign in with your social account on the right) which we encourage all contributors to do.

2000 characters limit; HTML formatting and smileys are not supported - text only

Icon
Doom III Icon
Platform
Windows
Game
Doom III
Developer
Team Future
Contact
Send Message
Official Page
Tfuture.org
Release Date
TBD
Mod Watch
Track this mod
News
Browse
News
Report Abuse
Report article
Related Mods
Doom 3: Phobos (Doom III)
Doom 3: Phobos Doom III - Single Player First Person Shooter
Related Games
Doom III
Doom III Single & Multiplayer First Person Shooter
Related Groups
Team Future
Team Future Developer with 6 members