40oz
diRTbAg
Posts: 5,535
|
Post by 40oz on Aug 12, 2020 18:40:41 GMT -5
Do you think the way Doom freezes the player in place when they teleport was a feature added on purpose to make them easier to telefrag in deathmatch?
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Aug 12, 2020 21:10:43 GMT -5
No. I think it may have been done for technical purposes, so as to avoid clipping problems (players moving too fast and going through the wall, for teleporter surrounded by walls) or anything other that may have happened in testing. Or so it looks better, so you see the teleporter animate over what came out, not several feets behind a crazy running marine.
|
|
dmdr
Doomer
is this how I add a title under my avatar?
Posts: 588
|
Post by dmdr on Aug 12, 2020 21:14:28 GMT -5
what vigilant said, especially the part about it looking better
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Aug 13, 2020 4:17:25 GMT -5
Sounds like bs about clipping problems to be honest. Boom has silent teleporters that don't freeze you and you can't clip any walls by using them.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Aug 13, 2020 4:19:59 GMT -5
Maybe they thought that teleporting is a little disorientating and so it would be nice to give the player a little time to realize what just happened.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Aug 13, 2020 10:47:44 GMT -5
Yes, I looked into source code, and it doesn't seem like clipping issues would happen, since momentum for all axis is set to zero as well (except when they later broke it). However I still hold to my opinion that it was about the looks, since players are able to get going much faster than monsters.
Also, strictly speaking, when the code is written and doesn't work like it supposed to work and the solution is not obvious, changes are sometimes introduced until it gets finally fixed, with some no longer relevant changes still held even after a true solution is found. This results in a situation when after actually successfully deriving a solution for something, that same person with now updated knowledge would still do things differently if they go to it from scratch. Code has history, and it helps to study its history to know why the technical solution for a certain problem was this or why a certain feature was implemented this way, which is made possible in modern developer world via bug trackers and revision control systems. I frequently solved problems at my job by looking at the history of certain code, to understand how well those who wrote it understood the objective, whether they achieved it, what pitfalls there were, what may have intended to be done but was not done or was done incorrectly due to a human factor (miscommunication), etc. - it's part of dealing with large codebase that has decades-long history (some written before those tools were avaiable) and keeps evolving, especially when all the original team is gone.
So, to say that it "never had that problem" implies you know of all the revisions the engine went through and all the problems it may have had in pre-alpha, alpha, beta stages and the rest. Your argument about Boom is especially interesting, as there are a lot things Boom doesn't have problems with (such as removing limits) that the original engine actually did have problems with.
But you are right, this was more likely a deliberately coded feature. I wonder if someone already contacted the developers in social media and got the answer from them.
|
|
