ゲームデザイン
このゲームをデザインする際、私たちの主な目標は、プログラマーのための楽しいエンターテインメントを用意することと、会社での仕事の一環として何か面白いことをすることでした。これまでのところ、私たちはゲームを作る能力を持っていなかったので、それは私たちにとって大きな挑戦でした。まず、このゲームが何であるかに焦点を当てた。最初の企画を考えた後、私たちは本番に臨んだ。
ゲーム制作の一環として、ハッカソンを実施し、グループに分かれて特定の作業を行うことにした。このような8時間の作業分担により、ゲーム内の対戦相手の外観、全体のレイアウト、システム全体のタスクとAPIの基礎を実現することができた。次の段階では、月に1回、4時間のミーティングを行い、3回でゲームを完成させることができた。
実施
弊社はRubyOnRailsに特化しているため、代表的な技術として選びました。しかし、このゲームはテキストになることを意図していなかったため、それに対するアプローチはSPAタイプのアプリケーションに反映されました。タスクの一部として、私たちはrailsからのアセットのよく知られたパイプラインに取り組み（2016年には、原理的にこれ以上のものはありませんでした）、全体の ジャバスクリプト に基づいている。 コード TypeScriptの助けを借りた。アプリケーションでは、標準的な役割分担があった：アセットとAPIソースとしてのRails、ユーザーとのインタラクションとしてのjavascriptと関連。しかし、ここではハイブリッドとして機能し、いくつかのビューは単にrailsからレンダリングされ、他のいくつかはJSからレンダリングされました。
タイプスクリプト
この分野での最初の実験だった。CoffeScriptの成功を信じていた時代だった。TypeScriptを使うには、typescript-rails gemを導入する必要があった。残念ながら、typescriptは静的型付け言語であるため、railsにデフォルトでアタッチされているライブラリからもこれを必要としたため、これは最終的なものではなかった。
https://github.com/codesthq/cody_the_game/blob/master/app/assets/javascripts/jquery.d.ts (特にrailsを使った組み込み資産管理システムを使う場合）。
ゲームとしてのCodyは、DOMのツリーを変更するだけでなく、ブラウザ側で多くのダイナミクスを必要としました。バニラjavascriptの代わりにTypeScriptを使うことは、コードの質において大きな飛躍であり、クラスとカプセル化の存在は、私たちにとって非常に魅力的でした。
APIとSPA
2019年、SPAアプリケーションは、壮大なReactまたは Vue 図書館を利用した。しかし2015年、私たちは別の方法でそれを行った。先に述べたtypescriptはゲームの実装に役立ち、一方jQueryはxml httpリクエストに関連するすべての作業を取り消した。当時は`$ .ajax`が仕事に必要なすべてだったのに対して、今はfetchを使うことができます。クライアントAPIを見てみよう！
もしapiだったら、認証の問題をどうにかして解決しなければならなかったのでは？そうだね。しかし、その場合、私たちはバンドを追いかけ（ここに書くことは可能でしょうか？私たちはバンドを使いました！）、railsセッションでcookie_keyを作成し、その後データベースに保存しました。それゆえ、私たちはすべてが順調であることを知っていた。
https://github.com/codesthq/cody_the_game/search?q=cookie_key&unscoped_q=cookie_key
ゲームのステータスはデータベースに保存され、何人のユーザーがポイントを持っているかという情報はデータベースから来ていた（まったく同じデータベースなのだろうか？ 代名詞で変えればいいのだろうか？）システム側にキャッシュがない場合、ACIDはいつも便利だ;)
温泉の場合、ページをリロードしないのが一番です。私たちはそれを古典的に解決し、htmlアンカーは不必要な依存関係を拡大することなく、最良の解決策でした。ターボリンクなんて誰が使うんだ？
スナップSVG
私たちがゲームをデザインする場合、素晴らしいグラフィックとアニメーションがなければリリースできません。当時、私たちは、アプリケーションでそのような要求を満たすにはどうすればいいのか、何時間も悩みました。一方では、キャンバスは奇跡を起こすことができ、他方では、きれいなhtmlは追いつくのがはるかに簡単で、誰もがそれを知っています。最良の解決策を苦労して探した結果、私たちはこの2つの解決策の組み合わせがsvgであることを突き止めた。svgは、グラフィックをベクターで簡単に表現でき、マークアップ言語で記述され、最も重要なことは、その場で修正できることだ。重要なのは、jQueryと同様に動作し、統一された方法で画像に対する操作を可能にするsvgファイル用のライブラリがあることだ。これはhttp://snapsvg.io、 私たちは、その特別なソリューションの使い方について、とてもいい思い出を持っている。
snap.svgをどのように使用したかの例を以下に示します：
https://github.com/codesthq/cody_the_game/blob/master/app/assets/javascripts/intro.js.ts
グラフィック・スケルトンを含むhamlファイルそのもの：
https://github.com/codesthq/cody_the_game/blob/master/app/views/game/show.html.haml
見ての通り、普通のDOMツリーと普通のrailsアプリのようなものだ！
トラステッド・サンドボックス
さて、ついにAPI、グラフィックス、SPAが登場した。しかし、ユーザーから送られたソリューションの実装についてはどうだろうか？
真っ先に思い浮かぶのはeval方式だが、我々はおかしくない;)2016年当時、dockerが台頭してきていたので、自然な選択だと感じました。コンテナ自体は完全な分離と保護を保証するものではなかったので、私たちはhttps://github.com/vaharoni/trusted-sandbox というRubyで用意されたソリューションを使いました。サンドボックスを出る前にコードをよりよく保護し、標準化された方法でオペレーティング・システムの要件を設定することができました。コードの実行時間、動作に必要なメモリ、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から始まった。
あわせて読みたい：
Japanese 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Arabic 
Italian 
Korean 
Polish