DM-Shine

Here's a specific forum for discussing potential maps, maps that need a vacation and optimizations and modifications for better playability.
Post Reply
DW_WailofSuicide
DW Clan Member
Posts: 1634
Joined: Wed Dec 28, 2005 12:00 am

New map I've been working on.

Image

This one is more of a proof of concept than anything else, but it hope it ends up being entertaining above and beyond the gameplay gimmick.
I'm a little bit unhappy with the state of the map at the moment because I feel like I could have a very cool aesthetic going on here with all the glass and potential lighting/shadowplay. At the same time I just want to make a playable map that demonstrates the gameplay twist here without getting caught up on being a perfectionist about visuals. So I'm forcing myself to release what I've got now, and maybe I can get back to that later.

Layout-wise, it's an arena map in the vein of Morbias/Fractal/Gael or Training Day. This was a tricky map to create because I wanted to do something that was quick & simple (i.e. a 1 room map), but also made use of the gimmick (which in theory is going to be most useful at 45 & 90 degree angle turns, i.e. lots of corridors). I hope I achieved my goal without going overkill/not utilizing it enough.

Image

Keep in mind that Shock Cores actually have a radius, Shock Beams don't, so they bounce somewhat differently. I tried to accomodate this by doing some additional vector math fun, but it's still not always accurate/easy to line them up properly.

Personally I'd put the suitable player count on 2-4, but 6-8 might be okay too depending on your spam tolerance.
Map requires the additional .u files included in the zip. These files need to be put on the redirect server and in the UT2004.ini ServerPackages. I debated whether I should embed everything in the map file itself, but eventually decided against it.
Custom music file is included in the zip file for those who care.
Download here

Known Issues & ToDos:
Players can't dodgejump off blocking volumes apparently - This is kind of annoying and I will have to look into solutions for this.
Improve Bot behavior? (They really don't seem to understand this map.)
Default Gametype Weapon/Pickup Placement (Default Weapon Mutator?)
Fix sticky corners on main-room dropdowns
Aesthetics in general.
DW_Ant
DW Clan Member
Posts: 2646
Joined: Sat Jun 21, 2008 11:00 pm
Location: North Carolina

That looks really cool. Definitely has an Unreal Classic feel to the map by your texture choice and use of lighting. I'm curious how often will players use the "reflecting" walls to their advantage. Generally people try not to shoot shock cores at walls. We got to play this several times in TAM some time.
DW>WailofSuicide wrote:Known Issues & ToDos:
Players can't dodgejump off blocking volumes apparently - This is kind of annoying and I will have to look into solutions for this.
I never knew that players cannot dodge jump off of blocking volumes. Do you have certain collision properties toggled off? If you can't get it to work, you could always resolve to making an invisible static mesh.
The difference between successful people from others is
not in the lack of strength,
not in the lack of knowledge,
but rather in the lack of will.

FFE466

_________________________
{F}{AH}{CivFR}{XC}{U}{DF}{CJ}{SD}
DW_WailofSuicide
DW Clan Member
Posts: 1634
Joined: Wed Dec 28, 2005 12:00 am

DW_Ant wrote:That looks really cool. Definitely has an Unreal Classic feel to the map by your texture choice and use of lighting. I'm curious how often will players use the "reflecting" walls to their advantage. Generally people try not to shoot shock cores at walls. We got to play this several times in TAM some time.
DW>WailofSuicide wrote:Known Issues & ToDos:
Players can't dodgejump off blocking volumes apparently - This is kind of annoying and I will have to look into solutions for this.
I never knew that players cannot dodge jump off of blocking volumes. Do you have certain collision properties toggled off? If you can't get it to work, you could always resolve to making an invisible static mesh.

It's a standard blocking volume with bBlockZeroExtentCollisions on. I dunno, there might be another property that allows players to wall jump off of a blocking volume, but I think it has more to do with the way that wall jumps are calculated. From what I remember, it does a trace from the pawn when you try to walljump, and so the game probably thinks there's nothing "there" when I'm trying to walljump off a blocking volume (and the only thing being blocked off is a non-colliding glass sheet brush). I do think you're right I'll probably have to put some invisible static meshes in there to handle the collision.
DW_Ant
DW Clan Member
Posts: 2646
Joined: Sat Jun 21, 2008 11:00 pm
Location: North Carolina

Ah, I believe I found your problem with the blocking volumes. You have the same problem with FrostDeck. It puzzled me how you created the ice ponds where the volumes only blocked players and not spectator camera.

What happens is that the surface of the blocking volume is facing the wrong side. What must of happened sometime when you were mapping is that you've inverted the brush while using the Actor Scaling tool. If you invert the brush, you invert the normals.

I've conducted a minor test with large blocking volumes with 256 size. One was not touched, and the other was inverted. I was able to wall dodge off the untouched one, and it blocked my spectator camera.
The inverted blocking volume allowed my camera to pass through just fine, however it'll trap my camera inside the blocking volume (I'm predicting that the thin blocking volumes were too small to trap the camera). Same results happen with the player with the fat blocking volumes. I was not able to wall dodge off the volume from the correct side. If I'm trapped inside, I can wall dodge off of any surface.

Try recreating blocking volumes without inverting them see if that works for you ;)

Note: These are only predictions, and they could be wrong.
The difference between successful people from others is
not in the lack of strength,
not in the lack of knowledge,
but rather in the lack of will.

FFE466

_________________________
{F}{AH}{CivFR}{XC}{U}{DF}{CJ}{SD}
DW_WailofSuicide
DW Clan Member
Posts: 1634
Joined: Wed Dec 28, 2005 12:00 am

Ah, interesting.
I'm not sure what you mean by actor scaling tool. I sincerely doubt it's that, since I vertex edit pretty much every brush. What I have been doing is selecting the brushes that define the shape of the window/glass and setting the builder brush to assume the same shape as that brush. Then I just add my volumes that way. This is no doubt the reason why that behavior occurs, although I'm unsure if it only happens with subtractive brushes (it'd make sense for the normals to be inverted on subtractive brush) or if it happens regardless of the targeted brush.

Since this problem seems to have afflicted every blocking volume in the level I also have to wonder if the inverted normals are persistent once they occur in the same editing session (e.g. I made all the blocking volumes in one session, but I know for a fact some of the target brushes were subtractive and some were additive. It's possible the normal-flipping occurred on the builder brush due to setting the builder brush to a subtractive brush at some point in the editing session, and the builder brush's normals stayed flipped until I closed the editor.)
DW_WailofSuicide
DW Clan Member
Posts: 1634
Joined: Wed Dec 28, 2005 12:00 am

I did some further investigation and it seems like my problem comes from the fact that I subclassed HitScanBlockingVolume as the basis of my reflective volumes instead of BlockingVolume. HitScanBlockingVolume has the property bWorldGeometry false, so I guess that property is checked when a walldodge occurs.

Further testing revealed that placing a solid BSP brush inside the reflective volume allowed walldodging as normal, as does a static mesh with the proper collision settings. I even tried setting the static mesh's drawtype to DT_None to see if that would impact the result and walldodging worked fine even with a totally undrawn static mesh actor.

Now my dilemma is whether I should bother updating the code package to set bWorldGeometry to true on the blocking volumes or not. I'm leaning towards not, just because it seems like any surface where you want stuff to reflect from should automatically have either a BSP brush or Static Mesh visual representation. (The only reason this isn't the case with Shine currently is because I was lazy and used BSP sheets, but I was planning on turning them into static mesh sheets anyway in the next update.)
Post Reply