게임 클라이언트
는 플레이어가 실제로 만지는 유일한 부분입니다.
게임 엔진은 명성이 아니라 게임이 돌아갈 곳으로 골라요. 웹은 Babylon.js, 앱은 Unity·Flutter Flame, 데스크톱은 Unity·Unreal 을 비교해 보세요.
무엇을 만들 것인가가 무엇을 고를지를 정합니다
세 가지를 순서대로 물으세요. 플레이어는 이것을 어디서 받는가 — 링크인가, 인가, 데스크톱 상점인가? 2D 인가 인가? 그리고 나는 이미 어떤 언어를 편하게 쓰는가? 이 세 답이면 대개 합리적인 선택지가 정확히 하나 남고, 그다음부터는 취향 논쟁입니다.
첫 라면 웹이 사람들이 생각하는 것보다 자주 이깁니다. 설치할 것도 없고, 심사받을 것도 없고, 한 시간 안에 친구에게 링크를 보낼 수 있습니다.
게임은 1초에 수십 번 같은 세 가지 일을 되풀이합니다
블록이 떨어지는 퍼즐이든 레이싱이든, 모든 게임은 위에서 돕니다. 클라이언트는 1초에도 여러 번 같은 일을 되풀이합니다. 플레이어가 무엇을 눌렀는지 읽고, 세계를 바꾸고(캐릭터를 옮기고, 맞았는지 보고, 점수를 더하고), 화면에 새 그림을 그립니다. 루프를 한 바퀴 돌 때마다 이 하나 나옵니다. 60 라면 한 바퀴를 약 16 안에 끝내야 해서, 느린 는 화면 끊김으로 드러납니다.
- 1 입력 읽기 어떤 키를 누르고 있는지, 손가락이 어디를 눌렀는지, 게임패드의 어느 버튼을 눌렀는지 읽습니다. 여기서는 읽기만 하고 아직 아무것도 옮기지 않습니다.
- 2 세계 갱신 캐릭터를 속도 × 지난 시간만큼 옮기고, 중력을 더하고, 충돌을 확인하고, 점수와 타이머를 바꿉니다. 게임의 규칙은 바로 여기에 삽니다.
- 3 그림 그리기 화면을 지우고 배경··점수를 새 자리에 그립니다. 플레이어가 보는 것은 이 단계뿐이니, 게임 규칙은 여기에 넣지 마세요.
화면에서 움직이는 그림 — 캐릭터, 동전, 총알 — 을 스프라이트라고 부릅니다. 두 스프라이트는 보이지 않는 상자(히트박스)가 겹칠 때 닿은 것이고, 이것을 프레임마다 확인하는 일을 이라고 합니다. ·· 같은 엔진은 루프를 대신 돌려 주고, 여러분은 갱신에서 무슨 일이 일어나는지와 무엇을 그릴지만 채우면 됩니다.
x += speed * dt. 그러면 어느 기기에서나 같은 속도로 움직입니다.
루프의 어느 부분을 말하는지 에게 알려 주세요. 예: "갱신에서 플레이어를 화살표 키로 초당 200픽셀씩 델타 타임을 써서 움직이고, 벽에서 멈추게 해 줘. 그리기에서는 점수를 왼쪽 위에 보여 줘." 단계를 짚어 말하면 더 작고 확인하기 쉬운 코드가 나옵니다.
웹
링크는 게임과 플레이어 사이의 가장 짧은 거리입니다. 설치도 도 없고, 가 있는 모든 기기에서 돕니다.
앱
··를 얻는 대신, 대기와 규칙을 감수합니다.
데스크톱
더 큰 화면, 제대로 된 입력 장치, 그리고 . 오래 붙잡고 하는 게임이 사는 곳입니다.
사람들이 자주 틀리는 두 가지
·Unity·Unreal·Flame 은 알아 둘 가치가 있는 것으로 여기 나올 뿐, SONUB 이 채택한 기술이 아닙니다.