On September 30 2010 13:27 GGTeMpLaR wrote:
I think everyone can agree that this is the most epic stalemate ever
+ Show Spoiler +
I think everyone can agree that this is the most epic stalemate ever
+ Show Spoiler +
story?
Forum Index > SC2 General |
Angelbelow
United States3728 Posts
On September 30 2010 13:27 GGTeMpLaR wrote: I think everyone can agree that this is the most epic stalemate ever + Show Spoiler + story? | ||
InToTheWannaB
United States4770 Posts
While StarCraft II and chess are both strategy-based games that require careful planning, great timing, and the ability to anticipate an opponent's movements, they're not entirely comparable in this situation. With respect to stalemates in StarCraft II, it's not only a matter of defining "what is a stalemate" and when one has occurred, it's also one of deciding how to address that stalemate once it's been identified. Do both players tie? Does one win and the other lose? Are both players penalized? If so, how? There's a lot of questions that need to be answered before we can move forward. If we're going to step in, we want to make sure that we do it right. What the hell is wrong with blizzard? I just don't understand how they don't know it should be a no contest. What Starcraft tournment in the last 10 years would decide a draw by some arbitrary measure? Ladder should be no different from a tournment. If its a draw its as if the game was never played. | ||
terranghost
United States980 Posts
On September 30 2010 13:22 StarSense wrote: Practically every Blizzard map, unlike in BW, has open empty space around it for superfun floaty terran building time. New. Maps. Hmm keep in mind that giving up the massive open air only areas not only means that terran buildings can't retreat there but also means that banshees/mutas/phonenixes also lose a retreat area. (and other air units as well) A "stalemate" caused by a terran flying buildings to the open air can really only be caused if the map is mined out. This situation rarely occurs. You could say that but if you base race a terran he will fly his buildings away. And you won't be able to finish him off. But ask your self would this be any different if any race just brought a worker along with them everytime a major attack force left and then just constructed a random hatchery/cc/nexus/pylon/depo in order to stay in the game. If you are in the lead and you know you can slaughter all the ground troops he has left go ahead and send a probe/drone with your attack force so if the terran ends up trying to base trade you just build something kill his base then go back and kill his force yes its annoying that you have to rebuild so you can kill the floating buildings but he won't kill you. Keep my mind it has already been established that your army could beat the terran army. If it is not the case that your army would be able to beat the terran army the floating buildings is not the problem as he could of just as easily brought an scv with his force (it would be beneficial to do this anyway as most forces have mech units for repair if not you can build bunkers for your infantry). Back to the OP A true stalemate would be something like this (which keep mind has nothing to do with floating buildings) Bases have been killed there is a depo and a terran force (no minerals for a rebuild) that consists of mainly siege tanks. The toss force has a force of mainly zealots and a pylon (likewise no money for a rebuild) The zealots don't want to charge a tanks that are in siege mode. The siege tanks don't want to go into siege mode for fear of getting raped by the zealots. Just like with terran players being anal about not wanting land there buildings and the other races getting pissed being forced to get some AA to go kill it there would be just as many people that would be to anal to push accept on a stalemate for the situation I gave. (I would still rather have that option) I don't think it is possible to make it where the game notice that the game is in a stalemate other than doing something like this if neither player kills a unit harvests money within a certain time limit game ends in stalemate automatically. (This would be the only way IMO to get rid of the chance that someone would be too anal to push yes to accepting a stalemate.) IMO we just need a vote to call a draw function. As for tournaments it would be up to the tournament officials to call the draw if the players can't agree. | ||
TSM
Great Britain584 Posts
| ||
Ryhn
United States509 Posts
On September 30 2010 13:19 AJMcSpiffy wrote: With respect to stalemates in StarCraft II, it's not only a matter of defining "what is a stalemate" and when one has occurred, it's also one of deciding how to address that stalemate once it's been identified. Do both players tie? Does one win and the other lose? Are both players penalized? If so, how? If there's anything Team Fortress 2 has taught me over the years, it's that in the event of a stalemate everyone loses. | ||
BluzMan
Russian Federation4235 Posts
On September 30 2010 13:31 tertle wrote: void CheckTime() { if (gamelength > 60) //minutes drawButton.enabled = true; } void CheckDraw() { if (Player1.drawButton.pressed && Player2.drawButton.pressed) drawGame(); } Blizzard should employ me... Who the fuck names fuctions with capitalized letters first. EDIT: That is unless they are class factories but these are not. | ||
NicolBolas
United States1388 Posts
As far as whether or not it is THAT simple, I think the main point is, if you look at what blizzard is capable of, how had do you think adding something as simple as a draw button would be for them? Here's the problem. The general reason for stalemates at the low level is because people are griefers. They know they can fly their buildings where the enemy can't attack them and just leave them there. They do not want a draw. They want a win, and they're willing to leave their computer running until they get it. A draw button, the option to offer a draw and accept/reject it, will not stop griefers. Blizzard's concern is not the difficulty of implementing any particular solution. It is in implementing the right solution, one that can deal with griefing while still preserving gameplay. | ||
TheGrimace
United States929 Posts
On September 30 2010 17:48 Ryhn wrote: Show nested quote + On September 30 2010 13:19 AJMcSpiffy wrote: With respect to stalemates in StarCraft II, it's not only a matter of defining "what is a stalemate" and when one has occurred, it's also one of deciding how to address that stalemate once it's been identified. Do both players tie? Does one win and the other lose? Are both players penalized? If so, how? If there's anything Team Fortress 2 has taught me over the years, it's that in the event of a stalemate everyone loses. Indeed. If you can't win, you lose. I'll be interested to see how and when Blizzard actually responds. I'm not really holding my breath though. | ||
Cyber_Cheese
Australia3615 Posts
On September 30 2010 13:25 Tsagacity wrote: Show nested quote + That wasn't a stalemate though... He had no way to stop that zergling.On September 30 2010 13:24 mierin wrote: Stalemates are just a part of the game. One of the most perfect stalemates I've ever seen is MasterAsia vs. TT1. the zealot would have won it if he'd attacked much sooner | ||
Teton
France1656 Posts
On September 30 2010 13:31 tertle wrote: void CheckTime() { if (gamelength > 60) //minutes drawButton.enabled = true; } void CheckDraw() { if (Player1.drawButton.pressed && Player2.drawButton.pressed) drawGame(); } Blizzard should employ me... Moar something like that : void OnStaleMate(object sender,EventArgs e) { InGameMenu::ShowDrawButton(); } void OnDrawClicked(object sender,EventArgs e)) { Player p; if(Game::GetPlayerId(0)==(Player)sender) p =Game::GetPlayerId(1); if(Game::GetPlayerId(1)==(Player)sender) p =Game::GetPlayerId(0); if(p.ShowDialog("Your opponent wants to draw")==DIALOG_OK) Game::DrawGame(); else sender.Write("Your opponent did't accept to draw."); } Event oriented :D | ||
Chizambers
United States126 Posts
The one problem I still see with this is on maps with islands, Terran would still be able to float his buildings and land them on an island. But, I don't really see this as that big of a deal. I have yet to experience a draw, and they are very rare. I have played about 600 matches total and haven't had one yet. So, it's not nearly as important as some of the other issues in the game right now. | ||
sluggaslamoo
Australia4494 Posts
On September 30 2010 13:35 Seide wrote: Show nested quote + On September 30 2010 13:31 tertle wrote: void CheckTime() { if (gamelength > 60) //minutes drawButton.enabled = true; } void CheckDraw() { if (Player1.drawButton.pressed && Player2.drawButton.pressed) drawGame(); } Blizzard should employ me... Synchronization? Error catching? direct access to other class variables... On September 30 2010 18:23 Teton wrote: Show nested quote + On September 30 2010 13:31 tertle wrote: void CheckTime() { if (gamelength > 60) //minutes drawButton.enabled = true; } void CheckDraw() { if (Player1.drawButton.pressed && Player2.drawButton.pressed) drawGame(); } Blizzard should employ me... Moar something like that : void OnStaleMate(object sender,EventArgs e) { InGameMenu::ShowDrawButton(); } void OnDrawClicked(object sender,EventArgs e)) { Player p; if(Game::GetPlayerId(0)==(Player)sender) p =Game::GetPlayerId(1); if(Game::GetPlayerId(1)==(Player)sender) p =Game::GetPlayerId(0); if(p.ShowDialog("Your opponent wants to draw")==DIALOG_OK) Game::DrawGame(); else sender.Write("Your opponent did't accept to draw."); } Event oriented :D You don't use object oriented programming or error catching for game engines as look ups and exceptions wastes cpu processing which could be better spent on things like AI. Asynchronous events while convenient, are completely pointless in game engines where everything runs in a loop. It just makes garbage collection difficult, and again wastes processing. Also there is a reason you guys don't work for blizzard. Its because you aren't using C++. (Take this lightly, its supposed to be written in a joking manner) | ||
BluzMan
Russian Federation4235 Posts
On September 30 2010 19:18 sluggaslamoo wrote: Show nested quote + On September 30 2010 13:35 Seide wrote: On September 30 2010 13:31 tertle wrote: void CheckTime() { if (gamelength > 60) //minutes drawButton.enabled = true; } void CheckDraw() { if (Player1.drawButton.pressed && Player2.drawButton.pressed) drawGame(); } Blizzard should employ me... Synchronization? Error catching? direct access to other class variables... Show nested quote + On September 30 2010 18:23 Teton wrote: On September 30 2010 13:31 tertle wrote: void CheckTime() { if (gamelength > 60) //minutes drawButton.enabled = true; } void CheckDraw() { if (Player1.drawButton.pressed && Player2.drawButton.pressed) drawGame(); } Blizzard should employ me... Moar something like that : void OnStaleMate(object sender,EventArgs e) { InGameMenu::ShowDrawButton(); } void OnDrawClicked(object sender,EventArgs e)) { Player p; if(Game::GetPlayerId(0)==(Player)sender) p =Game::GetPlayerId(1); if(Game::GetPlayerId(1)==(Player)sender) p =Game::GetPlayerId(0); if(p.ShowDialog("Your opponent wants to draw")==DIALOG_OK) Game::DrawGame(); else sender.Write("Your opponent did't accept to draw."); } Event oriented :D You don't use object oriented programming or error catching for game engines as look ups and exceptions wastes cpu processing which could be better spent on things like AI. Asynchronous events while convenient, are completely pointless in game engines where everything runs in a loop. It just makes garbage collection difficult, and again wastes processing. Also there is a reason you guys don't work for blizzard. Its because you aren't using C++. (Take this lightly, its supposed to be written in a joking manner) Lol, if you analyze this seriously, this has interface code randomly calling gameplay functions and gameplay code randomly altering interface, so this is wrong on many many levels. Interface code should know nothing about how exactly draw conditions are handled and game code should never call interface functions directly. Hanging the game thread to wait until your ShowDialog returns is not a good idea either. | ||
Zefa
United States297 Posts
On September 30 2010 17:01 Angelbelow wrote: Show nested quote + On September 30 2010 13:27 GGTeMpLaR wrote: I think everyone can agree that this is the most epic stalemate ever + Show Spoiler + http://www.youtube.com/watch?v=tkPAJjQYv-Q story? Chalrenge vs TheRock. Basically map mind out and chalrenge Red toss kept defending vs everything rock threw at him and every attack actually made chalrenge stronger with the mind controls and after over an hour of the game, the ref steps in and declares game a draw. | ||
arb
Noobville17918 Posts
On September 30 2010 13:25 hmunkey wrote: They should just add a timer on building hover. Make it five minutes or so and stalemates would pretty much be over. Of course they could still happen, but they'd be much less common to the point that they would only trivially matter. Well terran isnt the only race that causes them you know theres been plenty like 2 cannons and a pylon vs like 6 lings or something stupid like that that no one can win | ||
standalone
Norway73 Posts
And you know what? Afterwards i felt like shit and i apologized to the guy. I hurt myself by not being big enough to simply admit defeat when i had lost and ended up wasting my own, and my opponents time. That was the last time i created a stalemate. My point is that a lot of stalemates could be avoided if we were more willing to accept defeat when we have lost. Also if we don't, we are in fact hurting ourselves (regardless of whether it ends up in a win or not) since we are wasting time we could have spent practicing, having fun or doing IRL stuff. | ||
lololol
5198 Posts
| ||
dbddbddb
Singapore969 Posts
On September 30 2010 20:01 standalone wrote: So i lost and raged once and wasted 20 minutes out of someones life by flying my building around. And you know what? Afterwards i felt like shit and i apologized to the guy. I hurt myself by not being big enough to simply admit defeat when i had lost and ended up wasting my own, and my opponents time. That was the last time i created a stalemate. My point is that a lot of stalemates could be avoided if we were more willing to accept defeat when we have lost. Also if we don't, we are in fact hurting ourselves (regardless of whether it ends up in a win or not) since we are wasting time we could have spent practicing, having fun or doing IRL stuff. your example isnt a stalemate. if you had completely destroyed all his probes and he had not enough money to make an air unit to kill your floating CC, it would be a stalemate. | ||
RHoudini
Belgium3626 Posts
If for a certain period of time (say 5 or 10 minutes) not a single unit or building is made or lost, you can safely conclude that the game is a stalemate and a draw should be awarded. A draw should impact the ratings, if I draw against a stronger opponent I should win some points and my opponent should lose some. Exactly like in chess where draws are very frequent. | ||
attackfighter
Canada308 Posts
10/10 blizzard = GOD | ||
| ||
StarCraft: Brood War Dota 2 Counter-Strike Other Games summit1g11572 hungrybox1265 Artosis753 JimRising 651 shahzam517 Mew2King341 Livibee289 Maynarde137 ViBE107 Organizations
StarCraft 2 • Berry_CruncH260 StarCraft: Brood War• AfreecaTV YouTube • intothetv • Kozan • IndyKCrew • LaughNgamezSOOP • Laughngamez YouTube • Migwel • sooper7s League of Legends |
WardiTV Invitational
BSL: ProLeague
TerrOr vs Dandy
XuanXuan vs Dark
Korean StarCraft League
Acropolis
SOOP StarCraft League
CranKy Ducklings
SOOP
herO vs Cure
SC Evo Complete
PassionCraft
BSL: ProLeague
Sziky vs Dienmax
Jimin vs RaNgeD
[ Show More ] CSO Cup
Sparkling Tuna Cup
WardiTV Invitational
Online Event
Tenacious Turtle Tussle
The PondCast
|
|