게임 디자인
게임을 디자인할 때 저희의 주된 목표는 프로그래머들을 위한 재미있는 엔터테인먼트를 준비하는 동시에 회사 업무의 일부로서 재미있는 일을 하는 것이었습니다. 지금까지는 게임 제작에 대한 역량이 전혀 없었기 때문에 큰 도전으로 다가왔습니다. 우선 저희는 이 게임이 정말 무엇인지에 집중했습니다. 초기 계획을 세우고 나서는 본격적으로 개발에 착수했습니다.
게임 작업의 일환으로 해커톤을 진행하기로 결정하고 특정 작업을 수행하는 그룹으로 나눴습니다. 8시간의 작업 분담으로 게임 속 적의 모습, 전체 레이아웃, 전체 시스템의 작업과 API의 기초를 모두 구현할 수 있었습니다. 다음 단계에서는 한 달에 한 번 4시간씩 모여 회의를 진행했고, 그 덕분에 3번의 회의로 게임을 완성할 수 있었습니다.
구현
루비온레일을 전문으로 하는 저희는 이 기술을 선도적인 기술로 선택했습니다. 그러나 이 게임은 텍스트로 된 게임이 아니었기 때문에 접근 방식은 SPA 유형 애플리케이션에 반영되었습니다. 작업의 일환으로 우리는 잘 알려진 레일의 에셋 파이프라인(2016년에는 원칙적으로 이보다 더 좋은 것은 없었습니다)과 전체 자바스크립트 당사의 독점적인 코드 TypeScript의 도움으로. 애플리케이션에는 표준 책임 분담이 있었습니다: 에셋 및 API 소스로서의 레일, 사용자와의 상호 작용으로 관련된 자바스크립트. 그러나 여기서는 하이브리드 방식으로 작동했으며 일부 뷰는 단순히 레일에서 렌더링되고 다른 일부는 JS에서 렌더링되었습니다.
타입스크립트
이 분야에서의 첫 실험이었습니다. 사람들이 커피스크립트의 성공을 믿었던 시기였습니다. TypeScript를 사용하려면 타입스크립트 레일이라는 보석을 도입해야 했습니다. 안타깝게도 정적으로 입력되는 언어인 타입스크립트는 기본적으로 레일에 첨부된 라이브러리에서도 이를 필요로 했기 때문에 이것이 마지막이 아니었습니다.
https://github.com/codesthq/cody_the_game/blob/master/app/assets/javascripts/jquery.d.ts (특히 레일과 함께 임베디드 자산 관리 시스템을 사용하는 경우).
게임으로서의 코디는 브라우저 측에서 많은 동적 요소와 DOM 트리의 수정이 필요했습니다. 바닐라 자바스크립트 대신 TypeScript를 사용함으로써 코드 품질이 크게 향상되었고, 클래스와 캡슐화의 존재 자체가 저희에게는 매우 매력적이었습니다.
API 및 SPA
2019년, SPA 애플리케이션은 웅장한 React 또는 Vue 라이브러리. 하지만 2015년에는 다른 방식으로 구현했습니다. 앞서 언급한 타입스크립트는 게임 구현에 도움이 되었지만, jQuery는 xml http 요청과 관련된 모든 작업을 취소했습니다. 그 당시에는 `$ .ajax`가 작업에 필요한 모든 것이었지만, 지금은 fetch를 사용할 수 있습니다. 클라이언트 API를 살펴보세요!
API라면 어떻게든 인증 문제를 해결해야 하지 않았나요? 네, 맞습니다. 하지만 이 경우에는 밴드를 사용했고(여기에 쓸 수 있을까요?!) 레일즈 세션에서 쿠키 키를 생성한 후 데이터베이스에 저장했습니다. 따라서 우리는 모든 것이 괜찮다는 것을 알았습니다.
https://github.com/codesthq/cody_the_game/search?q=cookie_key&unscoped_q=cookie_key
게임 상태는 데이터베이스에 저장되었고, 얼마나 많은 사용자가 포인트를 가지고 있는지에 대한 정보는 데이터베이스에서 나왔습니다(같은 데이터베이스인가요? 대명사로 바꿀 수 있나요?). 시스템 측에 캐싱이 없을 때 ACID는 항상 유용합니다.)
스파의 경우 페이지를 다시 로드하지 않고 가장 좋습니다. 우리는 고전적으로 해결했으며 불필요한 종속성을 확장하지 않고 HTML 앵커가 가장 좋은 솔루션이었습니다. 누가 터보링크를 사용하겠습니까?
SnapSVG
게임을 디자인하면 멋진 그래픽과 애니메이션이 있어야만 출시할 수 있습니다. 당시에는 애플리케이션에서 이러한 요구 사항을 충족하는 방법을 고민하는 데 많은 시간을 보냈습니다. 한편으로는 캔버스가 기적을 일으킬 수 있고, 다른 한편으로는 깔끔한 HTML이 훨씬 더 따라잡기 쉽고 모두가 알고 있습니다. 최상의 솔루션을 찾기 위해 고심 끝에 이 두 가지 솔루션의 조합이 SVG라는 것을 알아냈습니다. 벡터로 그래픽을 쉽게 표현할 수 있고 마크업 언어로 작성되며 가장 중요한 것은 즉석에서 수정할 수 있다는 것입니다. 중요한 것은 jQuery와 유사하게 작동하고 통합된 방식으로 이미지를 작업할 수 있는 svg 파일용 라이브러리가 있다는 것입니다. 이것은: http://snapsvg.io, 우리는 그 특정 솔루션 사용에 대한 아주 좋은 기억을 가지고 있습니다.
스냅.svg를 사용한 예는 아래에서 확인할 수 있습니다:
https://github.com/codesthq/cody_the_game/blob/master/app/assets/javascripts/intro.js.ts
그래픽 스켈레톤이 있는 햄 파일 자체입니다:
https://github.com/codesthq/cody_the_game/blob/master/app/views/game/show.html.haml
보시다시피 일반 DOM 트리와 일반 레일즈 앱과 거의 비슷합니다!
트러스티드샌드박스
드디어 API, 그래픽, SPA가 생겼습니다. 하지만 사용자가 보낸 솔루션을 구현하는 것은 어떨까요?
가장 먼저 떠오르는 것은 평가 방법이지만, 저희는 미치지 않았습니다.) 2016년에는 도커가 떠오르고 있었기 때문에 당연한 선택처럼 느껴졌습니다. 컨테이너 자체는 완전한 격리 및 보호를 보장하지 않았기 때문에 루비에서 준비된 솔루션(https://github.com/vaharoni/trusted-sandbox)을 사용했습니다. 이를 통해 샌드박스를 벗어나기 전에 코드를 더 잘 보호하고 표준화된 방식으로 운영 체제 요구 사항을 구성할 수 있었습니다. 코드 실행 시간, 작동에 필요한 메모리 및 CPU 주기를 적절히 제한하는 것이 매우 중요했습니다. 구성은 다음과 같습니다.
https://github.com/codesthq/cody_the_game/blob/master/config/trusted_sandbox.yml.example
물론 신뢰할 수 있는 샌드박스로는 아무것도 보장할 수 없었기 때문에 코드를 실행할 수 있는 특별한 웹사이트를 만들었습니다.
https://github.com/codesthq/cody_the_game/blob/master/app/services/task_runner/base_task.rb
각 작업에는 자체 테스트 케이스가 있어 구현된 솔루션의 정확성을 검증할 수 있었습니다. 이는 테스트 케이스에 사용자 코드를 삽입하여 모든 것이 독립적으로 실행되도록 하는 방식으로 이루어졌습니다.
https://github.com/codesthq/cody_the_game/blob/master/app/challenges/challenge/case.rb
물론 이 작업에는 많은 시간이 소요되었고 응답을 수집하는 동안 샌드박스를 실행할 여유가 없었기 때문에 코드를 데이터베이스에 저장하고 제출을 생성한 다음 긴 풀링을 사용하여 엔드포인트에 코드 상태를 가져오도록 요청했습니다. 이를 통해 애플리케이션 서버의 부담을 덜고 데이터를 적절하게 검증할 수 있었습니다. 물론 '스크립트 충돌'로부터 자신을 보호해야 했기 때문에 아래에서 볼 수 있듯이 ttl 변수를 사용하여 서버 쿼리 수를 제한했습니다.
대회 요약
2011년 9월까지 게임 통계는 다음과 같습니다:
- 세션 수입니다: 1945 - 작업을 보냅니다: 4476 - 정답을 보냈습니다: 1624 - 게임을 완료했습니다: 31
보시다시피, 가장 큰 계단은 더 이상 평범한 헬로 월드 예제가 아니었기 때문에 작업 # 2에서 시작되었습니다.
또한 읽어보세요:
Korean 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Arabic 
Italian 
Japanese 
Polish