※当サイトは、アフィリエイトプログラムにより商品をご紹介しているため、記事内に広告を含むことがあります。 これらのリンクをクリックしてお買い物をすることで、このサイトを支援することができます。 Tiled Map Editorの仕組み Tiled Map Editorが扱うデータ構造 Tiled Map Editorが扱うデータ(*.tmx)のデータ構造は以下のとおりです。 TMX +-- version : バージョン番号 +-- orientation : 向き +-- width : 幅 +-- height : 高さ +-- tilewidth : チップの幅 +-- tileheight : チップの高さ +-- property : プロパティ | +-- name : キー | +-- value : 値 | +-- tileset : タイルセット | +-- firstg
■これは何？ ゲームプログラムしていて、気が付いたことを書き留めておくものです。 ■当たり判定 ▼当たり判定は「円」で充分 「円」による判定は、汎用的で、直感的に分りやすいためバグも出にくく、コストパフォーマンスが高いです。なにか特別な理由がある（地形との当たり判定とかニードル（縦長の弾）など）以外は、「円」で判定を行ったほうが良いみたいです。 ▼衝突応答は、複数回に分けて判定を行うとうまくいく 例えば、地形にぶつかった場合押し戻す、という処理を実装する場合、XY方向の判定をまとめて行うのではなく、 X方向に移動、ぶつかってたら押し戻し Y方向に移動、ぶつかってたら押し戻し というように、２回に分けて判定を行うと、うまくいきます。 ▼移動速度が速くて、通り抜けが起こる場合 以下のどちらかの方法を取ります。 通り抜けが起きない移動量になるよう、制限をかける 通り抜けが起きない移動量になるよう
これは何？ RPGの核となるシステムである、「マップ」と「イベントスクリプト」の作り方・連携について解説します。 ただ、RPGの本質は、プレイヤーのステータス、アイテム、敵パラメータの調整や、シナリオや世界観などの雰囲気作りにあります。そういった本質部分の作り込みをしやすくする、というのが、「マップ」「イベントスクリプト」システムの目的になります。 RPGツクールを作る ここで構築するシステムは「RPGツクール」の簡易版のようなものです。ここの内容が今一つピンとこない場合は、「RPGツクール」を試しに使ってみるのもいいかもしれません。 全体像 「マップ」は、地形レイヤーとイベントレイヤーという２層構造になっています。１つの「マップ」につき、１つの「イベントスクリプト」が対応します。地形レイヤーには、草原・山・海などプレイヤーが移動するフィールドを配置します。 イベントレイヤーは、NPCやお
■このページについて WEB+DB PRESS Vol.68にのっていた記事「はじめてのゲームAI」の記事を自分なりにまとめたメモです。 ■AIの基本原理 AIを考える上で欠かすことのできないものは、 外部の環境との関わり です。 AIには、外部との関わりなしで動作するものもあります。例えば、出現してもプレイヤーお構いなしで直線移動するような敵です。 これはこれで動作のパターンを覚えて撃ち落とすという楽しみもあるのでOKなのですが、パターンを覚えてしまうと、簡単に倒せる・避けられるので、そういった敵ばかりでは退屈ですよね。 そこで、ぱっと思いつくのが、プレイヤーを狙って動く敵ですね。このAIは、プレイヤーが避けても追いかけてくるので、プレイヤーは近づかれないように、何とかしてその敵を倒す必要が出る面白さが生まれます。 ここでは「プレイヤー」という外部環境との関わりですが、ゲームによってはフ
Game A Weekとは、一週間で1つゲームを作って、ゲーム開発者の経験値を上げる方法として、オランダのインディー系デベロッパー「Vlambeer」のRami Ismail氏が提唱したものです。 Gamasutra: Rami Ismail's Blog – Game A Week: Getting Experienced At Failure Rami Ismail氏は「Vlambeer」の共同設立者であるJan Willem氏が圧倒的なゲーム開発・ゲームデザインをする力を持っており、それは「数百ものプロトタイプを作り、失敗を繰り返しながら経験を積んだ」からだということに気がつきました。そして、それを実践するための方法の1つとして「Game A Week」を提唱しました。 ■定義 Rami Ismail氏が提唱する「Game A Week」の定義は以下のとおりです。 1. 毎週ゲームを
1.はじめに ここでは、戦術SLGの作り方について説明をします。 前回は、移動範囲の求め方を紹介しましたが、今回はその応用として、コンピュータの移動アルゴリズムを紹介します。 2.基本編 まず最初は、「移動可能な範囲にプレイヤーがいる」といったシンプルなモデルで考えてみます。 最短移動距離を求める この表は、前回の最後で求めた、移動範囲の検索結果です。 黄色の部分にプレイヤーがいるとします。 人間であれば、上→上→右（攻撃範囲を考えると右は必要ない）と瞬時に答えが出ますが、コンピュータはそうはいきません。 最短距離で移動させるアルゴリズムとしては、 経路探索開始地点をプレイヤーがいる地点（黄色）とする 数値が増加する地点に移動する といった方法を用います。 探索方法は、前回の移動範囲探索処理と同じく上下左右を再帰処理で探索し、コンピュータのユニット（赤色）がある地点のとなりまで探索できれば
■サンプルコード ちなみにサンプルはこちらです。 クォータービューサンプル [download id=”14″] ★マップチップ座標から、クォータービュー座標への変換 問題を簡単にするため、このような座標変換をすると考えます。 右回りに45度回転させる数式を以下に書いていきます。 w = チップの幅 h = チップの高さ x = マップチップ座標(X) y = マップチップ座標(Y) X = クォータービュー座標(X) Y = クォータービュー座標(Y) とします。 ■マップチップ座標からクォータービュー座標に変換する マップチップ座標からクォータービュー座標に変換する場合は、 となります。 ■クォータービュー座標からマップチップ座標に変換する クォータービュー座標からマップチップ座標に変換する場合は、 ちなみにマップチップ座標とは、マップエディタ内の座標のことです。 これは「8×8」のマ
今回は、3Dダンジョンを擬似的に表現する方法を解説してみます。 まあ現代的なプログラムなら3D描画でやるべきですが、3Dの実装が面倒なときは2Dでやるのも手です。まず準備として、視界の範囲や奥行きをどうやって表現するかを考えます。 とりあえずは、どんなものを作るかFlashでサンプルを作りましたので、「こちら」を見てもらえればと思います。 これは、視界を奥「２」まで、左右を「１」までとしたものです。この場合視界は、３×３マスで表現することができます。そして、０～２が奥、３～５が中距離、６・８が近く、となります。遠近法を使えば、近くにあれば大きく、遠くにあるほど小さく映るので、一番近い壁を「３」、中距離の壁を「２」、遠い壁を「１」の比率で考えます。 壁の描画 先ほどの図に合わせて壁を作っていきます。 0(左・奥） まずは左側の奥にある壁です。いくつかの壁は多角形になってしまうので、多角形の描
ローグライクの定義をまとめてみました。 ローグライクの定義には大きくわけて2つの解釈があります。それは「PDL」と「ベルリン解釈」です。 PDL PDLとは、ローグライクのコアな要素である「Procedual(自動生成)」と「Death(死)」、「Labyrinth(迷宮)」の頭文字をとったものです。以下の図は、ローグライクライクゲームをPDLとベルリン解釈で比較したものです。 すべてのゲームがPDLの要素を満たしており、PDLを満たしていると「ローグ性が強い」と言えます。 ベルリン解釈 ベルリン解釈というのは、「ローグライクはこんな要素が必要だよね」ということを話し合って決めた定義だそうです。 Berlin Interpretation このページの内容を翻訳してみました。 ■一般原則 ローグライクゲームはゲームジャンルの1つです。単なるローグのような、という意味ではありません。ローグラ
概要 スコアとは何であるかを考察するページです スコアとは スコアは「プレイ」を「数字」で評価するものです。 たとえば、 敵を倒した→「おお、いいね。100点あげましょう」 ボスを倒した→「凄い！ よく倒せたね。じゃあ、1000点あげましょう」 というように「敵を倒した／ボスを倒した」という「プレイ」を「点数」で評価します。 評価とは、プレイヤーを褒め称えることです。良いゲームは、プレイヤーを褒めることが上手で、プレイヤーに「もっと褒められたい」と思わせ、次回へのプレイ動機（リプレイ価値）を上昇することができます。 リプレイ価値を上昇させると、プレイ回数を増やすことができるため、ゲームの寿命を長くすることができます。 スコアのタイプ スコアには、 即時評価 一括評価 の２つのタイプがあります 即時評価 アクションを起こすたびに、それをスコアとして評価する方法です。 敵を倒した アイテムを取
gamasutraの翻訳記事「ゲームメカニクスの深みを評価する」をさらに自分なりに解釈してまとめてみました。 テストプレイヤーから以下のような感想がくる場合、 「すぐ飽きる」 「簡単すぎる」 「やりがいがない」 「同じことの繰り返し」 「もっと色々な遊びが欲しい」 その感想は２つのことを意味しています。 ゲームメカニクスが「浅い」 遊びの幅が「狭い」 これを解消するには、以下の手順を踏みます。 問題点を洗い出す 不足があればスキルを足す １．問題点の洗い出し方法 問題点を洗い出すには、 このゲームは「明確な目標」を提示しているか？ このゲームは「有意義なスキル」を提供しているか？ を考えます。 a．明確な目標の提示とは？ まず、明確な目標を提示できているかを考えます。目標が曖昧で、やるべきことが何かわからない場合、プレイヤーはあてずっぽうに操作を行い、結果、やりがいを得られなくなります。
騎兵が歩兵に圧倒的に強いですよね。そうなると、騎兵を雇う数は少なくていいですよね。かといって、少なくしすぎると、騎兵が全滅した場合に、歩兵が脅威になってしまいます。 というように、力関係に偏りを持たせると、「うーん、どれだけ騎兵を雇うのがいいのだろう…」と、プレイヤーを悩ませることができます。 そして、騎兵は雇うコストは「高い」ものとします。（お金がかかる） そうすると、「あああ、騎兵をもうちょっと雇いたいけど、お金がない…」と、プレイヤーをさらに悩ませることができます。 4.ジャンケンの拡張 さらにゲームを面白くするには、ユニットの種類を拡張します。 例えば、モンク・忍者を追加します。 すると、例えばこんな感じになります。 ここで気をつけておかなければならないことは、「拡張」はOKですが、「縮小」はダメ、ということです。 例えば、ゲームリリースの期日に間に合わないということで、図から１つ
アディクション・ベース・ゲームデザインとは？ 依存症ベースのゲームデザイン。 http://rpgvault.ign.com/articles/986/986323p1.html 本文の意訳 意訳というか、主観が時々紛れ込んでいるので、ご注意を…。 if a game uses rewards of any sort to entice you to experience highly repetitive content, you should see what it's trying to do and which of your buttons it's trying to press. If you don't mind, that's cool, but you should understand it. プレイヤーをゲームに依存させるには、「反復性のある動作」を経験させ、「報酬
ひどいチュートリアルでプレイヤーをガッカリさせる8つの方法（The Designer’s Notebook: Eight Ways To Make a Bad Tutorial）を個人的にまとめてみました http://www.gamasutra.com/view/feature/6406/the_designers_notebook_eight_.php はじめに 近年のゲームは大型化・複雑化に伴い、ルールや操作が難しいものとなりました。そのためチュートリアルでゲームのルールや操作を学ぶことが不可欠となっています。しかしチュートリアルを理解させようとするあまり、それが楽しくないゲームが増えてしまっているのも事実です。そんなガッカリさせられるチュートリアルのポイントは以下の8つです。 チュートリアルを強制しろ たくさん読ませろ わかりにくい説明にしろ 手順を省略せよ 失敗時は多くの罰を与え
Rapid Game Prototyping: Tips for Programmers http://gamasutra.com/blogs/HermanTulleken/20140119/208901/Rapid_Game_Prototyping_Tips_for_Programmers.php を翻訳した記事となります。 ━━━━━━━━━━━━━━━━ 2013年11月、私と2人の同僚は30ものゲームを作成しました。私は以前にもいくつかのゲームのプロトタイピングを作っていますが、このような短期間で非常に多くのゲームを作ったことは、私に新しい洞察を与えました。 この記事では、TIPSという形式で、これらの観察を集めました。 プロトタイプを記述するより一般的な視点については、 「7日間でゲームプロトタイプする方法(How to Prototype a Game in Under 7 D
Unityでタワーディフェンスを作るためのチュートリアルとなるKindle本を書きました。 今回の表紙イラストも、漫画家の炎堂たつや先生に描いてもらいました。いつも素晴らしいイラストをありがとうございます！ 本のタイトルは「タワーディフェンスのつくりかた Unity5.0編」です。 内容は、Unityでタワーディフェンスを丸々1本作るという、今までにない試み（たぶん）の内容となりました。詳細に手順を記載していますので、手順通りに進めることで誰でもタワーディフェンスを作ることができます。 ■対象読者 誰でも作れる……、というのが本書の売りですが、Unityの2D機能について、ある程度の理解や慣れは必要です。そのため、対象読者は「Unity中級者以上」とさせていただきます。具体的には以下の条件を満たしている必要があります。 Unityの基本的な操作を理解している Unityの2D機能の基本的な
━━━━━━━━━━━━━━━ ■（※2015/6/19追記）バージョンアップを行い、増ページしました。以下の記事が追加されています。 Chapter4 2Dゲームを作るときに知っておきたいコンポーネント・クラス Chapter5 uGUI入門 サポート掲示板のURLを追記 ■（※2015/10/15追記) 第一版を購入された方へのご連絡 改訂版の入手方法は、お手数となりますが、以下のページなどを参考に手動で更新が必要となります。 http://petite-lettre.com/blog/archives/1301 これは、2013年あたりから自動更新の審査基準が厳しくなったためで、本に大きな不具合がない限り自動更新の審査が通らなくなったためとなります。 ■（※2015/10/15追記) 3Dサウンドの設定について シューティング作成のチュートリアルで「3Dサウンドの設定を無効にする」と
GameMaker:Studioでタワーディフェンスを作るためのチュートリアルとなるKindle本を書きました。 今回の表紙イラストも、漫画家の炎堂たつや先生に描いてもらっています。ありがたやー。 本のタイトルは「タワーディフェンスのつくりかた GameMaker:Studio編」です。 内容は、GameMaker:Studioでタワーディフェンスを丸々1本作るという、今までにない試み（たぶん）の内容となりました。詳細に手順を記載していますので、手順通りに進めることで誰でもタワーディフェンスを作ることができます。 ■対象読者 誰でも作れる……、というのが本書の売りですが、GameMaker:Studioの基本的な機能やGMLについて、ある程度の理解や慣れは必要です。そのため対象読者は「Unity中級者以上」とさせていただきます。具体的には以下の条件を満たしている必要があります。 GameM
「5 ways to be a successful indie developer」（インディーズゲーム開発で成功する5つの方法）を個人的にまとめた記事となります。 http://gamasutra.com/view/news/173091/5_ways_to_be_a_successful_indie_developer.php インディーズゲームのシーンで成功するための5つの重要なポイントは以下となります。 一人だけで作るな 自分の強みに注力せよ 小さなゲームをたくさん作って経験を積め 大手パブリッシャーがやらないことをやれ 作ったゲームの良い点は次に引き継ぎ、悪い点は改善せよ これらについて、個人的な意見も加えてより詳しく説明をしていきます。 ①一人だけで作るな ゲームは少人数で作ると尖ったゲームになりやすいです。しかし一人だけで作ると、理解できない複雑なルール、分かりにくいゲーム
自動生成（プロシージャル）コンテンツをゲームで使うときの5つのヒント（5 tips for using procedurally-generated content in your game）を個人的にまとめた記事です http://www.gamasutra.com/view/news/181853/5_tips_for_using_procedurallygenerated_content_in_your_game.php 重要なポイントは以下の5つです。 ランダムに頼り過ぎない ランダム性の理不尽さを緩和する 偏りを意図的に入れる デバッグ機能を充実させる 別の何かと組み合わせる ①ランダムに頼り過ぎない すべてを自動生成にするのは必ずしも最良とは限りません。ゲームメカニクスに適合する部分に絞って自動生成を行います。例えば通常は固定コンテンツのレベルを用意し、ゲームプレイに影響に出な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く