Thursday, November 29, 2012

Eric Lippert is leaving Microsoft

Nothing like a fine morning with a cup of coffee and reading news articles and blogs to start off the day, which is practically forged inside my brain as a routine.

I turn on my Google Reader and bam, suddenly I felt like I got hit on the head by a hammer.

I nearly spew my coffee out my mouth when I saw Eric Lippert, a principal developer of C# compiler is leaving Microsoft. I'm sure many enthusiastic C# programmers have already seen the news:

It's pretty surprising how reading a single sentence can make a person s$!t bricks.

Eric Lippert is one of my heroes and a role model for various reasons. His seemingly endless knowledge about the C# language and compiler design is what captivated my interest on him (no homo) in the first place. To list a few posts written by him in his own blog and on Stack Overflow:

Reading each and every one of his posts constantly remind me that geniuses truly do exist in the world and how I basically know nothing when compared to the likes of Eric Lippert.

But what truly enraptured me about Eric Lippert (again, no homo) is the fact that you could make a topic that's generally perceived as dull, nerdy and/or boring then turn it into something very interesting for others to hear - His communication ability is just absolutely fantastic. 

It's really heartbreaking for me to see him leave Microsoft, but I'm also relieved to know that he will still be a part of C# community.

I wish Eric Lippert the best of luck on his new journey and I will continue to support him.

Monday, November 26, 2012

Regions are a code smell? Please!

I'm a C# developer who uses #regions on a daily basis.

There is a fair chance that the above statement threw off a lot of C# developers. Some may even start running riot, accusing me of "jumping the shark" or calling me a "cowboy coder" whatnot.

It's pretty shocking to see many C# developers hating #regions passionately. I have to admit that this has left me completely baffled for a long period of time.

Yes, even the man himself abhors regions. 

Observing all the strong opinions made by the community in programmers stackexchange had nearly convinced me into not using #regions. But then I remember seeing many code samples and tutorials written by expert programmers like Josh Smith use regions extensively. 

Then it suddenly hit my head. These people complaining about #regions have either never developed a WPF application nor deployed a tangible WPF application that utilizes the core functionality and features (MVVM, data binding, command interface etc).

Most of the code samples I've seen that uses #region blocks are from WPF applications. In fact, after much googling I think it is safe to say that it's hard to find a WPF code that doesn't utilize #regions.

The rationale for this is pretty straight forward: you and your companions will never, ever have to look at the folded lines of codes again! Ok, "Never" might be pushing it a little bit too far, but hopefully you get my point.

You might be saying "Ok, the lines of code you wrote does not have to be read again, there's something clearly wrong with the code you wrote". Don't be ridiculous, we wouldn't even have this discussion to begin with if that were the case. 

I sense an in-depth explanation is in order so I'll demonstrate an example: To reap the benefits of WPF, you are often required to do some "setups" to properly get your UI to display what you want. To use a WPF feature known as Data Binding you first need to implement INotifyPropertyChanged interface. Then you define a private variable for your property to refer to, a PropertyChangedEventHandler event, and a user defined property to perform the notification between your UI and business logic of the previously defined private variable.  (Digressing momentarily, if you are a WPF developer who doesn't know what data-binding is, this is probably a good place to stop reading this post and get yourself to really learn how to use WPF).

Here is the important bit: those properties, notification event and any other potential code to make the WPF feature to work are merely prerequisites to get your code working. In other words, once you verify the data binding working as intended, there is practically no reason to look at your setup code again. Now for those who are versed in WPF will readily recognize that all this code typically goes inside your ViewModel so consequently, that is where you see the regions used most frequently.

The following is a sample code from Josh Smith's WPF Treeview Tutorial:

Seriously, all of what's above is just noise to me. Without even having to look at the code, I expect the necessary properties and interface methods to be in the viewmodel so scrolling down through all this unnecessary, expected information is just a waste of time. 

Now what would be preferable to see is the following:

Immediately, I know that when I'm reading the code, I will probably never have to look at the folded portions, because all they do is relay the information from UI to Business Logic (Model). Everything is organized in a nice fashion, so if by any chance we really needed to fiddle around with our viewmodel, we immediately know where to add our necessary data/property/interface methods. Had the regions not been there, I would've had to scroll miles down my IDE to determine exactly where everything goes.

Admittedly, the above example might be taking things too far - it isn't necessary to literally group everything in regions. For instance, I think just wrapping the properties would've been sufficient.

But the important point I wanted to bring is this: it's OK to have a dogmatic belief or a strong preference towards a particular coding style, as long as it logically makes sense with your colleagues and it helps solving a particular problem. Part of what makes a good programmer is the ability to choose the right tool and having the correct approach to the problem you are trying to solve. The real harmful practice is to state an absolute such as "Never or Always" without considering other domains (Goto statement is an epitome of this, at least for the case of C#).Also remember that programming languages evolve continuously - what might've been a bad practice in the past can very well be the recommended approach now. 

As for the fellow developers, including Jeff Atwood whom I have a lot of respect towards, you can keep hatin' on the #regions but for us WPF developers, no thanks. We will keep using them :P

Sunday, November 18, 2012

Grand Theft Auto 5 - Soviet Russia

Why buy the game when you can play it IRL?

Monday, October 1, 2012

프로그래밍을 한글로?

Programmers.Stackexchange에 올려져 있는 글을 읽는중 어떤 C# 소스코드가 그리스어로 써져있는 것을 발견하였다. 참 신기하다고 생각하던 와중, "어쩌면 한글로도 코딩이 가능하지 않을까?" 라고 의문이 생겨 한글로 간단한 프로그램을 짜봤다.

   1:  namespace 대한민국
   2:  {
   3:      public class 학생
   4:      {
   5:          public string 이름 { get; private set; }
   6:          public string 좌우명 { get; private set; }
   8:          public 학생(string 이름, string 좌우명)
   9:          {
  10:              this.이름 = 이름;
  11:              this.좌우명 = 좌우명;
  12:          }
  13:      }
  14:      public class 대학교
  15:      {
  16:          private List<학생> 재학생목록 = new List<학생>();
  18:          public void 입학(학생 입학생)
  19:          {
  20:              재학생목록.Add(입학생);
  21:          }
  23:          public void 재학생출력()
  24:          {
  25:              foreach (학생 선택된학생 in 재학생목록)
  26:              {
  27:                  Console.WriteLine("이름: {0}", 선택된학생.이름);
  28:                  Console.WriteLine("좌우명: {0}", 선택된학생.좌우명);
  29:              }
  30:          }
  31:      }
  32:      public class 프로그램
  33:      {
  34:          static void Main(string[] args)
  35:          {
  36:              대학교 스쿨오브헬 = new 대학교();
  37:              스쿨오브헬.입학(new 학생("전땅끄", "본인은 단돈 29만원과 땅끄로 이 신성하고 거룩한 국가의 민주주의를 발전시켰소"));
  38:              스쿨오브헬.입학(new 학생("이피카츄", "여러분 이거 다 거짓말인거 아시죠!!!"));
  39:              스쿨오브헬.입학(new 학생("빵상아줌마", "빵빵 똥똥똥똥 땅땅 따라라라라~~~"));
  41:              스쿨오브헬.재학생출력();
  42:          }
  43:      }
  44:  }


보다시피 public, class, string 같은 키워드를 제외하면 한글로도 코드를 작성할 수 있다. 참으로 신기해서 이 기능이 C# 아니면 Visual Studio 에서 지원해 주는 기능인지 알아본 결과, C#에서 자체적으로 지원해 주는 기능이라는걸 금방 알 수 있었다.

CLI내 C# 기준에 적힌 바로는: 

A source file is an ordered sequence of Unicode characters.
I.8.5.1 Valid names
All name comparisons are done on a byte-by-byte (i.e., case sensitive, locale- independent, also known as code-point comparison) basis. Where names are used to access built-in VES-supplied functionality (e.g., the class initialization method) there is always an accompanying indication on the definition so as not to build in any set of reserved names. 

즉, 소스 코드내에서의 이름 비교는 바이트 단위로 하기 때문에 시스템 로케일과 상관없이 유니코드를 지원하는 언어는 아무것이나 쓸 수 있다는 뜻이다.

유니코드 지원이라고 할지라도 다른 언어는 잘 모르겠으나 한국어의 경우는 거의 실용성이 없을듯 싶다. 우선 윗 코드만 참고해도 영문과 한글을 번갈아 가면서 읽는것도 다소 난해하게 느껴며 그 이상으로 영문으로 코드를 작성하는 것 보다 훨씬 더 많은 키를 입력해야 한다는 느낌도 강하게 든다.

혹시나 한글로 소스코드를 짜보신분이 있으신지 궁금하다. 독자들중 그런 경험이 있으신 분이 있다면, 그 경험담을 공유해 주셨으면 한다.

Sunday, September 16, 2012


 [05:08:31 PM] [l46kok] did you press on that esc
 [05:08:37 PM] [Squally] ahh the disadvantage of using the wc3 client, randomly misclicking the X button while getting up 
 [05:08:42 PM] [l46kok] lol
 [05:08:52 PM] [l46kok] thats a universal problem for all UI programs LOL
 [05:09:07 PM] [l46kok] unless if u mean closing application should be command based
 [05:09:10 PM] [l46kok] !quit
 [05:09:11 PM] [l46kok] halp
 [05:09:13 PM] [l46kok] ?
 [05:09:16 PM] [l46kok] What the hell happened to the bot
 [05:09:24 PM] [Squally] well you just closed it
 [05:09:26 PM] [l46kok] LO
 [05:09:29 PM] [l46kok] OMG LOL
 [05:09:32 PM] [l46kok] NO I MEANT TO
 [05:09:34 PM] [l46kok] LOL WAIT
 [05:09:43 PM] [l46kok] NOO LOL
 [05:09:47 PM] [l46kok] ASDFQWERZXCV
 [05:09:54 PM] [l46kok] that's a picture worthy of
 [05:09:54 PM] [Squally] double fail
 [05:09:57 PM] [Squally] great minds think alike?
 [05:10:00 PM] [l46kok] LOL
 [05:10:01 PM] [Squally] and fail alike apparently
 [05:10:02 PM] [l46kok] AHAHAHA

Hahahahahaa!!!  Mega Fail XDDDDD

Sunday, September 2, 2012

Simple Plan - Save You

One of my favorite tracks from Simple Plan.

» Show Lyrics; 가사보기

Saturday, September 1, 2012


From xkcd -

I'm sorry I had to post this because I think I just ran into this situation myself lately HAHA!!!

Such an enlightening cartoon. 

(Yes, I know it's a joke)

Thursday, August 30, 2012

.NET Regex Tester

I came across a really good Regex tester for C# so I thought I'd share it

Yes, this one actually gives you a regex expression back that is C# compatible.

Keep it simple stupid

I love WPF. I write love songs about it. It also happens to be my main area of expertise when it comes to .NET framework but there are certain things about WPF that drove me nuts when they WPF-tized a former winforms control.

RichTextBox is one of them.

I needed a very simple textbox that can programmatically highlight a portion of my text given an index and a length. Now in Winforms, I can simply call the Select function on the text and change the selection color of it.
rtb.Select(startindex, endindex);  
rtb.SelectionColor = Color.Red;

Boom, two lines. Job done. How simple and elegant is that? You would think that you can get away doing the same thing in WPF but instead, they have to f$*% it up so hard that they make me write this monstrosity of a code:

 private static TextPointer GetTextPointAt(TextPointer from, int pos)  
     TextPointer ret = from;  
     int i = 0;  
     while ((i < pos) && (ret != null))  
       if ((ret.GetPointerContext(LogicalDirection.Backward) == TextPointerContext.Text) || (ret.GetPointerContext(LogicalDirection.Backward) == TextPointerContext.None))  
       if (ret.GetPositionAtOffset(1, LogicalDirection.Forward) == null)  
         return ret;  
       ret = ret.GetPositionAtOffset(1, LogicalDirection.Forward);  
     return ret;  
 internal string Select(RichTextBox rtb, int offset, int length, Color color)  
     // Get text selection:  
     TextSelection textRange = rtb.Selection;  
     // Get text starting point:  
     TextPointer start = rtb.Document.ContentStart;  
     // Get begin and end requested:  
     TextPointer startPos = GetTextPointAt(start, offset);  
     TextPointer endPos = GetTextPointAt(start, offset + length);  
     // New selection of text:  
     textRange.Select(startPos, endPos);  
     // Apply property to the selection:  
     textRange.ApplyPropertyValue(TextElement.BackgroundProperty, new SolidColorBrush(color));  
     // Return selection text:  
     return rtb.Selection.Text;  

WHY SHOULD I HAVE TO GO THROUGH SO MUCH TROUBLE FOR SOMETHING SEEMINGLY SIMPLE? Wtf is the reason that I have to deal with entirely new paradigms like Textpointers for such a simple feature? Oh M$FT wanted to make the control more robust and powerful? Well what the hell is the problem with making a new control then? Call it Even-More-Rich-Text-Box I don't f**king care. And if I really wanted a powerful texteditor, I'd be using Avalonedit anyways. Leave my Richtextbox alone.

Sure, there is an option to include a element host and just use the Winforms version of it, but the richtextbox I was including was inside a WPF host control running as a Winforms application. Going Winforms-WPF-Winforms (is this even possible?) would be the last retarded thing I do before I cut my throat. And no, I didn't have a choice to build the application in WPF to begin with.

Look, my point is this. It's great that Microsoft was trying to provide the users with more features, but I don't want to have to use a Swiss army knife to carve a chicken. Textbox lacks the feature I need, other powerful editors like AvalonEdit and ScintillaNET is an overkill. RichTextBox is just the right tool I need, except they made it much more complicated than needed for typical use.

I love WPF, I really do. But sometimes, ridiculous upgrades on features or radical changes in paradigms really frustrates me. And I'm sure I'm not the only developer who faces this kind of a problem.

Keep it simple, Stupid.

Thursday, August 23, 2012

여자어 사전

사귀시는 여자 있으신 분은 반드시 이거 참조하세요. 프린트 하시고 밖에 나갈때 꼭 가지고 나가세요.
» 사전 보기 «

Tuesday, August 21, 2012

PHP - It's time to reject the bad

Smoking is bad.

Drunk driving is bad.

Windows Vista is bad.

There are many things we encounter in life that we inherently know are bad. PHP is bad, but despite the myriad of evidences presented over the years of what makes PHP a truly bad language, it, to my biggest dismay, still remains the most used web scripting language in the world.

It's pretty much been established by most programmers that PHP is a bad language and there already are many, many, many places that already discusses what an abomination of this language is. Seriously, if you don't believe me, just google "Why PHP is bad" and "Why PHP is good", I guarantee you that you won't find much results for the latter keyword. If this still didn't convince you, let the numbers do the talking for you. But if you care about what I think on this matter, read on.

Monday, August 13, 2012




Thursday, August 9, 2012

프로젝트 Fate 모집 공고 (한글)

모집 인원: 최소 5명, 최대 10명

Project Fate 개발팀 모집 공고

개요: Fate / Another를 스탠드 얼론 기반으로 개발
프로젝트 개발 시작일: 2013년 1월
예상 개발 기간: 2년~3년
현재 팀 멤버: l46kok, Squally, Hecatic, Hyeon

저희와 함께 Fate / Another를 스탠드 얼론 기반으로 제작하시고 싶으신 분들을 찾고 있습니다.

게임 개발에 관심이 있으시며 페어를 사랑하시고 무엇보다도 열정을 가진 여러분들의 능력이 절실합니다.

무한한 가능성을 가진 이 게임을 지구상에서 최고로 좋은 게임으로 만들어 봅시다!

Project Fate Recruitment (English)

Aimed team size: 5 minimum, 10 maximum

Project Fate Development Team members recruitment post

Abstract: Create Fate / Another into a standalone game
Project launch date: January 2013
Expected length of development: 2 to 3 years
Current Team Members: l46kok, Squally, Hecatic, Hyeon

We are now recruiting team members to develop Fate / Another into a standalone game.

We are in a great need of people who are interested in game development, loves fate and above all, have a burning desire to make this project into a reality.

Fate / Another is a game that has limitless potential to make it into a big name. Let us make it happen with our hands!

Friday, August 3, 2012

Internet Community - An Ethical Consideration

Those of you who have been following my blog despite my seldom and spontaneous blog posts are likely to be aware of a pattern that I developed here. That is, although I write in both Korean and English, any posts that exceed a certain length or require a little bit of an in-depth thinking than my usual posts are always written in English. I know I've probably reiterated this fact a few times, but I only know how to perform academic or professional writing in English as I've spent my last ten years of education in the United States.

This post however, should probably be written in Korean as it directly addresses several peculiar situations that I have witnessed in our Fate/Another naver cafe. To my dismay, my Korean writing skills are far too pathetic to deliver the thoughts in my head to anyone with clarity. Actually, considering how difficult writing can be as there are people who spend their entire life just on learning how to write, I can't say I do such a spectacular job at writing in English either.

So for this particular post, I'm going to take a slightly different approach. Since I have to start from somewhere, why not with a language I'm most comfortable with? And then when it's time to make a post in the Korean language, I'll simply be translating what I have wrote on this post. Time consuming, sure but it's hell of a lot better than writing gibberish that could mislead the audience.

Sunday, June 24, 2012


For the program I'm developing, because we decided to use remoting service instead of WCF (.....) I had to go relearn how to marshal objects as the program was going to use it extensively but soon enough I thought to myself, "Do I really know what marshalling is?"

When I was taking .NET course for my undergrad, my professor briefly covered the topic of marshaling but he never really explained it in depth or rather, clear enough for me to understand. What's worse is this terminology isn't even clearly defined on the internet (Seriously, google "Marshalling" and it will only point you to a Wikipedia article which only gives an abstract explanation).

So I'm going to post an explanation I found on web that I personally believe is the clearest way you can explain what marshaling is.

Marshaling is the act of taking data from the environment you are in and
exporting it to another environment. In the context of .NET, marhsaling
refers to moving data outside of the app-domain you are in, somewhere else.

When you work with unmanaged code, you are marshaling data from your
managed app-domain to the unmanaged realm. Also, when transferring data
between app-domains (to another application, on the same or another
machine), you are also marshaling data from your app-domain, to another

Friday, June 22, 2012

Merge Sort vs Quick Sort

Merge Sort
Quick Sort
Time complexity (Average): O(n log n)Time complexity (Average): O(n log n)
Time complexity (Worst): O(n log n)Time complexity (Worst): O(n^2)
(Occurs when list is sorted)
Stable sort

Not dependent on any factors
Average case = Worst Case
Not a stable sort

Dependent on randomness of list
Memory: O(n)
Additional memory space required
Memory: O(log n)
Memory Complexity (Best): O(1)
Little additional memory space required

Sunday, May 6, 2012

A whole new world

지금 봐도 명작이다.

» Click to show lyrics; 가사 보기 «

Monday, April 16, 2012

IdrA Quotes Compilation

Just lol.

Wednesday, March 14, 2012

New Fate/Another mode draft - Oddball

Most of you should know that I am the current developer of Fate/Another by now.

While I was pondering about the current problem regarding Deathmatch, there's a new game mode that popped up in my mind that may be really appropriate for Fate/Another.

Let me explain about the problem in Deathmatch. The biggest issue there is with Deathmatch mode is that defending instead of attacking is a lot more advantageous in many situations. This is mostly due to the fact that the defending team is able to acquire sight very easily of where they are defendnig utilizing wards. This means that the defending team can safely engage the attacking team while the attacking team has to fight in the dark. In other words, this is a risk and a penalty the attacking team must take on.

As such.. this led to many situations where both sides simply do not choose to engage in combat. Both sides would camp for a long time and one team would decide to attack only because they would get sick of being bored or they are forced to attack for a special reason (I.E: TA Assassination).
Over the years, several clever solutions were invented by the users such as Select Position (where one team would have a very ideal composition to penetrate a defense vs the opposing team having an ideal composition for defense) or enforcing a house rule (where teams spawning from the right side are required to attack the opposing team).

Even in the case of Select Position, many tournament games revolved around both sides camping anyways despite the fact that one team might have an ideal composition for penetrating a defense, simply because the advantage of camping over defending is not dismissable. After all, everyone plays to win.

This is an epitome of a systematic failure of game design in my opinion. The only reason that this system seemingly worked so far is because of the roles of certain characters which forces the enemy to attack, most prominently True Assassin but also Caster and Gilgamesh to a degree, and because people in general opt to battle rather than continue a camp game. There is also the point that despite such systematic failure, the game is well balanced enough for users to enjoy it but this does not invalidate the point I am trying to make.

Other games are systematically designed in a way that "attacking" is a primary factor of the game. For instance, there are games where one team has to attack the other to win (I.E: Counter-Strike), where there is a strategic value and huge merit to attacking (I.E: Starcraft), where players engage in attacking to increase their chance to victory (I.E: DOTA, LoL). Yes, creeping is part of attacking as well for the last example.

Therefore, I firmly believe an introduction of a mode, where engaging in a combat is a primary factor, should be something that Fate / Another players would desire. After all, they went as far as creating house rule to compensate for this part, so the demand for this is pretty clear.

So I'd like to introduce oddball (Or Battle for the Holy Grail, I don't know, something appropriate for Fate/Another).

The gameplay is as follows (Do not focus on the numbers, they are easily changeable):
  • A team is victorious if they win 2/4/6/8 rounds. They switch sides between rounds.
  • Team wins a round by gathering 150 oddball points. Points are awarded to a team periodically if one of the team member holds the oddball.
  • Oddball spawns 15 seconds after the match begins at the center of the bridge.
  • You gain more points if you stay in the center of the map (bridge), and less points more you stay away from the center. Square "zones" will be created (and be clearly visible) for scoring. (For now, assume 4 points per second if you are on the bridge or 1 point per second if you are close to the edge of the map. 0 points if you are literally at the edge.)
  • You are consistently revealed (by minimap ping, not by sight) and you also take periodic damage based on your maximum HP while you hold the oddball. Starts from 0.5% per second to 10% per second.
  • Players holding the oddball will be given a small experience gain (0.5% per second).
  • Players holding the oddball will not be able to use certain items such as Speed Gem, Ward Teleportation.
  • After the oddball has been dropped, players cannot retrieve it until after 2 seconds.
  • Players can choose to manually drop the oddball. 10 points will be deducted from the team the dropping player is in if chosen to do so.
  • All players respawn 15 seconds after death (Regardless of level). They will be revived somewhere close to the bridge but randomly positioned.

 The above list is an incomplete draft of what an oddball mode might look like but you should get the idea. It is a systematical way of having the players engage in combat very actively if they want to win. Originally, such modes would often be found on FFA-based games, most notably from Halo but with some tweaks, I believe this is something that can definitely be applied on Fate/Another.
There are several concerns and problems with this design. Let me list some that I can think of.
  1. Certain characters would be given an unfair advantage due to their skillsets.

    Solution->The only potential issue lies with True Assassin, Beamers, Tanks, and Caster.

    In case of True Assassin, his invisibility and movement speed basically makes it very difficult for other players to catch him. This is where the scoring system and the HP penalty comes from. Basically his ability to run is practically countered by the fact that there is less incentive to staying away from the center (which is where the majority of battle will happen), and because of the damage penalty, True Assassin would not be able to run for so long.

    For beamers, because the battles majorly happen on the bridge, the narrow space basically makes beamers easier to hit their targets. This is a good thing in my opinion. Using beams are often difficult in a game because it takes a long time to charge it up, players anticipate it and use protective scrolls in advance, and worst of all, players are "locked" into their position making them vulnerable for few seconds. A small incentive like this is probably favorable to beamers (and killing people from beams is where a large portion of fun in this game comes from)

    Finally, for Tanks, I do not think it is a big problem. Because of the penalty, sure it would be more advantageous for them to take the oddball but due to the nature of the gameplay, strategically deciding who would take the oddball would be a difficult thing to do as the pace of the gameplay will be very quick. Furthermore, as the oddball gives a small exp incentive, other players would benefit from taking the oddball. If anything, this could be a feature of playing a "tank" in this game, just like from Deathmatch.
  2. Camping would occur on the bridge itself

    Solution->In other words, this is a concern addressed to the casters and a bit about warding.

    For next Real version of the map, I plan to change the way territories are built so that the building cooldown is triggered base (like Dust Explosion). This should mitigate some issues with casters abusing their territories as ridiculously as they are now.

    Aside from that, I believe camping wouldn't be too big of an issue on this particular mode. If a team decides to camp, because of the oddball location the opposing team practically knows their position and does not necessarily have to fight in the dark. They also have many more options to engage the opponent as they can attack from all sides, making beams and certain combos such as nuke and MMB more effective.

    Finally, for wards I believe they are over-speced even now in Deathmatch. To make the camping less effective with wards (as sight is a big criteria of camping), the duration of wards in oddball mode will be reduced to 1-2 minutes. This change might even be applied in Deathmatch as well, that I have not decided.

I will add onto this list once I come up with more. Let me know what you guys think.

Saturday, January 14, 2012

Garena Customer Service

About 10 days ago, I made a ticket to the Garena Support Team, asking about a possibility of establishing a moderator for one of the Fate/Another rooms on Garena. Here is the e-mail I sent:

Greetings. My name is l46kok and I am the current lead developer of the Warcraft 3 custom map Fate/Another. Today, I come with a favor to ask. If it is not too much trouble, I'd like to be directed to an admin who can help me in establishing a moderator for the room War 3 RPG - War 3 Custom Map : FSN ROOM 1 (v1.24e). Several members from the mentioned room have already tried to make a petition back in July of 2010 to one of the admins of Garena, then the petitioners were replied back that the petition has been sent to the higher chain of command and were promised to hear back from then soon, but to this date, the petitioners have told me that they haven't gotten anything back. They have came to me instead and have asked me to make a petition instead under my name. I look forward to hearing back from you. Thank you very much and have a good day.

After 10 days later (Yes, because it really does take that long for them), this is the response I get:

Dear   l46kok ,
Sorry, but you can not ask us about these things
Best Regards,
Garena Customer Care Team


Ok.. Can I get a reason of WHY I can't ask a simple question of "Can you establish a moderator for one of your custom game rooms"? I mean if it isn't possible, is it so hard to come up with an answer such as "No, because it is not logistically feasible" but instead you have to tell me "You can't ask us that question". I mean it's not like I'm making a very unreasonable request, setting up a moderator for a room is something they should have already done.

What kind of shitty customer service is this? I made another inquiry about why I can't ask that question. Let's see how long the response takes this time.