Ever wondered if kewl maps made on quake 3 engine games could be created for DoD?

Well I have and I've spent loads of time trying to re-create the Wolfenstein Beach Assalt map (the one that came with the multiplayer demo release of the game).

Before I get into this, PLEASE NOTE: at no time have I reverse engineered the original wolfenstein map. The modeling was done from scratch. Some of textures were steamed off the original wolfenstein pak files (to give an authentic wolfenstein look to the map). A few custom textures have been created from scratch and a new treatment for the ocean surface has been implemented.

Here are the findings.
I have managed to re-create the whole map comprising the beach area, the upper base and the lower base bunker rooms. The map is huge and covers the full mapping grid.

After a lot of fine-tuning, I've got the whole map to compile and work like it did in the wolfenstein original. Unfortunately, steam doesnt like the bsp file for some reason and it immediately jumps to the end screen shot and quits the map. I assume there is an internal limit that has been exceeded someplace.

To get a playable version of the map, I have removed the lower bunkers (and the kewl 3d bannisters on the staircases - and they took ages to model too). At present, I've created 4 flags for capture in the axis base. Allies receive extra points for blowing the beach wall and the forward bunker doorway.

Ideally, I would like a set of plans to be accessed and taken to the radio room when the 4 flags are captured. This is a work in progress (I'm still fighting the geometry limits here - so it will be a lot less complex than the lower bunkers of the original).

So, thats the story so far.

It is possible to create huge quake3 maps for DoD (they even compile successfully if you use XP-Cageys latest tools and make the geometry as efficient as possible).

Exceeding the maximum number of clip nodes is a big problem. I had to do a lot of creative modeling to get round the internal limits.

r-speeds are a bit high, but most modern PC's will be able to run the map with no real problems - this might be a different story on a full server though.

Steam doesnt seem to like a bsp bigger than 8 megs.

I'll post a few piccies and a link to the current (cut-down) playable version - hopefully by this week-end.

As I have already mentioned, this was an experiment to see if a popular map made for another game (using a better engine) could be implemented on the HL1 engine. I think it can (but you REALLY need to know a trick or two when it comes to mapping).

Anyhow, you can make up your own mind when I eventually get round to releasing the thing.

Pix

Pics please (at least from the Hammer Editor)

RE: map automatically finishing:

It is most likely the entities that are making the map automactically win. Heres a few reasons why that may be:

You may have used the "built-in timer" in the info_doddetect entity and it expires quickly. Dont use this feature if you are. Use the dod_roundtimer (may be named different).

You may have somewhere in an entity used the "end game" after someone controls all the flags. Take that off. Do not use that at all. I supsect this is the most likely culprit.

Or you may have accidentally given all flag or capture points to Axis (im assuming axis cuz they defend) and they win. Simply remove entity coding that gives Axis victory if they control all the flag points. If "end game" is selected to yes, the map ends, therefore, your map instantly goes to the next in the map cycle.

Thats happened to me a few times and I suspect it happened to you. Id also suggest quickly compiling with no vis or rad to make sure ur entity work is correctly fixed.

hope ive sparked a way of finding your current problem

Originally posted by Watchtower
RE: map automatically finishing:

It is most likely the entities that are making the map automactically win. Heres a few reasons why that may be:

You may have used the "built-in timer" in the info_doddetect entity and it expires quickly. Dont use this feature if you are. Use the dod_roundtimer (may be named different).[...]

Errr... Wrong thread?

Thanx Watchtower

I'll go see if the problems you have highlighted have somehow sneaked into the map.

I started getting the round-ending problem when I included the lower bunker geometry into the final map. Up until that point it was behaving itself.

Maybe I've cut and pasted some entity gremlins from one map to another (much of the map was constructed area at a time then glued together to make the final map - this made hammer response times fast and test compiles a lot more useful).

If you have nailed the problem - I owe you a pint

Pix

eric the pixie....not seen that name in a while now, I liked your TFC maps and was cool meeting you at i18!!

Anyway, to the topic...looks like you doing a good job and if you can I'd like to see some screenies of the end result....you could probably put the 3d bannisters,etc back in too when dod source comes about so don't delete them!!

Interresting project...:sheep:

I've stuck some screenies on our webby

http://www.clan-scot.com/dod_wolfie_01.jpg
http://www.clan-scot.com/dod_wolfie_02.jpg
http://www.clan-scot.com/dod_wolfie_03.jpg
http://www.clan-scot.com/dod_wolfie_04.jpg
http://www.clan-scot.com/dod_wolfie_05.jpg
http://www.clan-scot.com/dod_wolfie_06.jpg

I hope this lets you see how close the map is to the Wolfenstein original.


Here are a few screenies with the DoD fog turned on:-

http://www.clan-scot.com/dod_wolfie_07.jpg
http://www.clan-scot.com/dod_wolfie_08.jpg
http://www.clan-scot.com/dod_wolfie_09.jpg
http://www.clan-scot.com/dod_wolfie_10.jpg
http://www.clan-scot.com/dod_wolfie_11.jpg


And here are a selection of shots from the lower bunker.

Unfortunately, it looks like this stuff wont be included in the first release of the map due to some problems I'm having with compiler internal limits. (at least I think thats where the problem lies).

http://www.clan-scot.com/dod_wolfie_12.jpg
http://www.clan-scot.com/dod_wolfie_13.jpg
http://www.clan-scot.com/dod_wolfie_14.jpg
http://www.clan-scot.com/dod_wolfie_15.jpg
http://www.clan-scot.com/dod_wolfie_16.jpg
http://www.clan-scot.com/dod_wolfie_17.jpg
http://www.clan-scot.com/dod_wolfie_18.jpg
http://www.clan-scot.com/dod_wolfie_19.jpg

Hopefully I can fix these problems so we can play the map as it was intended, with the lower bunker rooms holding the top secret plans which must be taken to the radio room to win the round. If that cant be achieved, the map will be released as a standard 4 flag control type with all the action happening in the upper base. - Watch this space :D



Hello El Cap :D good to see you are still around m8.

Like you said, it will be pretty damn helpful if the source version of DoD fixes all these internal limits - I have a spinky full map with all the toys in place ready to go if this turns out to be the case.

Lemme know what you think of the screenies

Pix

This is really some amazing work :) i see nice clean mapping and a damn good look of the original wolfbeach map! looking forward to this!

Yeah, this looks wery nice indeed!
But will prob work best with dod s, wich is just fine for me...:D

Can we get r_speed counts because they look incredibly high. Passing the 1000 mark without a problem (on the beach)

Wow. Great job porting the map. RTCW's Omaha is one of my favorite beach invasion maps in any game.

Thanx for the positive feedback peeps.

Just to mention it again, the whole thing is a bit of an experiment to see if its possible to get the map working in DoD.

There are a number of limitations in the HL1 engine which are not a problem in the Q3 engine and so, the challenge is to find work-arounds to produce the same look, feel and playability as the original.

Neutrino:
r_speeds are pretty high on the beach. I haven't used a single hint brush yet because I've been concentrating on trying to include as much of the lower bunker geometry as possible.

When I finally reach the end of this process (and will have to settle for what lower bunker stuff I can safely get away with), I'll be looking at streamlining the open areas for poly counts and the like.

The beach area is deceptively big - probably because of the mountains on each side which makes the actual sand area feel smaller than it really is. Most DoD beach maps dont include this kind of terrain element to minimise the poly count - but the object of the excercise here is to re-create the original look of the map, so the extra terrain has to be kept in. That leaves a big r_speed hit because of it. The whole outside area is constructed of triangles and their vertices have been pulled and pushed to create the topography. I've done a fair bit of reducing of these brushes to help with clip node counts - which also helped the r_speeds at the same time - so in a roundabout way, the map optimisation has already started.

One major r_speed saving will probably be made on the ocean - func_water to func_illusinary perhaps. At present, the lines of barbed wire on the beach are func_illusionaries with hurt areas and clip brushes to block player movement. They will probably be converted to custom models which will reduce the poly count considerably.

My main thrust at the moment is on just getting the map to run with the maximum amount of geometry. When thats done, the r_speeds will get the full attention.

Pix

if you need any help with models and stuff, i can always help out in my spare time (less than i would like but meh)

just gimme a ring (pm)

Wow. Just...wow. A fantastic amount of effort on your part, and it shows in the detailing. I'd be hard pressed to tell if that was RTCW or DoD at a glance.

Have you looked at dod_charlie for hints to lowering rspeeds? The length of the Charlie beach is probably the equivilent to what you have there.

Also, you could make it so that seizing control of the upper bunker forces a respawn/map change to the lower bunker area with new objectives. That might be a work-around for the HL map limitations.

Eric the pixie - that looks amazing!!

Roll on DoD:S

Outstanding port job. Well done.

Ok, - latest on the progress of the map.

The geometry at present consists of the full beach area, the full upper base and a cut-down lower base which is accessed by 2 staircases, one at each end of the lower bunker corridors.

The map has 4 flags which must be captured by the allies as a first objective. Once captured, 2 large blast-doors in the upper base open to allow access to the radio room and the staircase beyond and also allow access to the stair case at the other end of the base. In the lower base area, there is a vault that must be blown with TNT. Inside the vault are the top secret documents that must be taken to the radio room and transmitted to the allied HQ to win the round.

The only real difference from the original map is the simplicity of the lower base area (and the inclusion of a vault), we also have more flags to capture on the upper base.

@Khakiass
That would be a good idea (having a second part to the map loaded in, replacing the first after the first flag area objectives are secured - kinda like what happens in the TFC map Dustbowl). Thing is though, I'm trying to duplicate the original as much as possible, so the spawns and stuff like that still exist on the completed part of the map, also, the lower area is only really missing a couple of rooms and a corridor, so there isn't an awful lot that is going to happen down there anyway.

@Watchtower
Yep, the entity problem was exactly how you explained it - I had assigned all 4 flags to the Axis at the start of the map. This immediately triggered the 'Axis-Win' code - which ended the round, Doh!. So I owe you one frothing pint of your choice. :D

Final changes to the map before release.
r_speeds are likely to be a bit on the high side when on the beach. By using the DoD fog mode, the maximum distance seen by the engine can be significantly reduced during the compile process. This single tweak will kill a huge number of rendered polygons. The only down side to this is that if a player gets rid of the fog, there will be no distant terrain drawn on the screen.

To be honest, the map looks really good with the fog, its like a sea-fog has rolled in just in time for the assault. Snipers will moan a lot because of this I expect and will probably kill the fog.

Another side effect of the fog is the way that it doesn't affect func_illusionaries. Everything else fades with distance, but they remain unchanged and screw up the illusion. I'm converting func_illusionaries to models instead (which work great with the fog)

All being well, I should have a fog version and a non-fog version out for review very soon - hopefully by next week-end.

Pix

A vault sounds kinda hokey... maybe it's just me.

Perhaps a quickly baracaded room with the documents on a table or something? ... the baracade will need to be TNT'd? .. I dunno. A vault just seems kinda.. outta place. :confused:

Anyways, other than that, the map work looks amazing. I remember the original of this map and it was pretty awesome.

Hope it'll have the same feel.. only DoDized. Keep up the good work, yo.

@{GL}DoubleD

exceeded_max_clipnodes is a real pain.

I'm continually fine-tuning the geometry to try and free up some more nodes. The more I have, the more stuff I can build. Like I've mentioned a couple of posts back, the map is nearly there as far as comparisons with the original are concerned.

At the moment, I still don't have enough nodes to include the original big room where the plans were found. Thats where the vault idea came from - it won't take too many nodes to knock one up, it won't be very big and it won't need much in the way of furniture and other node-producing stuff.

I still have a couple of areas I can re-work and they might release lots more nodes if I'm lucky. In the mean time, I need a temporary home for the plans so that the gameplay, entity logic and performance issues can be checked on a server.

Pix

Originally posted by Eric the Pixie
Thanx for the positive feedback peeps.
One major r_speed saving will probably be made on the ocean - func_water to func_illusinary perhaps. At present, the lines of barbed wire on the beach are func_illusionaries with hurt areas and clip brushes to block player movement. They will probably be converted to custom models which will reduce the poly count considerably.

My main thrust at the moment is on just getting the map to run with the maximum amount of geometry. When thats done, the r_speeds will get the full attention.

Pix

Fork me, nice map!

Actually, R_SPEEDS will be reduced if you:
- Give the water texture an ! in front of its name
- Un-tie the water to any entity (in this case func_water), the water is still accessable/swimmable.

Good good work :D

Update:

I really like the way the fog makes this kind of map look so atmospheric, so I've created a load of models to replace the func_illusionary brushes that were used on the beach and other open areas.

Models are affected by the fog, func_illusionaries are not.

Here are some more screenies to make the point. Notice how the stuff on the beach (specifically the barbed wire lines) and the camoflage netting in the base all fade with distance now.

http://www.clan-scot.com/dod_wolfie_20.jpg
http://www.clan-scot.com/dod_wolfie_21.jpg
http://www.clan-scot.com/dod_wolfie_22.jpg
http://www.clan-scot.com/dod_wolfie_23.jpg
http://www.clan-scot.com/dod_wolfie_24.jpg
http://www.clan-scot.com/dod_wolfie_25.jpg
http://www.clan-scot.com/dod_wolfie_26.jpg
http://www.clan-scot.com/dod_wolfie_27.jpg

These images were saved from DoD running at 1920x1440 and reduced to 640x480 (so poor sod's like me on 56k dial-up won't have to wait for 3 days to download the piccies).

One thing I have noticed with transparent models, the image quality drops off pretty quick the further away you are from them. Hopefully DoD:S will have support for proper alpha-channel transparency.

Pix

You should make the next official beach map for DoD! :eek:

Damn thas sweet!
Is the beach part of the map playable as it is now?
Cause you should just slap some flags or objectives in there
and let it rip!
I would so like to play this RIGHT KNOW! :D

I had to double check the calendar to make sure it wasn't April Fools! This thing looks fantastic!!

Keep up the good work...the dev team would not ever consider a remake of another companies work as "official" but the skills you show here could easily work in the source environment given another project.

As to r_speeds...it's a given that beach maps will have high r_speeds in the HL1 engine unless you go the Omaha route (flat wall left, flat wall right, single brush beach, three-brush cliff, etc) so I think you should not be overly worried about them (charlie hits 1200-1300 in places or more). One thing to think about is making sure you have some way for guys to get away from long-ranged snipers...good luck!

Eric, once you have it to a playable state, let me know if you'd like somewhere to playtest where you can get a good turnout and truly useful feedback.

-Shane

First player models and now this, soon were gonna see COD and MOHAA maps:D

awesome map, lad! release for dod 1.3??? or source?

-Stoffer

Pixie..... damn nice mate, you had better send that map to me for play testing or I'll send BB(Or a nekkid TT) and CheeryE around to sort you out ;)

Grab me on msn and I'll drop into [SCOT] chan for a chat mate.

Higgsy.

wow - the textures dont even fit the dod play - i was like omg ... this is not dod lol ... awesome work tho

Update: The Experiment is almost over.

Once again thanks for all the feedback and encouragement.

I've decided to pull my finger out and try to get this thing ready for a release - probably mid-week (work permitting).

I'm gonna try and squeeze some more geometry into the basement section of the map before then.

R_speeds are not as good as I had hoped on the beach area. Looking towards the ocean from the base doesn't break the 1000 poly limit, but looking up the way towards the base is a huge 2500-3000+ (this has been steadily improved by hint brush work, but its still way on the high side). My PC doesn't feel the r_speed hit to be honest, but that doesn't mean it won't lag other peeps to hell. We will see how it performs on a server.

As far as the original aims of the experiment go, I think it was almost a success. The HL1 engine can still pull some rabbits out of a hat if you make the effort.

Nice thing is though, now I've got a half-decent map to use in DoD:Source, so I should have an all-singing, all-dancing version out there in jig-time once the new Hammer is released.

@Shane
Thanks for the offer of a server to playtest, I may take you up on that if its still ok.

@Higgsy
Where have you been hiding m8 - That Scotland to Australia time difference excuse is a cop-out :) Get your ass into #-scot- or jump onto the [SCOT] server so we can gang up on TT :D

Pix

Originally posted by Eric the Pixie

My PC doesn't feel the r_speed hit to be honest, but that doesn't mean it won't lag other peeps to hell. We will see how it performs on a server.


in your last set of pictures, i dont see anything over 20fps (at the bottom right, your net graph).

@Neutrino
Yep, thats true - but the game was running at 1920x1440 @ 32bit so I could get some nice screenies.

I normally run it at 1024x768 and the fps never dips below 60 in the worst areas.

I probably could improve the r_speeds with time but I dont think its gonna be worth it (there is just too much geometry visible from the water end of the map).

DoD:S is just about here, so I'm drawing a line at this point as far as the HL1 effort goes and will be one happy bunneh converting it to run on the new engine.

Pix

If you need to convert your terrain brushwork and other brush details into .mdls, do this!

Originally posted by Glidias

How to convert RMF brushwork? I use this method (mentioned long ago as well): DIY

1. You've got .rmf brushwork. Place it properly in relation to the origin of Valve Hammer Editor grid.
2. Click on every individual brush and convert it to func_wall. This is to prevent vis-portal splitting during compile.
3. Edit>Select All and Apply NULL texture
4. Shift+A texture application: Apply another texture on all visible faces you can see on the model.
5. Edit>Select All, Shift+A, increase texture scale to 16x, face alignment centered.
6. Compile map (CSG and BSP only)
7. Once .bsp is produced, go convert that .bsp to a .asc (or some other format) that can be read by 3d programs such as Milkshape 3D or 3D Studio Max. For the conversion, i use VeSDK editor that you can get from http://www.deep-shadows.com/downloads/vesdk_en.zip . Use the lev editor export function. I didn't bother with using the export scale factor....I suggest you don't....keep it at 1.0 ok?
8. Import the .asc in MS3d or 3dSmax or your program. Scale all 0.25!! By then, the extra vertices should have collapsed into each other so there's no need to re-weld vertices. It would be still good to select all vertices and Weld together just to be sure. Rotate and orient the model properly *about the origin*!!! I think it's -90 at the Y box. Don't worry you can always adjust later in Valve Hammer Editor using the Pitch/Yaw feature of entities.
9. Result: One clean model that is exact replica of your .rmf. Now, group and texture it. I use Lithun Unwrap and MS3D's tile texture application plugin (half-life mdls don't support repeating textures, so just tile apply 1 repeat only!) from v1.6.5.
9. Do the nceesssary .qc compiling to get that thing into a .mdl!

So, now you can transfer 500 wpolies into 1000 epolies if you are desperate!

Or just use displacement maps.

Originally posted by Ginger Lord
Or just use displacement maps.

this is for dod on hl1 not source :D

5 statements/opinions

--I downloaded the map and stress-tested it on my pc with 32 bots. It was fun.

--At no point did I have any lag problems until I was up on the complex near one of the capture points close to the far left bunker where axis come through. This I would expect, and as a whole, you did an excellent job keeping the original look and feel of the map while keeping lag to a minimum.

--I think that area could cause the only problems as alot of wpolies and epolies, including players and associated items are visiable up on top of the complex. I wouldnt go so far as to calling it bad, but there was some hitches up there.

--I dont know how it would run online though, that is the true test if you wish to complete this project and make it availble for mass downloads, I would seriously consider doing that with at least 24 players.

--Your sky map needs work though, the only visual recomendation I would make. I realize you suggest fog settings but sometimes I like using my mini-map and that cuts out the fog.

WT

I agree I would like to see this map finished and available. Did anyone else notice this thread is from October?

Thanks for all the good feedback.

I've just competed a few minor changes to the map and have overhauled the capping logic.

I keep getting asked about the way I made the flags and doors work the way they do. For those who are interested, I'll do my best to explain the thinking behind it. If this doesn't float your boat, jump down to the last bit of the post.

I'll explain the original setup (seriously flawed).

I needed to have 4 flags that are captured using areas and a fifth point to represent the radio room, again captured by an area. Each area needs a secondary device to reflect the state of the flag, ie, another flag - or a plinth in this case. The blast doors need to open when the 4 flags are captured by the allies. They also need to open only once, no matter what happens to the flags after this event.

My first method used two capture point masters. The primary master controled 5 capture points, the secondary monitored the 4 secondary flags and supplied the plinth models where needed.

Each primary flag controlled the appearance of the secondary plinth. When the 4 primary flags were captured by the allies, the 4 secondary devices were triggered too, this fired the secondary master and opened the doors via the allies target parameter.

To make sure the doors only opened once, the doors were opened by targeting a game counter that started at 0 and ended at 1. When it is fired, the counter goes to 1, targets the door multi_manager which does all the sound and door stuff. Targetting the counter after this event produces no output because its already at 1, therefore the doors dont open again.

The final point is captured by the allies to win the game.

This method worked great on my main pc and my laptop, but it didnt work for everyone. Some people see 4 flags plus the radio tower icons in the hud, some people only see 4 flag icons, it seems to be a bug with DoD and multiple control point masters.

The new way of doing the flags.
The current method uses only one control_point_master, and uses a multi_watcher to monitor the status of each flag point. A dummy entity is also monitored to determine when the allies have capped the 4 flags - I'll explain this a bit better :)

Each flag targets an env_state entity and also toggles a plinth (the secondary device for the point). The plinth is textured with an animated texture with 2 frames, (an axis image and an allies image) and is a func_button.

Each env_state starts the round in the OFF state. A dummy env_state starts the round in the ON state. The multi watcher monitors the dummy and the 4 flag env_state entities and triggers when all 5 are set to ON. This happens when all 4 flags are captured by the allies (which switches all the env_states to ON). The multi_watcher triggers the door opening stuff.

To make sure the doors only open once, there is actually another dummy env_state entity that is tested by the multi_watcher. This entity starts in the ON state and is included in the multi_watcher test (so it is actually testing for 6 env_states set to ON to open the doors). When the doors are triggered, this second dummy env_state is flipped to the OFF state via a multi_manager. Because of this, the multi_watcher will never fire again because there will never be all 6 env_state entities in the ON position again, so no more opening doors!

The final point is capped to win the round for the allies or win the round for the axis if they can hold on to the point.

@Watchtower
I hate the sky!
The only reason for keeping it like that was because the original map used a pretty simple star-lit sky. Unfortunately, I don't have the luxury of the resolution they can use in the sky of a q3 based map, so the 256x256 images in the skybox are one quarter of the resolution of a 512x512 image - and it shows.

It would be fine if I used a skybox with clouds and stuff because the busier it is, the less obvious the low-res look is.

Maybe I should ditch the stars. :)

llHeldll B0nd has provided me with good feedback from some testing they did on his 28 player server. He pointed out a few bugs (which were known) and didnt mention any new ones, so thats a result.
He seemed pretty pleased with the map under full load. I get the feeling the more players the better the gameplay is. The wolfenstein servers usually run the map with around 32 players. He didnt mention any problems with lag, so fingers crossed, maybe it will be ok for most servers.

We will have a spinky new clan server by the weekend, so I'll probably stick it up there for a final playtest for anyone that wants to jump on and play it. Its only a 20 player server but it will have to do for now.

I'll post ip details, times and the zip file for download nearer the time.

Pix

cool beans!

This is very interesting very.

I looked at all the screen shots
the fog ones are :crown:

Amazing.

i would say just by the screenshots this is the best looking beach map ive seen, plenty of cover comming up the beach too - would be good to see a beach map that takes skill again.

keep it up, cant wait for a release