ZeptoLabのプログラマ向けのテストタスクに関するコンテストの結果。 新しいテストタスク

最後に、Dream-Team ZeptoLabチームの場所を求めてAndroidとiOSの開発者の力の競争の待望の結果がまとめられています。 過去6か月間、私たちはそうすることを約束しました。2倍に成長し、修道院を概念的に設計しました。





どうでしたか







同じ期間に、もう一度ルールを確認するだけの十分な作業を確認することができました。常駐のスペシャリストは非常に少なく、彼らは隠れています。 状況の改善に貢献するために、これら2つのモバイルプラットフォームでのゲーム開発の主なポイントに関する意見を共有することにしました：いくつかの時点で、推奨事項を示し、AndroidとiOSの開発の達人からのコメントの場所を残し、歓迎します。



プログラマ向けのテストタスクは、Objective-C for iOSおよびNDK for Androidを使用してArkanoidゲームのプロトタイプを開発することでした。



iOSに送信されたタスクに応じて



iOS向けのアルカノイドの簡単なレビューから始めましょう（かなり多く送られました）-最も記憶に残る、明らかになります：






1.オリジナルのアイデア。

便利な管理。

優れた衝突処理。

プラットフォームの端に近づくと、ボールの方向が変わります




2.美しいグラフィック。 便利な管理。 非常に高速なゲームプレイ。 優れた衝突処理。




3.プリミティブに基づくシンプルなグラフィック。

便利な管理。

優れた衝突処理。

ピンチジェスチャの影響

ゲーム速度。

進むにつれて

テクスチャが下から現れる

「Zeptoに行きたい」という碑文があります




4. 3Dで完了して送信される唯一のタスク=）




5.アトラスの使用。

フレームごとのアニメーション。

便利な管理。

美しいグラフィック。




6.古い学校のテトリスのスタイルで作られた美しいテストタスク。

適切な音の伴奏。

便利な管理。




7.非常に美しいテストタスク。ほとんど完成したプロジェクトのように見えます。

便利な管理。

優れた衝突処理。

高速なゲームプレイ。




8.元のタスクとプロットを持つ唯一のタスク（スタッフがいるウィザードがオークから都市を保護します）。

素敵なフレームごとのキャラクターアニメーション。


よくある間違い：



1.メモリリーク。 残念ながら、自動参照カウントテクノロジを使用せずに実行されたほとんどすべてのタスクには、メモリリークがありました。

2.衝突処理。 多くのタスクで、ボールはキューボールまたは「ブリック」に詰まりました。 最も顕著に、これは非常に厳しく強制されたレベルで起こりました。 さらに、ほとんどの場合、これは最初の起動時に見られました。 ほとんどすべてのタスクで、処理はフレームレートに依存していました。

3.管理。 スワイプジェスチャまたは加速度計に制御がかかっていることがあり、キューボールで制御することが非常に困難になりました。 もちろん、この点はエラーに完全に起因するものではないため、私たちはそれについては問題ありませんでした。 しかし、それにもかかわらず、私たちの意見では、最も便利なコントロールは、キューボールが厳密にあなたの指に続くときです。

4.アプリケーションアーキテクチャ。 時には2つの極端がありました。 アプリケーション全体のメインコードが1つのクラスにある場合、またはその逆の場合、50個のクラスの下に作成されたため、このアプリケーションにはまったく不要です。

5.コード内の重大なエラー。 ほとんどの場合、OOPの原則に違反しています。 幸いなことに、このようなエラーはほとんどありませんでした。

6.時々、Cocos2Dなどのさまざまなサードパーティフレームワークを使用して実行されるタスクがありました。 このようなタスクはすぐに排除されました。

7.追加の操作なしでは開始したくないタスクもありました。 これはほとんどの場合、プロジェクトの設定が原因です。 たとえば、グローバルパスでリソースが追加されています。 そのようなエラーが5分以内に修正できた場合、タスクは競技から撤回されませんでした。

8.解像度。 コードには、多くの場合、1つの特定の解像度に関連付けられた多くのマジックナンバーがありました。 他の解像度では、それに応じて、すべてが動き出しました。

9.再起動します。 1つのアプリケーションは、一時停止すると一時停止します。 レベルを再起動するには、アプリケーション全体を再起動する必要がありました。

これもまったく間違いではありませんが、そのようなタスクの評価を複雑にします。



気持が良いから：



サウンドデザイン、スタイリッシュなグラフィックス、美しいアニメーションなど、いくつかのタスクは楽しいものです。 美しくデザインされたプロジェクトを見るのは確かに喜びであり、そのようなプロジェクトはよく記憶されていますが、メインタスクアルゴリズムが洗練されるまでさまざまな美しいものの追加を延期することをお勧めします。 何よりもまず、コードの構成と可読性、衝突を処理するアルゴリズム、制御の利便性と実装、そしてもちろん、発生したエラーの数を正確に考慮したためです。



Androidに送信されたタスクに応じて



Android向け開発用IDEのアクセシビリティの度合いはある程度高く、ハードウェア要件はiOS向けXcodeよりも低いという事実にもかかわらず、このOSのテストのフロー全体の約4分の1が送信されました。 これは、デフォルトIDEのネイティブ環境（通常はEclipse）の通常の統合デバッガーが不足していること、プログラマーが少なくとも2つのプログラミング言語（C ++とJava）を知っているか、それらをすぐに理解できるようにするための要件によって部分的に説明できます。



多くの人が初めてAndroid開発に精通しているという事実は、送信されたソースコードから明らかでした。 また、多くのプログラマーは、これを手紙やインタビューで正直に述べました。 このようなテストケースをより厳密に判断しませんでした。これは、開発者がAndroid向けの最初のプロジェクトであるという事実に甘んじていないためです。 誰もが平等な立場にいた。



プロジェクトの基礎としてネイティブ環境で作業するのは初めて、Android NDKに付属のサンプルを使用しました。これは、ビルドするものがあるように作業プロジェクトを取得する素晴らしい方法です。 より経験豊富なプログラマーは、自分のライブラリーと他のライブラリーが描くベストプラクティスを使用しています。 その結果、プロジェクトのソースコードのボリュームが大幅に増加することがあり、分析に十分な資料がありました。 ちなみに、「最軽量」プロジェクトのソースコードの量は14キロバイトで、1.6メガバイト（コードのみ）です。 ちなみに、最も簡単なコードの作成者はまだチームに参加しました



プログラムの主な要件の1つは、任意の画面解像度での正しい操作でした。 Androidの場合、この要件はiOSと比較してより重要です。 デバイスのアクセス許可のリストは「わずかに」長くなります（このトピックに関する有用な記事： opensignalmaps.com/reports/fragmentation.php ）。それらのすべてについて、2つの条件を満たしている必要があります。



1.一般的な物理学とゲームプレイの不変性。 簡単に言えば、ユーザーのアクション（たとえば、そのような制御方法が選択された場合は画面に触れる）を相対座標で記録し、別のデバイスでそれらを再生する場合、レベルの変化は変わらないはずです。

2.視覚部分の許容可能な変更。

さまざまな著者がこれらの条件をさまざまな方法で扱った。



画像の単純なスケーリングは明らかに適切ではありません。これは、丸いボールの代わりに楕円を表示する必要があるためです（または、タスクの一部でボールの役割を果たした正方形の代わりに長方形）



一部のプログラマーは、最小解像度のために競技場のサイズをピクセル単位で実装し、大きなデバイスでは、競技場を画面の中央または隅に表示しました。



ところで、さまざまなデバイスでOpenGLコードを使用してボールを表示するというタスク自体は簡単ではありません。 一部のユーザーは、画面サイズを大きくすると視認性が失われるテクスチャを使用しました。 一部はプログラムでボールを描きました。 ところで、このトピックに関する無関心な行商人のコメントを聞いてうれしいです：最初の制限（ゲームプレイの不変性）を考慮せずにOpenGLボールをどのように描画しますか？



コード自体について少し

以下は、Androidに送信されたタスクの一部のスクリーンショットです。




アルカノイドの素晴らしい実装。

著者は注意を払う必要があります

ボールの挙動について

ブロックから押しのけて、

角度の保存

衝突。 同様に

ゲームでは、ツールバーを非表示にすることが望ましいです。

ゲームのレンダリングに問題があります

ファームウェア2.3.2を使用したSony Xperia Play。





かなり興味深い実装。 この場合、重力ではなく、加速度計を使用して重力を制御します。 私は、FPSが高く、アニメーションにけいれんがないことを気に入っています。 ゲームプレイは非常に興味深く、同時に条件の一部であることが判明しました。 著者は、いくつかのデバイスのボールの形状と、ファームウェア2.3.6を搭載したSamsung Galaxy Noteおよびファームウェア4.0.4を搭載したGoogle Nexus Sで起動する際の問題に注意する必要があります。




アルカノイドの標準的な実装。 古典的なゲームプレイと問題の条件の厳守。 バットは加速度計によって制御されます。 長所のうち、かなり滑らかなレンダリングに注目することができます。 マイナスの-ビットの下部との衝突の処理の不正確さと、最初にボールの方向が厳密に垂直に設定されている場合の可能性-この場合、レベルは通過できなくなります。




堅実な作業、最高の実装の1つ。 便利なコントロール、優れたグラフィックス、優れたゲームプレイ全般。 崩壊するブロックのアニメーションの存在に満足しています。 筆者は、プレーヤーがビットの端でボールを繰り返し打つ場合の壁からの大きな逸脱角度でのボールの挙動を見て、パス角度を増やし、ファームウェア2.3.6を使用したSamsung Galaxy Noteのアプリケーションの動作不能にも注意する必要があります。




別の良い仕事。 ここでは、すべての要素がピクセルシェーダーで描画されます。レベルを渡すと、オールドスクールシェーダー効果は「90年代のこんにちは」になります。 プラスの点として、ゲームプレイの滑らかさと高いFPSに注目することもできます。 このプログラムは、テストされたすべてのデバイスで機能しました。 指が小さなビットを覆っているため、作成者はビットを上げ、タッチゾーンを下げる必要があります。



十分な数のオプションが送信されたため、同じローカル問題の解決策を比較する機会がありました。

たとえば、ボールを表示することに加えて、マップを初期化するタスクが示されます。



誰かがこれを実行しました（iOS）：



const intレベル[LD_HEIGHT] [LD_WIDTH] = {

{0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1}、

{0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1}、

{0,0,0,0,0,0,0,0,0,0,1,1,1,0,0,0,0}、

{0,0,0,0,0,0,0,0,0,1,1,1,1,1,0,0,1}、

{0,0,0,0,0,0,0,0,1,1,1,1,1,1,0,0,1}、

{0,0,0,0,0,0,0,1,1,1,1,1,1,1,1,1,1,0,1}、

{0,0,0,0,0,0,1,1,1,1,1,1,1,1,1,1,1,0,1}、

{0,0,0,0,0,0,1,1,1,1,1,1,1,1,1,1,1,0,1}、

{0,0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,0,1}、

{0,0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}、

{0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}、

{0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0}、

{0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0}、

{0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0}、

{0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0}、

{0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0}、

{0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0}、

{0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0}、

{0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0}、

{0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0}、

{0,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0,0}、

{0,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0,0}、

{0,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0,0}、

{0,1,1,1,1,1,1,1,1,1,1,1,1,0,0,0,0}、

{0,1,1,1,1,1,1,1,1,1,1,1,1,0,0,0,0}、

{0,1,1,1,1,1,1,1,1,1,1,1,0,0,0,0,0}、

{0,0,1,1,1,1,1,1,1,1,1,1,0,0,0,0,0,0,0}、

{0,0,1,1,1,1,1,1,1,1,0,0,0,0,0,0,0,0}、

{0,0,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0}、

{0,0,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0}};



そのような人（Android）：

for（int i = 0; i <MAP_W * MAP_H; ++ i）

（ブロック[i] =新しいブロック（））-> init（（i％MAP_W-MAP_W / 2）* 0.2、（i / MAP_W）* 0.2、i％3> 0？1：0、（i + 2） ％4> 0？0.7：0、（i + 3）％5> 0？0.9：0）;



そして、そのような誰か（iOS）：



//マップ生成



マップ[0,0] = 1;

マップ[0,1] = 2;

マップ[0.2] = 4;

マップ[0.3] = 1;

マップ[0.4] = 2;

マップ[0.5] = 0;

マップ[0.6] = 3;

マップ[0.7] = 2;

マップ[1,0] = 1;

マップ[1,1] = 3;

マップ[1,2] = 0;

マップ[1,3] = 1;

マップ[1,4] = 2;

マップ[1,5] = 3;

マップ[1,6] = 4;

マップ[1.7] = 2;

マップ[2.0] = 1;

マップ[2,1] = 0;

マップ[2,2] = 2;

マップ[2,3] = 3;

マップ[2,4] = 4;

マップ[2,5] = 3;

マップ[2.6] = 0;

マップ[2.7] = 2;

...

マップ[4.7] = 1;



わかりやすくするためにどのコードが書かれたか、問題の解決をスピードアップすることを目的とするコード、そして誰かを驚かすためにどのコードがコードかがすぐにわかります。



また、このトピックに触れたので、私たちはそのようなコードに関する行商人の意見に興味があります：その場合、存在する権利があり、ループ（iOSコード）に置き換える価値があります：



[player_pic addFrame：[UIImage imageNamed：@ "0.png"]];

[player_pic addFrame：[UIImage imageNamed：@ "1.png"]];

[player_pic addFrame：[UIImage imageNamed：@ "2.png"]];

[player_pic addFrame：[UIImage imageNamed：@ "3.png"]];

[player_pic addFrame：[UIImage imageNamed：@ "4.png"]];

[player_pic addFrame：[UIImage imageNamed：@ "5.png"]];

...

[player_pic addFrame：[UIImage imageNamed：@ "12.png"]];



iOSプラットフォームとAndroidプラットフォームを比較すると、iOSのコードのばらつきがより顕著であると言えます-判読できない例は本当に判読できず、スパゲッティコードはその名の通りであり、適切に設計されたタスクは本当に美しく見えます。



また、iOSに比べてAndroidプログラマーによる問題の定式化に対する創造性の低いアプローチに注目したいと思います.iOSでは、人間の肺がタバコのビットの助けを借りて壊れていましたが（アイデアは借用されたことが判明しました）、テトリスのクローン、さらにはファンタジーのストーリーラインを備えたプロジェクトです。



一般に、コードによって：iOSとAndroidのタスクを比較すると、次のようなことがわかりました。iOSのコードはあまり文書化されておらず、かなり頻繁に汚れています。 元々スタブであった関数に自動生成されたコメントを残した人もいれば、大きなモジュール全体をコメントアウトした人もいました。



両方のプラットフォームで、次のようなKOコメントの欠如



Void initGame(); //







しかし、本質的にはもっとコメントがあったかもしれません。



実装の不正確さについて



プログラマーの仕事は、「コウモリを制御する...画面上の特定の場所にあるレンガを壊す」ことでした。 多くの人がいくつかのレンガで構成されるレベルを描き、3Dオプションもあり、実際の野球用バットのオプションさえありました。

テスト課題は技術的な課題ではありません。文学研究をしませんでした。なぜなら、 両側がテストタスクの目的を理解しています。 プログラマーがもっと複​​雑で面白いことをした場合、これはプラスになります。 しかし、定式化されたタスクを厳守することもプラスであり、それ自体が人について多くを語っています。 しかし、すでに選択された方向に従うことは真剣に評価され、評価されたのは主に選択されたバージョンのゲームプレイのバグでした。



虫



ほぼ全員にバグがありました。 それほどではありませんが、レンダリングのエラーを重視し、ゲームエンジンの不正確さに注意を向けました。 グラフのエラーがすぐに目立つ場合、ロジックのエラーはより潜行性があります。 テストを通じて、すぐに優れたコードを作成できるプログラマーを探しました。 この場合、これは衝突の正しい処理、メモリリークがないこと、そしてもちろんゲームがクラッシュすることを意味します。



ロジックの典型的なエラー：



1.レンガからボールが出る方向を決定します。 結局のところ、ほとんどすべての人がエラーを抱えていたため、この些細な作業には慎重なテストが必要でした。 最も一般的なのは2つです。

•ボールが2つのレンガの接合部の角に落ちた場合、ボールはX軸とY軸に沿って反対方向に飛ぶ。

•ボールは、入射角とは異なる角度でレンガから飛び去ります。



2.ボールがすでにビットのレベルを通過し、ビットがそれを「カバー」しているときのボールの動作の誤った計算。 この場合、バグは画面の下部からボールを​​押しのけるまで非常に多様であり、問​​題の声明と直接矛盾しています。

Androidのコード内のロジックのエラーに加えて、システムエラーがありました。主に、メモリを操作する際の典型的なエラーです。 それらを詳細に説明しても意味がありません。 誰もアプリケーションをクラッシュさせませんでした。



おわりに



以下に、理想的なタスクの説明を示します。



1.衝突。 理想的には、低fpsなどに関連する問題がないように、ここで連続的な衝突追跡システムを作成する必要があります。

2.メモリリークはありません。 iOS 5.0は、テクノロジー-自動参照カウントによりメモリ処理を簡素化します。

3.優れたアプリケーションアーキテクチャ。 OOPが何であるか、そしてそれを正しく使用する方法を知っていることを示すことができればうれしいです。

4.便利な管理。 このタスクでは、私たちに思われるように、最も便利なコントロールは指でプラットフォームを厳密にフォローすることです。 さらに、プラットフォームは指と重ならないようにしてください（画面の下部から持ち上げることができます）。 タッチゾーンは、指を上下に動かしても制御が失われないように、画面上で動作する必要があります。 ここではマルチタッチはまったく役に立たないため、エラーを避けるためにオフにする必要があります。

5.個性。 タスクに熱意がある場合-これはプラスです。



これにより、アルカノイドコンテストの終了を正式に発表します。 しかし、Dream Teamの会社は不可逆的に成長しているため、iOSおよびAndroidプラットフォーム用の新しいプログラマーのセット（Leadsと普通の、しかし才能のある両方）を発表し、 新しいタスクを提供します。



最も簡単なバージョンでは、パックマンのプロトタイプを作成する必要があります。私たちのキャラクターがいる迷路と、彼に追いつこうとしているモンスターがいます。

迷路に散らばっている食べ物をすべて集めたなら、勝ちましたが、怪物が私たちに触れたなら、負けました。 あなたがキャラクターをコントロールする方法はあなた次第です。



プロトタイプ要件：

-レンダリングは、OpenGL（任意のバージョン）を使用して実装する必要があります。

-ゲームは、iOSの場合はObjective-CまたはC ++で、Androidの場合はNDK（C ++）を使用して作成する必要があります（プログラムは完全にC ++である必要があり、Javaではコードバインディングのみが可能です）サードパーティのライブラリ（Cocos2DやGLKitなど）。



私たちの側では、常に才能のあるプログラマーが必要なので、実行時間を制限しません。 効率は間違いなく競争力を追加しますが、仕事に満足することは最初の仕事よりも良いことです。 job@zeptolab.comで質問、提案、完了したタスクをお待ちしています。



私たちの仕事は面白く、創造的で、可能な限りチーム指向です。だから私たちのスケジュールは柔軟ですが、美しいオフィスでの存在は不可欠な要素になります。



突然、これらのスキルをまったく持っていないのに、ZeptoLab-a開発チームに参加したいという欲求が減らなかった場合、これらのツールのいずれかをすぐに学ぶことができます（当社の（すでに当社の）Android開発者の1人が1か月でAndroidのプログラミングを学んだ） （C ++をよく知っている）、最高のタスクの1つを送ってくれました）。 したがって、彼らが言うように、欲求があるでしょう:)



上記のレビューが、開発者が自分の作品の高品質を主張し、傑作を作成する際に何を探すべきかを理解するのに役立つことを願っています。 誰かのために-これは彼らの分野の専門家の輪で手を試して、多くを学ぶもう一つのチャンスです。



すべてのすべて。



あなたがトピックで共有するものがある場合-彼らが言うように、また歓迎します。



さよならを言わないでください。



ZeptoTeam