I love the smell of UnrealEd crashing in the morning. – tarquin
Legacy:Solid Snake/ProjectX Development Blog
4th of April, 2007[edit]
Today I scheduled the task to start writing the cover system for ProjectX. The cover system does not work like Gears of War where you were either in cover or you weren't. They emphasized getting into cover and using it from there. ProjectX's form of cover is based on the idea that the player's environment influences the player's cover attribute. The influences can be both positive and negative, which I believe allows mappers to create areas of interest in this manner. There are currently two things that influence cover, which are terrain and near by objects. This means that the influences isn't spread out like attacking is, but it is rather localized to where the player is positioned in the map.
So thats the basic idea of this core game play element. So what I had in mind to do this was to use volumes. Volumes are very useful in Unreal Engine as they simply define a space attached to an actor using a brush as its collision hull (rather than using the default cylindrical collision). However in UE3 this has all changed, as you can now define various forms of collisions. In any case, I tried subclassing a the basic PhysicsVolume and using the hooks I found in the base class I set about writing code. After compiling the code, the results didn't quite go exactly the way I had thought they would. So I did some logging. It didn't appear that the volumes actually ever received the Touch event calls. So that was annoying, so I kept trying to figure out why it wasn't working. Looking at default classes that UE3 (remember I used RoboBlitz here) has, I couldn't see much difference between my version and their version. So I decided to try their version in the map. Unfortunately to my dismass, none of their basic volumes worked either. Water volumes, physics volumes etc didn't actually work. Now its entirely possible that the way I've written my Pawn class prevents volumes from working (which I'll have to do more research in) but as far as I can see, volumes don't appear to be working at all. Thats pretty annoying.
So I started looking for other methods I could use. Along the way, it appeared that Blocking Volumes still worked. Racking my brains, I remembered that all actors stored the base actor, which changed depending on what that actor is based on. Well what I mean there is, actors that stacked upon each other would acknowledge each other. So for example if a crate was stacked on a barrel, the crate's base actor would be the barrel. So from there, I figured that if I made a 1uu blocking volume which extruded from the floor, I could effectively do the same thing as a volume detection. Huzzah! It worked, and a hook called 'BaseChanged' also allowed me to receive notifications of when the base was changed (thus meaning I didn't have to scan it per tick).
All in all, I never did get the cover system actually coded, but I do have the mechanisms to do so now. So it looks like I'll actually code the cover system tommorow. Unless of course, I decided to keep trying to make volumes work. Who knows, maybe it is my pawn class causing all the trouble to begin with!