새로운 게임을 개발할 때 고려해야 할 가장 큰 함정은 무엇입니까?

실제로 몇 주 전에 Facebook에 대한 몇 가지 새로운 웹 기반 게임을 추적하기 시작했습니다 (명칭 수정에 David David에게 감사드립니다). 턴 기반 (뱀파이어 워즈) 스타일 RPG와 비슷한 작업을하고 있습니다. 게임을 코딩하는 기술이 있지만 디자인 패턴을 올바르게 파악하고 제품이 내 눈에 보이는 것과 일치하도록 노력하고 있습니다.

일반적으로 웹 사이트를 만들 때 '코드를 생각하고 싶습니다.'코드 / HTML을 변경하여 코드를 변경하는 것이 더 빠릅니다. 아마도 내가하는 일에 매우 편안하고 무엇을 기대해야하는지 알고 있기 때문일 것입니다 반복해서 반복했습니다. 게임 개발이 시작되는 시점에서 나는 웹 사이트에서 익숙했던 것처럼 종이로 다시 시작한다는 것을 알았습니다. 이것이 게임 로직에 대한 초점과 직관이 부족하거나 이것이 내 생각을 롤아웃하기에 적절한 방법인지 궁금합니다. 코딩의 발전.

이 문제를 올바르게 공격하고 업무를 수행하는 방법에 대한 조언을 부탁드립니다. 표준 비즈니스 웹 사이트와 게임 엔진이 얼마나 다른지 빠르게 배우고 있습니다! 무언가를 제자리에 넣을 때마다 매끄럽고 불완전한 느낌이 들며 좌절감을 느끼게됩니다.

펼친

예를 들어, 나에게 많은 문제를 안겨준 배틀 엔진은 최근 간단한 공격 기술을 취한 다음 -50 %와 + 50 % 사이에서 임의의 롤을 한 다음 원래 공격 기술을 그 백분율에 곱합니다. 같은 방법으로 방어를 한 다음 적의 체력에 피해를 입히는지를 결정하기 위해 그것들을 맞 춥니 다. 나는 그것이 올바른 방법인지 또는 '올바른'방법이 있는지 스스로에게 물어보기 시작할 때 내 머리 위에 있다는 것을 깨달아야한다고 생각합니다. 내가 찾은 주요 결함 중 하나는 같은 레벨에서 두 명의 캐릭터가 공격이 -50 %이고 방어가 + 50 % 인 여러 개의 '롤'을 가질 수 있다는 것입니다. 불합격

어쩌면 내 게시물에 간단한 게임 논리를 설명하는 제안 된 링크가 필요했을 것입니다.

엔드 익스텐션

미리 감사합니다!

너무 많은 기능을 추가합니다. 게임의 핵심에 집중하고 빌드 한 다음 모든 것이 잘 작동하면 기능을 추가하십시오. 사람들은 멋진 것을 추가하는 데 너무 집중하고 아무것도하지 않습니다.

게임 프로토 타입을 만드는 방법에 대한 훌륭한 기사입니다. 귀하의 질문에서 프로토 타입이 무엇인지에 대한 아이디어가 빠져있는 것 같습니다.

프로토 타이핑 : 당신은 (아마) 잘못하고 있습니다

추천 광고:

실수 # 4 : 게임
이 아닌 시스템 구축 프로토 타입을 제작할 때 직접 진행하지 않는 작업을하고있는 경우에는 바로 중지하십시오. 프로그래머로서 우리는 코드를 일반화하고 우아하게 만들고 모든 상황을 처리 할 수있는 경향이 있습니다. 우리는 가려움증이 긁히지 않는 것을 발견했지만, 방법을 알아야합니다. 코드가 아니라 결국에 제공하는 게임에 관한 것임을 깨닫는 데 몇 년이 걸렸습니다.

우아한 게임 구성 요소 시스템을 작성하지 말고 편집기를 완전히 건너 뛰고 코드로 상태를 고정 시키십시오. 데이터 중심의 자체 구문 분석, XML 크래시를 피하고 손상된 것을 코딩하십시오.

편집하다:

프로토 타입과 트레이서 코드의 차이점을 명확히하기 위해 이것을 추가하고 있습니다.

항상 기억하십시오 : 프로토 타입은 버려 지도록 설계되었습니다! 추적 프로그램 코드가 아닙니다.

프로토 타입 함정

... 추적자 코드 접근 방식은 다른 문제를 해결합니다. 응용 프로그램 전체가 어떻게 연결되는지 알아야합니다. 사용자에게 상호 작용이 실제로 작동하는 방식을 보여주고 개발자에게 코드를 걸 수있는 구조적 골격을 제공하려고합니다. 이 경우 컨테이너 패킹 알고리즘 (선착순, 선착순 등)의 단순 구현과 단순하지만 작동하는 사용자 인터페이스로 구성된 추적 프로그램을 구성 할 수 있습니다. 응용 프로그램의 모든 구성 요소가 함께 연결되면 사용자와 개발자를 보여주는 프레임 워크가 만들어집니다. 시간이 지남에 따라 새로운 기능으로이 프레임 워크에 추가하여 스텁 된 루틴을 완료합니다. 그러나 프레임 워크는 그대로 유지되며 첫 번째 추적 프로그램 코드가 완료 될 때와 마찬가지로 시스템이 계속 작동한다는 것을 알고 있습니다.

구별은 반복을 보증하기에 충분히 중요합니다. 프로토 타이핑은 일회용 코드를 생성합니다. 추적 프로그램 코드는 간결하지만 완전하며 최종 시스템의 골격을 구성합니다. 프로토 타입을 하나의 추적 총알이 발사되기 전에 이루어지는 정찰 및 정보 수집으로 생각하십시오.

Pragmatic Programmer 의 Tracer Code 디자인에 대한 추가 정보

추적 프로그램 글 머리 기호 및 프로토 타입

함정 : 데이터에서 논리를 분리하지 않습니다. 데이터가 원하는 결과를 생성하는지 테스트하지 않습니다.

Joe의 게시물에 대한 귀하의 의견에서 :

괴물과의 만남을 위해 전투 엔진을 코딩하길 원해요, 붐! 나는 이번 주에 적어도 세 번 내 엔진을 다시 작성했으며 결코 기분이 좋지 않습니다. 내 말은, 수학은 효과가 있지만, 그것을 시도 할 때 그것은 기분이 좋지 않습니다. 말이 돼?

여기에 데이터와 엔진을 혼동시키는 것처럼 들립니다. 몬스터 만남 엔진은 데이터로 구동되어야합니다. 게임 밸런스 / 재미에 영향을 미치는 데이터가 잘못된 경우 엔진을 완전히 다시 작성할 필요가 없습니다. 밸런스 변수가 제대로 느껴질 때까지 조정하면됩니다.

그러나 균형 변수는 때때로 상호 의존적이므로 하나의 변수를 더 나은 시나리오로 변경하면 다른 시나리오에 막대한 영향을 줄 수 있습니다.

새로 조정 된 데이터가 다른 여러 사례를 망쳐 놓지 않았 음을 테스트하려면 몇 가지 테스트 사례를 유지하고 조정 후에도 문제가 해결되지 않는 것이 좋습니다. 다음은 이것을 테스트하는 방법에 대한 인정 된 예입니다.

TestResult TestPlayerKillsMonsterDuringAttack(PlayerStats, MonsterStats, seed)
{
   Player player(PlayerStats);
   Monster monster(MonsterStats);


EncounterEngine.SeedRNG(seed);

   while(1)
   {
     result = EncounterEngine.Attack(player, monster);
     if (result == PLAYER_DEAD)
       return TEST_FAIL;
     if (result == MONSTER_DEAD)
       return TEST_PASS;
     // result == MONSTER_DAMAGED, PLAYER_DAMAGED is expected. 
   }
}

예 : PlayerStats.Level == 5 및 MonsterStats.Level == 3으로 이것을 호출하면 플레이어는 항상이 몬스터를 물리 칠 것입니다.

여기서 볼 수있는 한 가지 함정은 프로그래밍과 게임 디자인이 실제로 별도의 작업 일 때 동일한 작업으로 취급한다는 것입니다. 제안한 바와 같이 이것은 프로그래밍이나 알고리즘 문제가 아니며 (원하는 방식으로 전투 시스템을 코딩 할 수 있음) 플레이어에게 재미 있고 흥미로운 부분에 관한 것입니다.

답은 게임 디자인과 게임 밸런스에 관한 자료를 찾아 보는 것입니다. 실제로 4 년 동안의 전공 프로그램을 여러분이 모으고있는 주제에 전념하는 대학이 있기 때문에, 여러분에게 신속하고 더러운 답변을하는 것은 불가능합니다 (누군가 " 그래, 나는이 게임에 대한 아이디어를 얻었지만 그것을 어떻게 프로그래밍해야할지 모르겠다. 무엇을주의해야합니까? "). 게임 디자인에 관한 책, 코스 및 온라인 글이 있습니다. 그들을 찾아보십시오.

게임을 작성할 때 가장 큰 함정은 기분이 좋은 코드를 작성하는 대신 올바른 디자인 패턴을 사용하는지 여부를 걱정하는 것입니다.

시간 관리와 자기 동기 부여에 관한 Steve Pavlina 의 기사를 추천합니다 : http://stevepavlina.narod.ru/

그는 프로그래머이기도하다. 그의 라이프 스타일 실험은 일부 주요 미디어 관심을 불러 일으켰습니다.