GoldenEye: Source Forums

Global Communications => Development Media => killermonkey's Blog => Topic started by: killermonkey on January 31, 2010, 05:58:47 am

Title: Beta 4 Programming (Part 1)
Post by: killermonkey on January 31, 2010, 05:58:47 am
Hey guys, I know I am very vocal on the forums in everyone else's topic, but most of you don't really understand what it takes to get this mod to perform and feel like the GoldenEye 64. The developers and beta testers know all too well how many innocuous bugs crop up out of such benign additions such as a revamped blood screen or new team score display on the hud. Not to mention the extremely tricky bugs involved with bullet penetration, rolling explosions, and dynamic token gameplay...

This blog will discuss some of those bugs and what you can expect from Beta 4. I am not whining or complaining, but you have to understand how difficult it is to erase all the BAD things Valve hard coded into the SDK.



Bullet Penetration

My first, second, and third approach to bullet penetration were complete failures in terms of effects and performance. Basically, I extended the penetration of glass to all other objects which seemed like a trivial extension, but Valve stepped in again...

Their generalization of what a shot does during it's "flight" prohibited the penetration from working on both client and server sides. Ever notice that when you fire on glass you only see a bullet hole on your side of the glass and you never see a tracer past the glass? Well that is what I am talking about. The shot stopped on client side at the glass and continued only server side after the glass. This causes a desync in the shot effects and potential lag in the visualization of your attack. The reason for this was actually quite simple. If glass is bullet proof, only the server knows. So they didn't draw the effect on client side pending the bullet was actually stopped and hoped you didn't notice.

The final implementation of penetration involved me rewriting the entire sequence of firing bullets to be both client and server side so the effects are visible to the local player and the other connected players. I also implemented a method of bullet "slowing" such that the deeper the bullet penetrates the less it can penetrate on the next hit of an object (including players!). Although another bug crept in.... penetrated weapons actually hit multiple hit boxes on the same player as it passed through the player! This resulted in an instant kill with the magnum even if you hit them in the legs. So another run through introduced a filter to prevent the same player from being hit by the same penetrated shot.

(http://img.photobucket.com/albums/v687/killermonkey01/GE%20Source/th_ge_library_classic0002.jpg) (http://smg.photobucket.com/albums/v687/killermonkey01/GE%20Source/?action=view&current=ge_library_classic0002.jpg)


Rolling Explosions

Another thing that Valve's damage system was not designed for was damage over a prolonged period from the same entity. Basically when you are damaged by something the damage has to know who/what inflicted it and that information is passed down through all the functions that are called.

Take the mine for example. In a HL2 explosion the explosion damage lasts for 1 game frame. It is applied instantly to all objects within range and then it never happens again. The effect lasts for multiple frames, but it doesn't do anything damage wise. This allows the mine to remove itself from the world on the NEXT frame and still count as the inflictor, etc etc.

With rolling explosions, damage is applied over a 3 second interval (roughly). If the mine removed itself after that first frame the explosion would be holding onto an invalid pointer to the now deleted mine as it tried to apply damage again! This was causing serious crashes in our system that were very hard to identify at first. The fix was to create a new removal function that postponed actual deletion of the entity (mine) for X seconds and only kept it hidden from view during that time. That way damage application could use the information (printname, dmg amount, etc.) through all the successive damage applications over the course of the explosion.


(http://img.photobucket.com/albums/v687/killermonkey01/GE%20Source/th_ge_silo0000.jpg) (http://smg.photobucket.com/albums/v687/killermonkey01/GE%20Source/?action=view&current=ge_silo0000.jpg)


To be continued...
Title: Re: Beta 4 Programming (Part 1)
Post by: CCsaint10 on January 31, 2010, 06:22:57 am
Although this log doesn't even come close to dealing with all the hassles that we put you through and all code you have to modify/make.....it at least gives a picture of how much the mod team appreciates your efforts. Beta 4 is strong (especially after that particle simulation fix last night that you figured out). I am so grateful. You guys are in for a GREAT surprise. :)
Title: Re: Beta 4 Programming (Part 1)
Post by: VC on January 31, 2010, 07:06:31 am
The true heroics isn't in the coding.  It's in dealing with me telling you how to do it.
Title: Re: Beta 4 Programming (Part 1)
Post by: CCsaint10 on January 31, 2010, 08:36:17 am
right....because you have all the answers to everything...
Title: Re: Beta 4 Programming (Part 1)
Post by: Ruone Delacroix on February 15, 2011, 09:17:17 am
I know that I'm a bit late with this, but I think that it's incredible just how complex these details are in this game (and I'm guessing in most other games too). I especially liked reading about the rolling explosions.

Honestly, I'd buy you all a round if I could. You're all working so hard to make this game as amazing as it is. Thanks alone doesn't even scratch the surface of how much you all deserve.
Title: Re: Beta 4 Programming (Part 1)
Post by: JcFerggy on February 15, 2011, 02:40:22 pm
I'd love a round, but due note that you have made a bump spanning over a year.
Title: Re: Beta 4 Programming (Part 1)
Post by: Ruone Delacroix on February 15, 2011, 02:44:31 pm
Yeah, I do realize that. I misread the date as New Year's Eve 2010. I don't mean to go around necroposting, but I'm just trying to get some activity in this place again by saying more than just "cool!" and having some logic involved.