안녕하세요 코인1입니다.

어제까지 3차 클베를 진행한 블레이드 앤 소울 게임을 하다 왔습니다.

3차 클베의 가장 큰 특징 중 하나는 바로 '활력 시스템' 의 도입입니다. 안해보신 분들 혹은 관심없는 분들을 위해 말씀드리면 이 시스템은 2차까지는 없었던 시스템으로, 던파나 드네의 그것과 비슷한 일종의 피로도 시스템 같은 것입니다. 와우로 치자면 휴식 경험치 같은 것인데요, 이번 3차 클베의 가장 큰 이슈가 되었습니다. 안좋은쪽으로요.

허벅지가 튼튼한게 큰 이슈인 우리 막내

활력 시스템의 구성은 이렇게 되어 있습니다.

활력 시스템의 기본과 상태 -

- 활력 상태는 활력 / 일반 / 피로 세 가지 상태로 분류됩니다.

- 활력 상태는 파랑 / 일반 상태는 초록 / 피로 상태는 회색으로 표시됩니다.

- 활력 상태에 따라 경험치를 각각 220% / 150% / 10% 로 적용 받습니다. (패치 전에는 200% / 100% / 10%)

그래서 광렙을 하게 되면 활력을 점점 소모하게 되어, 더 이상 경험치를 쌓을 수 없는 지경에 이르게 됩니다. 여기서 유저들은 첫번째로 '정기사용요금을 전제로 하는 게임이 사용자의 진행을 막는다는 것은 있을 수 없는 일' 이라며 크게 반발했었습니다.

이정도는 한 눈에 보면 알 수 있는 것들이고, 그 외의 사항에 대해서는 개발진에 의해서 자세하게 밝혀진 것들이 없었습니다. 그래서 게임을 해보면서 몇가지 연구를 조금 해봤습니다. 

1. 활력을 통해 얻는 경험치의 증가량은 사냥과 퀘스트 등 모든 경험치에 적용된다.

- 말 그대로 활력 상태별로 얻는 경험치 보너스는 모든 경험치에 적용됩니다. 계속 언급 되겠지만, 월드 오브 워크래프트의 휴식 경험치는 사냥 경험치에만 휴식 경험치 보너스가 붙습니다.

2. 활력의 소모는 경험치를 얻음으로서 소모된다.

- 활력은 시간 경과나 그 밖의 행동으로는 소모되지 않으며, 오직 경험치를 얻는 행위 (사냥, 퀘스트 완료 등)을 통해서만 소모됩니다.

3. 활력의 회복은 마을등 특정 활력 회복 구간 혹은 로그아웃을 하는 것으로 회복된다.

-  활력이 회복되는 곳에서 채팅이나 PVP, 제작 등의 일을 하면 활력을 회복시킬 수 있고, 로그아웃 하는 도중에도 회복이 가능합니다. 월드 오브 워크래프트에서는 마을의 여관에 가야지만 회복이 가능합니다.

4. 활력을 회복했다면 그 양 만큼의 경험치 보너스를 보장한다.

- 활력을 소모해 간다고 해서 최초 보장했던 양이 점점 줄어든다거나 하지 않습니다.

이정도 놓고 보면 뭔가 그렇게 큰 문제가 있어보이지는 않습니다. 그렇다면 도대체 무엇 때문에 활력 시스템이 이렇게 화제가 되었을까요? 그래서 캐릭을 다시 처음부터 키우면서 하나씩 체크를 해봤습니다.

먼저 최초 프롤로그를 마치고 나면 그때부터 활력 시스템이 시작됩니다.

위에서 보신 사진입니다만... 일단 처음 활력 시스템이 적용되면 레벨 4에서 레벨 11의 0% 그러니까 레벨 10까지 올릴 때 까지는 무조건 활력 220% 경험치를 보장받게 됩니다. 여기서 한가지 더 알 수 있는 활력 시스템의 법칙은

5. 활력은 최대치까지 차오르면 그 이상은 올라가지 않는다.

- 일단 활력 상태가 되면 그 활력을 일정량 소비하기 전 까지는 더 이상 활력이 회복되지 않습니다. 그러니까 활력이 최대치까지 차게 되면 더 이상 활력을 회복하는 일이 무의미하다는 말입니다. WOW 에서는 휴식 8시간에 경험치칸1칸씩 휴식 보너스를 받게 되며, 8칸이 최대입니다. (64시간)

여기서 유저들은 '정기 요금을 결제해도 게임을 자주 못하거나 주말에 겨우 접속하는 라이트 유저라면 활력을 다 쓰지도 못해서 마찬가지로 손해를 볼 것이다'라는 시나리오를 가정하고 역시 반발했습니다.

처음에는 '그래도 레벨 4에 11까지는 활력 220%를 보장해주니 꽤 많지 않은가?' 하고 생각을 했는데, 220%로 바뀌기 전 200%일때는 레벨 16까지 활력 상태가 보장 되었다고 하더군요. (이건 사실 확인을 해보지 못했습니다)

그래서 경험치 테이블을 작성해 보기로 했습니다.

최초 활력을 보장받는 구간의 경험치를 기록해봤습니다. 레벨 4부터 10까지 필요한 경험치의 총량은 35,600 입니다. 그러면 대충 '오 35600 씩이나 경험치 활력 구간을 보장받으면 다음 활력 상태일때도 그정도 양을 보장받겠군' 이라는 유토피아를 꿈꿨습니다. 그리고 초록 상태에서 가끔 게임을 접속하며 시간당 활력이 얼마나 회복되는지 지켜보기로 했습니다.

초록색 일반 상태의 활력을 거의 소모하지 않은 상태에서 약 3일을 들여서 활력이 차오르는걸 지켜봤는데 결과는 조금 참담했습니다. 무엇보다 레벨 4-10 까지 활력 보너스를 보장하던 구간이, 11에 오르자마자 13의 0%, 그러니까 약 2레벨이 조금 안되는 구간만 보장을 하는 것으로 태도를 싹 바꾸는 통에 멘탈 붕괴될 뻔 했습니다. 레벨 11과 12는 각각 필요 경험치가 7200, 7800 밖에 되지 않습니다. 최초 35600의 활력 보너스를 제공하다가 갑자기 절반 정도로 뚝 떨어져버리게 된 샘입니다.

레벨 27 캐릭터는 말할 필요도 없지요. 활력이 완충되기까지는 24시간 이상이 필요했습니다. 저렇게 10레벨대 초반에나 약 2레벨 정도의 활력 상태 보너스를 제공하고 이후에는 1레벨 정도로 빠듯하게 주어지게 됩니다.

여기서 한가지 더 함정이 있습니다.

6. 활력 상태는 일정량을 소비하지 않으면 회복되지 않는다.

- 정확하게 얼만큼인지는 확인해보지 못했습니다만, 활력 상태에서 일정량의 활력을 사용하지 않는다면 활력이 회복되는 일이 없습니다. 적어도 50% 이상은 소모해야 하는 것 같았습니다. 그렇지 않을 경우 플레이어의 활력 최대치는 항상 제자리에 있게 되며 활력 회복 지역이나 로그아웃 같은 행동이 무의미해집니다. 활력 회복 지역에 들어서면 '이 구역에서는 활력이 회복됩니다' 라고 나오는데 모두 뻥이 되는 샘이지요. 그래서 플레이어의 캐릭터는 더 이상 성장을 할 수 없게 됩니다.

7. 활력은 항상 정확하게 계산된다.

- 드네 게임에서는 피로도가 일단 남아만 있다면, 요구하는 피로도가 얼마든 상관없이 스테이지에 입장 가능합니다. 그러니까 10밖에 없어도 200짜리 스테이지에 입장하는게 가능합니다. 근데 이 활력은 다음 활력 구간까지 10 남았는데 내가 지금 받는 경험치가 100이라면, 얄짤없이 남은 양은 다음 활력 구간에 맞게 결정됩니다. 만약 피로 구간에 걸쳐있다면 경험치를 10%만 챙겨가는 사태도 벌어집니다. (그럼에도 불구하고 UI 적으로는 그냥 현재 구간에 맞게 출력되어, 그렇게 손해볼 수 있다는 사실을 모르게 됩니다)

문제점은 바로 피로 구간입니다. 경험치를 10%만 챙겨가게 되는데, 사실상 얻는 경험치가 1 정도에 불과해서 더이상의 사냥이나 퀘스트 진행은 불가능하게 됩니다. 무엇보다 퀘스트 경험치까지 빼앗아 간다는 것은 실로 엄청난 패널티가 아닐 수 없습니다.

어디서 본 것인지 도저히 생각이 안나는데 (혹시 아시는 분은 첨언 부탁) 본래 WOW의 휴식경험치는 휴식 상태 100%, 보통 상태 50% 로 했더니 게임 플레이 시간이 줄어들길래 휴식 상태 200%, 일반 상태 100%로 바꿔서 긍정적인 보너스로 바꿨더니 잘 되었더라- 하는 포스트모템을 본 기억은 있는데 도저히 그 출처를 찾을 수가 없습니다 ㅠㅠ (
http://www.slideshare.net/epiphany/blizzard-design-processkor-for-web-v10 avici 님의 제보입니다 감사합니다) 근데 이런 휴식경험치 개념을 관련된 사람들이 몰랐을리가 없거든요. 블&소 PD님도 와우 즐겨하시는 걸로 알고있고요.

정말 이해가 안가는건 '왜 이렇게까지 해야 했느냐' 하는 점입니다. 굳이 10%로 깎아 가면서까지 플레이를 막아야 했을 정도로 컨텐츠 소모가 두려웠는지 거기에 더해 '더 자세한 정보를 알고 싶으면 NC에 입사해라' 라는 GM의 운영 미숙에 이후 220% 150% 패치와 더불어 활력 시스템의 수많은 건의에도 불구하고 일언반구도 없었던 소통의 부재까지 여러모로 다 된 밥에 스스로 재를 뿌리는 상황을 연출하고 말았습니다. 이 게임이 2차 CBT때까지는 극찬을 받았고 심지어는 '모든 게임이 까이는 그 곳'에서도 쉴드를 받았던 게임이라는 것을 상기하면 정말로 안타깝기 그지 없습니다.

활력 시스템의 기획 의도는 무엇일까요? 제가 기획자가 아니니 추측을 해보자면

- 레벨링을 늦춰서 유저간 레벨 격차 축소

- 레벨링 이외의 컨텐츠 (제작, PVP, 아이템 파밍 등) 사용 유도 

정도가 아닐까 생각 해봅니다. 애피타이징 2주, 3차 클베 2주로 어느정도 데이터도 얻었을테고 중간의 220% 150% 패치도 뭔가 의도가 있었겠지요. 그런데 어제 클베 종료와 동시에 사업 총괄을 맡고 계신 전무님이 활력 시스템은 삭제하고 고객님들 말씀도 경청하고 있다는 공지를 올림으로서 활력 시스템은 개선의 여지 없이 사라질 운명에 처하게 되었습니다. 

그래서 결론 : 아무리 의도가 좋아도 고갱님고객님을 이기려고 해서는 안된다. 싸움을 걸어서는 안된다.

접기

아무튼 게임은 참 재밌게 했습니다.

참 좋은 게임 같습니다

이전다음

0123456

접기

저를 포함한 대부분의 개발자들은 버그를 만듭니다.
인재들이 모였다는 MS의 IE 베타버전이 얼마나 엉망인지 아시죠? QA와 오류 보고 시스템 등을 통한 검수가 정식 버전을 안정성있게 만드는 것이지 MS가 만든 제품도 버그가 많습니다.
그 들이 극찬하는 IOS나 OSX요? 네 그렇게 신중한 애플도 버그를 만듭니다.
특히나 많은 버그가 개발 과정에서 더더욱 많이 튀어나오는데, 이들 대부분이 개발자의 습관에서 비롯됩니다.

흔 히 많이 하는 실수가 초기화 오류(변수값의 초기화 값이 없다거나, 변수가 초기화 되는 시점이 잘못된 경우)라던가, 경계값 오류(임계치에 가까운 값을 잘못 설정한 오류), 연속 시도시 잘못된 결과가 도출되는 오류 (예를들면 결제 버튼 여러번 누르면 돈은 여러번 감소하고 아이템은 지급안된다던가하는 오류), 버그 수정시 다른 버그를 만들어 내는 문제 등이 있습니다.

생각보다 같은 종류의 실수를 자주 하는 사람이 많은데, 모 QA팀에서는 버그 스타일에 따라 담당자를 배정하는 사례도 있었다고 할 정도죠.
물론 어쩌다가 한번 나오는 버그는 개발자의 실수로 모두가 좋게 넘어가지만 같은 종류의 버그가 여러번 나오고, 제대로 된 수정이 이루어지지 않는다면 여러가지 측면에서 문제가 생깁니다.

QA팀에 없는 경우에는 개발팀 테스트 후 바로 서비스가 될 테니 더 말 할것 없고, QA팀이 있는 경우라해도 개발 과정의 버그도 줄여야 합니다.
반드시 그렇게 해야 하는 근거는 다음과 같습니다.

이런 문제는 정상적인 개발자라면 대부분 2~3년차 때는 고치게 되는 편입니다. (안타깝게 비정상적인 개발자가 꽤 많죠...ㅠ_ㅠ 누구라고는 얘기 안하겠습니다.)

여하튼 개인의 습관에서 나오는 문제를 고쳐야 되는 이유에 대해 이야기 해봤습니다.
자 이제, 팀 차원에서의 버그 재발을 막기 위한 노력에 대해서 예를 들어 이야기 해보겠습니다.

노파심에서 말씀드리자면 이 이야기는 절대 신입을 뽑지 말자는 의미가 아닙니다.
상황이 이렇게 된데에는 잘 흘러가는 것처럼 보이던 S프로젝트 팀에 잠재적 문제가 있었습니다.


과연 이 팀의 문제가 무엇이었을까요?

실제로 이 팀에 내재된 문제는 더 있을 겁니다.
이런 상황을 만들었다는 것 자체가, 개발자 개개인의 역량에 지나치게 의존한다는 증거라고 볼 수 있기 때문입니다.

게다가 업무에 대한 교류와 검토가 이루어지지 않다보니, 베테랑 개발자 A라 할지라도 순간 정줄을 놓는 순간 버그를 양산할 여지가 다분합니다.
문제는 버그가 양산된다해도 우리의 희망 QA팀에서 대부분 잡아주시겠지만 개발 규약이라던지, 로그가 적절하게 취합되고 있는지, 예외 상황은 얼마나 잘 처리되었는지 등에 대한 검토마저 개개인의 역량에 맡기고 있다는 사실입니다.

요 새 PC가 워낙에 빠르다지만 클라이언트는 유저에게 배포되기 때문에, 서버는 많은 유저를 수용하고 그들의 요청을 처리해야 되기 때문에 속도도 중요한데, 검수가 없다는 것은 이 코드가 정상 상황에서 잘 돌아가기만 하면 된다고 여기고 있다는 얘기가 되는 겁니다.

이렇듯 꽤나많은 문제를 갖고 있는 이 팀이 문제들을 해결하기 위해선 몇가지 노력이 필요합니다.

이렇게 갖춰놓는다면 아무리 사고뭉치라해도 개발 과정에서 대다수를 캐치 할 수 있습니다.

자 이렇게 좋은 개발팀이 버그를 많이 만들지 않도록 구축해야 할 것들에 대해 이야기해보았습니다.
어느정도 디버깅에 대한 이야기를 마무리 한거 같네요. 아쉬운 부분이 좀 있지만, 디버깅에 대해 좀 더 진지하게 다시 할 얘기가 생겼을 때 연재하도록 하겠습니다.

다음 시간에는 디버깅 주제가 아닌 게임 개발 이야기로 찾아올게요~ 감사합니다 ^^

요즘 디아블로 3를 즐기고 있는데 로그인 에러 때문에 빡치더군요. 돈 주고 게임을 샀는데 할 수가 없어요. 그러다 로그인 과정에 일정한 패턴도 있겠다. 한번 자동으로 만들어보자 해서 만들어보게 되었습니다. ( 이렇게 프로그래밍 스킬을 써먹는 것 이지요. )

열어줘!! 열어달라고!!!

일단 크게 3 부분이 필요하다는 것을 정리했습니다.

1. 전역 키 후킹

매크로 프로그램 같은 경우 게임의 배경에서 돌아가야 합니다. 포커스가 디아블로에 있다 하더라도 자동 로그인 프로그램이 on/off 될수 있도록 전역적인 키 후킹이 필요합니다. ( 예. F1로 자동 로그인 켜기, F2로 자동 로그인 끄기 )

2. 패턴화된 작업을 자동화

보통 로그인이 과정이 아이디는 입력해놓으면 고정되고, 패스워드 입력 -> 접속 버튼 클릭 -> (에러난 경우 ) 에러창 출력 -> 에러창 닫기 -> 패스워드 입력 -> ... 대략 이렇습니다. 이 과정만 자동화 해놓으면 되죠.

3. 화면 해상도

클릭 해야 될 부분이 해상도 마다 다릅니다. 모든 사람이 1920 * 1080 해상도를 쓰는 것이 아니므로, 클릭 좌표를 비율로 관리해야 했습니다. 일단 제가 사용하는 1680 * 1050 해상도를 기준으로 좌표를 클릭해야 할 좌표들을 얻은 다음 비율을 통해 대부분의 해상도에서 ( 와이드 기준 ) 작동 하도록 하였습니다.

일단 작업 해야될 부분을 정리 했고, 이제 실제로 만들어 보도록 하죠.

먼저 전역 키 후킹 클래스를 만들어봅니다. 구글링을 해보니 이미 CodeProject에 좋은 샘플이 있더군요. 이것을 기반으로 작업해보겠습니다. ( 출처 : http://www.codeproject.com/Articles/19004/A-Simple-C-Global-Low-Level-Keyboard-Hook )

// 후킹에 필요한 Win32API를 임포트
[DllImport("user32.dll")]
static extern IntPtr SetWindowsHookEx(int idHook, keyboardHookProc callback, IntPtr hInstance, uint threadId);
[DllImport("user32.dll")]
static extern bool UnhookWindowsHookEx(IntPtr hInstance);
[DllImport("user32.dll")]
static extern int CallNextHookEx(IntPtr idHook, int nCode, int wParam, ref keyboardHookStruct lParam);
[DllImport("kernel32.dll")]
static extern IntPtr LoadLibrary(string lpFileName);

// 후킹 프로시저 함수와 후킹 데이타 구조체 정의
delegate int keyboardHookProc(int code, int wParam, ref keyboardHookStruct lParam);
keyboardHookProc mkeyboardHookProc;
struct keyboardHookStruct
{
	public int vkCode;
	public int scanCode;
	public int flags;
	public int time;
	public int dwExtraInfo;
}

// 후킹 후 불려질 콜백 함수 정의
public delegate bool CustomKeyEventHandler(Key k);
public event CustomKeyEventHandler CustomKeyDown;
public event CustomKeyEventHandler CustomKeyUp;

// 후킹 시작
const int WH_KEYBOARD_LL = 13;
public void hook() 
{
	IntPtr hInstance = LoadLibrary("User32");
 	mkeyboardHookProc = hookProc;
 	hhook = SetWindowsHookEx(WH_KEYBOARD_LL, mkeyboardHookProc, hInstance, 0);
}

// 후킹 끝
public void unhook() 
{
	UnhookWindowsHookEx(hhook);
}

// 후킹 프로시저
public int hookProc(int code, int wParam, ref keyboardHookStruct lParam)
{
	if (code >= 0) 
    {
		Key key = KeyInterop.KeyFromVirtualKey(lParam.vkCode);      
        
        // 등록된 키가 눌러졌으면 
		if (HookedKeys.Contains(key)) 
        {
            bool bHandled = false;
			if ((wParam == WM_KEYDOWN || wParam == WM_SYSKEYDOWN) && CustomKeyDown != null)
            {
                bHandled = CustomKeyDown(key);
			}
            else if ((wParam == WM_KEYUP || wParam == WM_SYSKEYUP) && CustomKeyUp != null)
            {
                bHandled = CustomKeyUp(key);
			}
            if (bHandled)
				return 1;
		}
	}
	return CallNextHookEx(hhook, code, wParam, ref lParam);
}

코드는 상당히 간단합니다. HookedKeys에 후킹 하고 싶은 키과 불려질 함수를 등록 해두고, 해당 키가 입력 되었을때 등록된 함수가 호출 되는 방식입니다. (KeyDown, KeyUp을 구분 해둠)

실제 사용하는 부분입니다.

// F1과 F2키를 후킹 하도록 한다.
// 위의 키가 눌리면 CustomKeyUpEvent가 호출
mGlobalHooker = new GlobalHooker();
mGlobalHooker.HookedKeys.Add(Key.F1);
mGlobalHooker.HookedKeys.Add(Key.F2);
mGlobalHooker.CustomKeyUp += new CustomKeyEventHandler(CustomKeyUpEvent);

이제 키 후킹은 되었으니 자동 로그인 부분을 만들어 보죠. 제가 생각하는 구조는 필요한 암호를 입력 받아놓고, 패스워드 필드에 패스워드 입력 후 ( 붙여넣기 ) 접속 버튼을 클릭. 그 다음 에러 창이 뜨고, 에러창 닫기를 클릭. 다시 패스워드 필드를 클릭 하고 ( 가끔 포커스가 아이디 필드로 날아가니 ) 다시 패스워드 입력 후... 이후 반복 작업입니다.

대략 4가지 일을 해야 합니다. 이 모든 일이 한번에 일어나면 이벤트 동작이 제대로 안됩니다. 이전 이벤트가 씹히기도 하죠. 그래서 각 이벤트를 일정 딜레이를 주고, 발생하도록 합니다. 일단 그전에 클릭 해야될 좌표를 구해야 합니다. 제가 1680 * 1050 해상도를 사용하는데, 이 해상도를 기준으로 클릭 좌표를 화면 해상도 비율로 구해놓았습니다. 그렇기 때문에 해상도가 변해도 클릭해야 될 곳을 정확히 클릭하도록 했습니다.

// 마우스와 키 입력 이벤트를 생성하기 위한 Win32Api 불러오기
[DllImport("user32.dll")]
static extern void keybd_event(byte vk, byte scan, int flags, int extrainfo);
[DllImport("user32.dll")]
static extern void mouse_event(uint dwFlags, uint dx, uint dy, uint dwData, int dwExtraInfo);
[DllImport("USER32.dll", CallingConvention = CallingConvention.StdCall)]
static extern void SetCursorPos(uint X, uint Y);

// 현재 화면 해상도(게임 해상도)를 비율로 구함
// 이 작업은 자동 로그인이 시작 될때 실행 됨
mScreenWidthRatio = 1.0 / 1680 * SystemParameters.PrimaryScreenWidth;
mScreenHeightRatio = 1.0 / 1050 * SystemParameters.PrimaryScreenHeight;

// 작업 이벤트를 순차적으로 등록
mEvents = new ArrayList();
mEvents.Add(new LoginEventHandler(LoginEvent1));
mEvents.Add(new LoginEventHandler(LoginEvent2));
mEvents.Add(new LoginEventHandler(LoginEvent3));
mEvents.Add(new LoginEventHandler(LoginEvent4));

// 이벤트 1 - 패스워드 필드 클릭
void LoginEvent1()
{
    double CursorX = mScreenWidthRatio * 835;
    double CursorY = mScreenHeightRatio * 686;

    SetCursorPos((uint)CursorX, (uint)CursorY);
    mouse_event(LBUTTONDOWN | LBUTTONUP, (uint)CursorX, (uint)CursorY, 0, 0);
}

// 이벤트 2 - 패스워드 붙여넣기
void LoginEvent2()
{
    keybd_event(CTRLKEY, 0, 0, 0);
    keybd_event(VKEY, 0, 0, 0);
    keybd_event(CTRLKEY, 0, KEYEVENT_UP, 0);
}

// 이벤트 3 - 접속 버튼 클릭
void LoginEvent3()
{
    double CursorX = mScreenWidthRatio * 835;
    double CursorY = mScreenHeightRatio * 835;

    SetCursorPos((uint)CursorX, (uint)CursorY);
    mouse_event(LBUTTONDOWN | LBUTTONUP, (uint)CursorX, (uint)CursorY, 0, 0);
}

// 이벤트 4 - 에러37 확인 버튼 누르기
void LoginEvent4()
{
    double CursorX = mScreenWidthRatio * 835;
    double CursorY = mScreenHeightRatio * 615;

    SetCursorPos((uint)CursorX, (uint)CursorY);
    mouse_event(LBUTTONDOWN | LBUTTONUP, (uint)CursorX, (uint)CursorY, 0, 0);
}

각 이벤트들을 배열리스트에 담아두고 지정된 딜레이 시간마다 순차적으로 호출 되게 합니다. 여기서는 F1키가 입력되면 작업을 실행도록 합니다.

// 타이머를 생성
TimerClock = new DispatcherTimer();
TimerClock.Tick += new EventHandler(Timer_Tick);

// 등록된 키가 눌리면 불려지는 함수
bool CustomKeyUpEvent(Key k)
{
    switch (k)
    {
        case Key.F1:
            {
                if (!TimerClock.IsEnabled)
                {
                    // 해상도 비율로 사용 가능하게 비율을 구함
                    mScreenWidthRatio = 1.0 / 1680 * SystemParameters.PrimaryScreenWidth;
                    mScreenHeightRatio = 1.0 / 1050 * SystemParameters.PrimaryScreenHeight;

                    // 실행될 프로시저 인덱스
                    mCurrEventIDX = 0;
                            
                    // 입력된 딜레이 값을 지정
                    // 입력된 패스워드를 클립보드에 복사
                    miDelayTime = Convert.ToInt32(textBox1.Text);
                    Clipboard.SetData(DataFormats.Text, textBox2.Text);

                    // 타이머 실행
                    TimerClock.Interval = new TimeSpan(0, 0, 0, 0, miDelayTime);
                    TimerClock.Start();
                }
                else
                {
                    TimerClock.Stop();
                }
            }
            return true;

        // F2키는 종료. 종료 되기전에 클립보드를 비운다.
        case Key.F2:
            {
                Clipboard.SetData(DataFormats.Text, "");
                Application.Current.Shutdown();
            }
            return true;
        default: return false;
    }
}

// 타이머에 의해서 호출된다
// 호출될때마다 순차적으로 등록된 이벤트 함수를 호출한다
void Timer_Tick(object sender, EventArgs e)
{
    if (0 == mEvents.Count)
        return;

    if (mCurrEventIDX >= mEvents.Count)
        mCurrEventIDX = 0;

    (mEvents[mCurrEventIDX] as LoginEventHandler)();
    ++mCurrEventIDX;
}

대략 이걸로 기본적인 동작은 하게 됩니다. 이렇게 만들어진 결과물~ 쨔란~ 알고 보면 별거 아님.

Diablo3AutoLoginV2.zip

인증 중인 창을 닫는 부분을 수정했습니다.