09-16-2012, 10:53 AM
Alright, lots of information to go over... I've been very busy, and this is quite a time consuming post to make, so I do apologize. Anyway, let me organize this and address it as best as possible:
Flag Throwing
Let me start with some background information... The reasoning behind allowing flags to cap is quite simple: The goal of CTF is to get the enemy flag to your base, essentially "capturing" it for yourself at your flag. Now, during development I noticed something fishy... if you drop a flag immediately after picking it up, it just sits there... even though it's technically on its base still. See this picture. Later on after fixing this, I noticed is that there is a logical hole in the concept with capturing as well: If you drop a flag onto the base, is that not TECHNICALLY bringing the enemy flag to yours? It moved the same distance; it went to the same location, it should denote a capture. As seen in this picture, it just looks silly... So that's why I made the feature to fix it.
As for flag throw balancing... Passed flags move at 500qu ALWAYS, and thrown flags have a maximum speed as well which are manipulated by the games Newtonian mechanics... thrown flags get slower if you throw them away from your velocity, but also have a limit on how fast they can be thrown... so, really, you can just cap faster/more reliably by just holding it yourself and running with the flag then throwing it. I tried the same exact curve on Space Elevator, and just by using air control I can cap faster than what is possible by throwing the flag. Try it yourself if you really must, use a savegame from a spot before the curve then try each method 5 times... average the results and if you're honest you'll see that using air control is faster than throwing the flag. By the way, the flag carrier can still be killed before capturing-- If you throw a flag while moving fast, it WILL move slower than you and probably won't even actually make it to the base unless you aim it perfectly. Really, this doesn't take anyway any defensive qualities of CTF with stopping people from capturing by killing them before they get to their base, and people who say this clearly haven't played with it enough.
Finally though... I have come up with a feature/compromise for you folks though, I can add a delay for the automatic collection/returning feature, this way you can't throw a flag to cap instantly, but maybe after it has been sitting there for a 1 second delay. (Then, you can just shoot it off the base or return it yourself in time or such) This way it still gets rid of the stupid problem where flags just SIT there even though they technically fit the goal of the game mode of being captured.
Notifications
I've noticed quite a bit of people actually talking about this, and certainly not just from the forums, so I thought i'd clarify the goals and reasoning behind the changes... First of all, we're planning on phasing out the console log in the top left corner, so all the game information is supposed to be moved to other panels on the HUD (like joins/parts will be moved into chat box, and game events will be set up properly in the notify/centerprint panels respectively)... So that's why there are quite a lot more events added into the centerprints now. Second, the centerprints are given color coded information of the team it refers to, this is the most logical and unambiguous way considering our teams have fixed colors (red vs blue, not good vs bad).
However, the eventual goal I have will resolve both of those issues for everyone. Essentially, I want to create a global notification system to network game events/kill events to clients... Right now, we have a "killnotification" system which sends events to panels and with centerprints, however the system is incomplete and not appropriate for game modes to use properly. What i'm planning on doing is unifying this entire system, cleaning it up, and making use of it in ALL game modes... And what will that allow, you ask? #1: Translated game events (capture the flag currently has no translations for example, it's not possible yet), #2: Customizable event messages (yes, you will be able to set a variable to have a unique customized message... or you can just create your own language, like pirate mode or LOL mode.), #3: Cleaner, easier, and more consistent ways to program events into game modes.
The only reason I did not do this before merging the CTF code is because it is a MASSIVE undertaking, it's literally at least 50 hours of work, and i'm just so worn out from programming CTF already. However, I didn't want to wait for such a massive thing to get the benefits of the mostly completed CTF improvements.
Stalemate
Stalemates goal is to speed up the gameplay, it is to make it MORE DIFFICULT to hold a flag during the time of stalemate, I do believe stalemate accomplishes this quite well. Additionally, making the waypointsprites update periodically really is not worth it... It's actually quite a decent amount of work to create a system to update/refresh/clean up the waypointsprites for enemy flag carriers constantly like that, and I don't think it has much of a benefit in relation to the Stalemates goal. So, I should say, it's less about discouraging camping, and more about allowing the gameplay to progress faster by showing players where the flag carrier is. I don't understand where you get off saying "no def no attack" though, any time i'm FC in stalemate i'm always defending myself-- I generally get hunted down when that happens, so... seems to me like the system works as it should.
Oh and... We can't really do new sounds for kill of FC/voluntary drop like that, or at least I certainly can't do them well enough-- I don't really think they're necessary at all though honestly, as the game notifications already cover the proper information.
Flag Throwing
Let me start with some background information... The reasoning behind allowing flags to cap is quite simple: The goal of CTF is to get the enemy flag to your base, essentially "capturing" it for yourself at your flag. Now, during development I noticed something fishy... if you drop a flag immediately after picking it up, it just sits there... even though it's technically on its base still. See this picture. Later on after fixing this, I noticed is that there is a logical hole in the concept with capturing as well: If you drop a flag onto the base, is that not TECHNICALLY bringing the enemy flag to yours? It moved the same distance; it went to the same location, it should denote a capture. As seen in this picture, it just looks silly... So that's why I made the feature to fix it.
As for flag throw balancing... Passed flags move at 500qu ALWAYS, and thrown flags have a maximum speed as well which are manipulated by the games Newtonian mechanics... thrown flags get slower if you throw them away from your velocity, but also have a limit on how fast they can be thrown... so, really, you can just cap faster/more reliably by just holding it yourself and running with the flag then throwing it. I tried the same exact curve on Space Elevator, and just by using air control I can cap faster than what is possible by throwing the flag. Try it yourself if you really must, use a savegame from a spot before the curve then try each method 5 times... average the results and if you're honest you'll see that using air control is faster than throwing the flag. By the way, the flag carrier can still be killed before capturing-- If you throw a flag while moving fast, it WILL move slower than you and probably won't even actually make it to the base unless you aim it perfectly. Really, this doesn't take anyway any defensive qualities of CTF with stopping people from capturing by killing them before they get to their base, and people who say this clearly haven't played with it enough.
Finally though... I have come up with a feature/compromise for you folks though, I can add a delay for the automatic collection/returning feature, this way you can't throw a flag to cap instantly, but maybe after it has been sitting there for a 1 second delay. (Then, you can just shoot it off the base or return it yourself in time or such) This way it still gets rid of the stupid problem where flags just SIT there even though they technically fit the goal of the game mode of being captured.
Notifications
I've noticed quite a bit of people actually talking about this, and certainly not just from the forums, so I thought i'd clarify the goals and reasoning behind the changes... First of all, we're planning on phasing out the console log in the top left corner, so all the game information is supposed to be moved to other panels on the HUD (like joins/parts will be moved into chat box, and game events will be set up properly in the notify/centerprint panels respectively)... So that's why there are quite a lot more events added into the centerprints now. Second, the centerprints are given color coded information of the team it refers to, this is the most logical and unambiguous way considering our teams have fixed colors (red vs blue, not good vs bad).
However, the eventual goal I have will resolve both of those issues for everyone. Essentially, I want to create a global notification system to network game events/kill events to clients... Right now, we have a "killnotification" system which sends events to panels and with centerprints, however the system is incomplete and not appropriate for game modes to use properly. What i'm planning on doing is unifying this entire system, cleaning it up, and making use of it in ALL game modes... And what will that allow, you ask? #1: Translated game events (capture the flag currently has no translations for example, it's not possible yet), #2: Customizable event messages (yes, you will be able to set a variable to have a unique customized message... or you can just create your own language, like pirate mode or LOL mode.), #3: Cleaner, easier, and more consistent ways to program events into game modes.
The only reason I did not do this before merging the CTF code is because it is a MASSIVE undertaking, it's literally at least 50 hours of work, and i'm just so worn out from programming CTF already. However, I didn't want to wait for such a massive thing to get the benefits of the mostly completed CTF improvements.
Stalemate
Stalemates goal is to speed up the gameplay, it is to make it MORE DIFFICULT to hold a flag during the time of stalemate, I do believe stalemate accomplishes this quite well. Additionally, making the waypointsprites update periodically really is not worth it... It's actually quite a decent amount of work to create a system to update/refresh/clean up the waypointsprites for enemy flag carriers constantly like that, and I don't think it has much of a benefit in relation to the Stalemates goal. So, I should say, it's less about discouraging camping, and more about allowing the gameplay to progress faster by showing players where the flag carrier is. I don't understand where you get off saying "no def no attack" though, any time i'm FC in stalemate i'm always defending myself-- I generally get hunted down when that happens, so... seems to me like the system works as it should.
Oh and... We can't really do new sounds for kill of FC/voluntary drop like that, or at least I certainly can't do them well enough-- I don't really think they're necessary at all though honestly, as the game notifications already cover the proper information.