⛱️ 🌆 📧 私たちは、libGDXのためのコードと、インディー開発者の生活からの小さな喜びを描きます 👨🏽‍⚕️ 🚗 🛌🏽

こんにちは、Habr！このトピックでは、libGDXゲームエンジンの印象を共有し、普通のインディーデベロッパーの日常生活について話し、オフィス奴隷からの自由時間で過去数か月間行ってきたゲームの秘密のベールを開きたいと思います。これらのメモがlibGDXで何かを始めたばかりの人や、「夢のゲーム」のエンジンを選択した人に役立つことを願っています。

そして、猫をごめんなさい。 igrostroyとはまったく関係ありません。私は同時に描くことを学んでいます（学ぶことを試みています）そして今、私のこれらのトレーニング猫はどこにでもあります！ローファーを誰かに見せることを要求します。

描画

描画といえば。もちろん、ベテランのCGアーティストは私にスリッパを投げます（そして、彼らは絶対に正しいでしょう）が、私はプロセスからどのように立ち退きますか！絵がこんなにクールだとは思いませんでした！昔、すべてのゴミの中で、私はグラフィックタブレットをプレゼントしていました。竹はそこにあるものです。私は誰もが同じ「ふける」ことを買っていると思います。それから、かつて、マークキスラーの「30日で描くことができる」という本に目が行きました。いいえ、もちろん、30日間で描くことを学ぶことは、C ++を同時に学ぶことと同じです。誰もがこれを理解しています。しかし、絵はそこにある無形の才能ではなく、未知の島の牧草地でユニコーンを食べているエルフではありません。これは、プログラミング言語の構文と同じくらい単純なルールのセットです。もちろん、経験も！スタッフィング。しかし、優れたプログラマーも同様の方法で開発し、問題を解決し、パターン、テクノロジーを研究し、あらゆる種類のベストプラクティスに従います。

したがって、この本（より正確には、本ではまったく深刻ではありません）には、スティックスティックキュウリ以上のものを描くための基本的なルールがすべてあります。そして、手描きの波線が少なくともあなたに恐怖を引き起こしなくなると、それはクールです！プロセス自体が喜びをもたらし始めます。私個人にとって、これは啓示でした。

また、この機会を利用して、優れたエディターであるSketchBook Proにアドバイスをしたいと思います。そこにはプロも描かれていますが、それはまさに非専門家が必要としているものです。ユーザーフレンドリーで、機能が多すぎません。ライセンスは、Photoshopとは異なり、比較的安価です。この不快な「サブスクリプションソフトウェア」スキームはここで適用されますが、基本的な機能は無料で利用できます。

鉛筆、ボールペン、ブラシの3つのツールのみを使用しています。正しく呼び出す方法がわからないので、外出先でカーブをまっすぐにする機能は非常に便利です。ペンを片手で持ち、もう片方の手でペンを持ち（キャンバスの回転とスケーリング）、行ってください！創造性を創造します。

なぜUnityではないのですか？

しかし、気が散りました。ゲームエンジンの選択に関して、最初に出てくる唯一の質問は、「なぜユニティではないのですか？」です。したがって、！私はAndroid Studioに慣れているため（最近、企業アプリケーションを作成しました）、Java SDKを多少知っています。そして、単純な2DゲームにUnityなどの多機能モンスターを使用することは、少し「すずめ銃」ですよね。なじみのないIDE、別のアプローチ、再び。そして、空のプロジェクトのサイズは20 MBですか？はい、libGDXではゲーム全体とグラフィック（ここではそれほど小さくはありません）の重量が軽くなっています！私たちは高速インターネットの時代に住んでいると理解していますが、それでもアプリケーションのサイズとインストール数の間には相関関係があります。

もっと深く掘り下げると、「アプリケーションのサイズが大きすぎます。Wi-Fi経由ではなくダウンロードしてもよろしいですか？」という警告が出ます（実際、覚えていないが、本質はこれです）。

一般に、以前にAndroid SDKを扱ったことがある場合、libGDXは、クロスプラットフォーム開発へのスムーズな移行のための優れた選択肢です。 libGDXを初めて知ったときに自分で学んだすべての長所と短所を定式化しようとします。

長所

無料です。
クロスプラットフォーム。デスクトップビルドは、WindowsとMacで等しくシームレスにビルドおよび実行されます（Linuxでは確認する方法がありませんでしたが、同じ方法であると確信しています）。 HTMLについては、ちょっとしたニュアンスに出会いました。追加するすべてのパッケージは、gwt.xmlのコアプロジェクトに登録する必要があります。登録しないと、ビルドされません。 Androidには何の問題もありません。iOSは今のところ私の計画にのみ含まれています。
Android開発者の低エントリーしきい値。同じスタジオ、同じGradle。すべてのゲームロジックとAndroidプロジェクトを記述するCoreプロジェクトがあります。これは、大まかに言うと、Viewが存在するMainActivityであり、その中でCoreプロジェクトが実行されます。コアプロジェクトから、Androidプロジェクトで記述したプラットフォーム依存部分を簡単に呼び出すことができます。そして非常に素晴らしいことは、Googleのチュートリアルから直接プラットフォームコード（広告、分析、ゲームサービス）を実装することです。通常のアプリケーションのように。つまり、ライブラリ、サードパーティの拡張機能などはありません！

短所

関連する、賢明なチュートリアルは見つかりませんでした。ここでもHabréには多くの情報がありますが、通常は画面にスプライトを表示する方法に帰着します。実際には、これは必要ありません、なぜですか？より高いレベルの抽象化を使用する方が賢明です：Actor、Scene（これについては以下で詳しく説明します）。新しいエンジンに慣れるとき、クイックスタートガイドでは、さまざまな画面に合わせてゲームを正しくスケーリングする、リソースのバックグラウンドロード（これはすべて良いです）、画面/シーンおよびそれらのオブジェクトの管理を参照してください。

短所についての会話を続けると、libGDXに少し控えめな感じがします。ここには優れた抽象化があります：スクリーン-ゲーム画面、ステージ-シーンまたはレイヤー、アクター-このシーン上のオブジェクト。私のゲームでは、レベル、メニューなど、すべてのゲーム画面に1つの画面と多くのステージを作成することにしました。 Actorからゲームオブジェクトを継承し、 stage.addActor（ボール）を実行するだけです。次のステージでは、レンダリング、移動などを行っています。このオブジェクト。したがって、アクター自体は何もしません。スプライトは表示されず（ゲームオブジェクトの99％はスプライトです）、2つのアクター間の衝突をチェックすることはできません。一般的には何もありません！

独自のSimpleActorを作成し、そこからゲームオブジェクトを既に継承する必要があります。

コード

public class SimpleActor extends Actor { private final TextureRegion region; public SimpleActor(TextureRegion region) { this.region = region; setSize(region.getRegionWidth(), region.getRegionHeight()); setBounds(0, 0, getWidth(), getHeight()); } @Override public void draw(Batch batch, float parentAlpha) { batch.draw(region, getX(), getY(), getOriginX(), getOriginY(), getWidth(), getHeight(), getScaleX(), getScaleY(), getRotation()); } }

アニメーション化されたゲームオブジェクトが必要な場合（そうでない場合、どこにありますか？）

コード

 public class SimpleAnimatedActor extends Actor { private Animation animation; private TextureRegion currentFrame; private float stateTime; private boolean started; public SimpleAnimatedActor(float frameDuration, Array<TextureRegion> frames) { animation = new Animation(frameDuration, frames); currentFrame = animation.getKeyFrame(stateTime); setBorders(frames.get(0)); } private void setBorders(TextureRegion sample) { setSize(sample.getRegionWidth(), sample.getRegionHeight()); setBounds(0, 0, getWidth(), getHeight()); } public void start() { stateTime = 0; started = true; } public boolean isFinished() { return animation.isAnimationFinished(stateTime); } @Override public void act(float delta) { super.act(delta); if (!started) { return; } stateTime += delta; currentFrame = animation.getKeyFrame(stateTime); } @Override public void draw(Batch batch, float parentAlpha) { batch.draw(currentFrame, getX(), getY(), getOriginX(), getOriginY(), getWidth(), getHeight(), getScaleX(), getScaleY(), getRotation()); } }

プリミティブな衝突チェックを実装するために、SimpleActorにPolygonを追加できます：

コード

 Polygon polygon = new Polygon(new float[]{0, 0, getWidth(), 0, getWidth(), getHeight(), 0, getHeight()}); polygon.setPosition(getX(), getY()); polygon.setOrigin(getOriginX(), getOriginY()); polygon.setScale(getScaleX(), getScaleY()); polygon.setRotation(getRotation());

などなど。もちろん、これは特定の困難を引き起こしません。それでも、なぜエンジンで同様のことをしないのか理解できませんか？そのため、追加したコードをプロジェクトからプロジェクトにドラッグする必要があります。

フラグメンテーション

Androidデバイスの動物園全体でゲームを同等にクールに見せるためにはどうすればよいですか？私にとって、これは重要な問題の1つです。したがって、libGDXで画像をスケーリングする問題をどのように解決したかを詳しく説明します。

タブレットではより多くの環境を表示し（4：3）、スマートフォンではより少ない環境を表示する（16：9）とき、私はすでに古典的なアプローチが好きです。この場合、どこにも引き伸ばされるものはなく、ゲームオブジェクトはサイズを変更しないと言われます。すべてのグラフィックを1つの解像度で保存します。960x1280（4：3）です。画面の中央には、プレーヤーが操作するすべてのオブジェクトが入る必要がある「ゲーム領域」720x1280（16：9）があり、残りは特定のデバイスに応じて風景であり、カットできます。この原則を説明する最も簡単な方法は、写真を使用することです。

LibGDXは、このためのすべての機能を提供します。唯一の注意点-一部のオブジェクトは画面の端に取り付ける必要があります。上の画像の[ホーム]ボタンのように。これを行うには、ゲーム座標で画面の実際の左端と右端を知る必要があります（上と下が簡単になります-それぞれ常に1280と0です）。いくつかのコードを書きましょう：

コード

 public class MyGame extends Game { public static final float SCREEN_WIDTH = 960f; public static final float SCREEN_HEIGHT = 1280f; public static float VIEWPORT_LEFT; public static float VIEWPORT_RIGHT; private GameScreen mGameScreen; @Override public void create() { mGameScreen = new GameScreen(); setScreen(mGameScreen); } @Override public void resize(int width, int height) { super.resize(width, height); float aspectRatio = (float) width / height; float viewportWidth = SCREEN_HEIGHT * aspectRatio; VIEWPORT_LEFT = (SCREEN_WIDTH - viewportWidth) / 2; VIEWPORT_RIGHT = VIEWPORT_LEFT + viewportWidth; } @Override public void dispose() { super.dispose(); mGameScreen.dispose(); } }

ここで何が起こっていますか？これは、Gameから継承したゲームのメインクラスです。ここでScreen（私の場合は画面のみ）を作成および設定し、 resize（）をオーバーライドします。このAndroidのイベントは、アプリケーションの起動時にトリガーされます。ここで、画像の左端と右端を計算できます（VIEWPORT_LEFTおよびVIEWPORT_RIGHT）。

GameScreenでは、 FillViewportをインストールする必要があります。アスペクト比がターゲットと一致しない場合、画像が確実にトリミングされるようにするのは、彼です。ビューポートは、ゲームの世界への窓口です。それらはいくつかのタイプがあり、これに関するドキュメントは私よりもさらにわかりやすく、コードを提供します：

コード

 public class GameScreen implements Screen { private final OrthographicCamera mCamera; private final Viewport mViewport; private final AssetManager mAssetManager; private Stage mActiveStage; public GameScreen() { mCamera = new OrthographicCamera(); mViewport = new FillViewport(MyGame.SCREEN_WIDTH, MyGame.SCREEN_HEIGHT, mCamera); mAssetManager = new AssetManager(); mActiveStage = new MyStage(mViewport, mAssetManager); } @Override public void render(float delta) { mCamera.update(); Gdx.gl.glClearColor(65 / 255f, 65 / 255f, 65 / 255f, 1f); //    Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT); mActiveStage.act(delta); mActiveStage.draw(); } @Override public void resize(int width, int height) { mViewport.update(width, height, true); } @Override public void dispose() { mActiveStage.dispose(); mAssetManager.dispose(); } }

ここでは、一般に、すべてが直感的に明確である必要があります。resize（）を使用してmViewport.update（width、height、true）を実行することを忘れないでください。

メカニカルボックス

エンジンについて簡単に説明したので、ゲーム自体についてもう少し言いたいと思います。私は1年間ゲームをプレイしていませんが、企業の沼地はほとんど私を吸いました。しかし、それは私が夢を見ることを止めませんでした。クエストの夢、可能な限り複雑なパズル。お金や他のフリープレイの愚かなことの手がかりなし。

したがって、メカニカルボックスのアイデアは、内部にあるものを確実に保護するという1つの目的で作成されたデバイスです。保護の各レイヤーは、新しいゲームメカニズムを備えた個別の独立したパズルです。

巨大なプラスのインディーズ、私たちは私たちが望むことをする余裕があります。保持率やその他のマーケティングについては気にしません。はい、すべてのコマーシャルスタジオのgamediseは、プレイヤーの割合が最初のレベルで動けなくなるのを見てから自分自身を撃ちます！そして、自分でプレイしたいゲームを作ることができます。

一般的に、今年の8月に私はBoxの建設を始めました。少し描いたので、私はそのようなボリュームを引き出すことができないことに気づきました、そして、私の芸術は品質で私に合いませんでした。控えめに言っても、彼は独特です。その結果、gamedev.ruでこの冒険に参加することに同意したアーティストが見つかりました。驚いたことに、ウラジミールと私は同じ都市だけでなく、近隣の通りにも住んでいることがわかりました。 Mechanical Boxに適切な外観を与えたのは彼でした。私は「それがどうだったか」と「それがどうなったか」を記念品としても保持しました。違いは明らかだと思います。

私はメカニカルボックスの作業を続けていますが、このアイデアの開発についていくつかの考えがあります。あなたの強さをテストすることにした場合、ゲームは既にGoogle Playで公開されています。 もう一度UFOの注目を集めないように、リンクは提供しません 。また、Boxは人気のある1つのリソースですぐにパーツに分解されましたが、このパズルは非常に深刻な課題です。個人的に、私を喜ばせます。あなたが行き詰まるところまで予測することさえできます。これは、クレーンのあるレベル（このいまいましい爪を右に動かす方法）、または3つのマルチカラーの正方形（この謎は簡単に思えますが、統計は頑固なものです）。または、「失われたゼロのクラブ」へようこそ-さて、これはエリートです。

読んでくれて、質問して、コメントを書いてくれてありがとう！

良いことをして水に投げてください。

私たちは、libGDXのためのコードと、インディー開発者の生活からの小さな喜びを描きます

描画

なぜUnityではないのですか？

長所

短所

フラグメンテーション

メカニカルボックス

More articles: