質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
Java

Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

Q&A

解決済

2回答

695閲覧

マップ制のゲームで、オブジェクトが自身の座標を持つことは不自然かどうか

chankane

総合スコア139

Java

Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

0グッド

1クリップ

投稿2017/06/04 04:27

###前提・実現したいこと
こんにちは毎度お世話になっております。
今回は、ツクールのような、RPGゲームをつくりたいのですが、前回の質問でご指摘を受けて悩んでいることがあります。
具体的には、今回のようなマップ性のゲームで、キャラクターなどのオブジェクトが自身の座標をもつことに違和感があるというものです。

簡単に書くと、
座標 → オブジェクト
オブジェクト → 座標
どちらの流れが自然かで悩んでいます。

質問の意図がつかめない方は、上のリンク「前回の質問」をご参照ください。
ずいぶんとおおざっぱな質問でわかりにくいと思いますが、そのときは追記依頼をお願いします。
どうぞよろしくお願いします。

###今のところ考えられる方法
配列の中にオブジェクトがあって、座標を指定してそこからオブジェクトを取り出す方法

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答2

0

ベストアンサー

個人的にはそのゲームの内容によって設計を考えます。

ドラゴンクエストとファイアーエムブレムというと大体のゲームのイメージがつかめますでしょうか?
マップ上で十字キーを押したときに、前者はキャラクターが、後者はマップ上の位置がカーソルで動きます。

前者であれば、十字キーを押すとキャラクターが能動的に動くイメージです。この場合、個人的にはマップ上を移動するメソッドはキャラクターのオブジェクトを主導として実装したいので、おそらくキャラクターが現在の座標を持っているほうが処理が円滑に進むのではないかと思います。左に進みたいのだがそこには進めないので動かない、とか、前に宝箱があってそれをあけるかどうか、という判断もキャラクター自身にさせたいです。
ただしキャラクターの周りに何があるかは別管理にするでしょうね。キャラクターは現在の座標を持っていて、その座標を元に別の地形を管理している箇所に問い合わせを行い、前に何があるかを返します。その返り値をもって、キャラクターが何をするかという選択肢が示される。というような実装が自然に感じられます。

後者であれば、キャラクター自身が能動的に動くのではなく、マップ上の地形が既に存在し、そこにキャラクターが乗る、というイメージです。キャラクターが能動的に相手を攻撃する、というよりは、地形を選んでそこにキャラクターがいて、周囲に敵がいれば攻撃することもできる、というようなイメージを私個人は持ちます。ですのでその場合キャラクターには現在の座標は持たせないかもしれません。キャラクター自身が自分の座標を持っている必要を感じないからです。
ただし同様のゲームであっても周囲に敵がいればキャラクターは自動的に相手を攻撃する、というようなゲーム内容の場合はキャラクターが自分自身の座標を持っているほうが処理が円滑に進むだろうと思いますし自然に感じられます。

上記のようにそのゲームの内容によって何が自然な設計かは変わってくると思います。

投稿2017/06/04 05:23

akabee

総合スコア1947

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

chankane

2017/06/04 05:54 編集

自分の解釈が合っていれば、前者の能動的に動くイメージに該当します。 >ただしキャラクターの周りに何があるかは別管理にするでしょうね。キャラクターは現在の座標を持っていて、その座標を元に別の地形を管理している箇所に問い合わせを行い、前に何があるかを返します。その返り値をもって、キャラクターが何をするかという選択肢が示される。というような実装が自然に感じられます。 そのように実装しています。 ちなみに2つのゲームを知らないのですが、前者は青鬼、後者はチェスのようなイメージですか?(そっちのほうがわかりにくかったらごめんなさい(´・ω・`))
akabee

2017/06/04 05:55

はい、そのイメージで合っています。
chankane

2017/06/04 06:00

ではキャラクターに座標を持たせるようにしたいと思います。 参考になりました。ありがとうございます(*^^)v
guest

0

具体的には、今回のようなマップ性のゲームで、キャラクターなどのオブジェクトが自身の座標をもつことに違和感があるというものです。

その違和感は正しいです。
「キャラクターなどのオブジェクトは自身の座標を持たない」方が多くの場合良い選択となります。

メリットは”オブジェクトの座標情報がマップに集約されるので設計がシンプルになる”ことです。
デメリットもあります。”実装手順が多くなる”や”処理速度”といったことです。
現段階ではデメリットを気にする必要はないでしょう。
デメリットは最適化の問題なので、問題が現実に発生したらその問題に合わせて最適化すれば良いです。

今回の問題に対して、私なら下記のようにします。

・マップは全オブジェクトの座標を管理(「今のところ考えられる方法」に記載のされた内容)
・キャラクタ(オブジェクト)は自分を管理しているマップへの参照をもつ(これは必然)

この方法には賛否が出ると思います。また、実装すると非効率だと感じることでしょう。
キャラクタが自身の現在座標を知るだけでループで探すことになるからです。
キャラクタが自身の座標を持っていればループは必要なくなります。
ですが、オブジェクトに座標を持たせてしまうと
マップとの二重管理を発端に随所に座標やオブジェクトの捜索をする処理が必要になってきます。
定石や上手い管理の仕方がない限り、オブジェクト捜索と座標計算の化け物になってしまいます。
なので、冒頭の回答となります。

蛇足ですが
現実世界もそうです。私たちは自分がどこにいるのかその座標を自分自身では知りません。
自分自身の外、つまりマップが教えてくれます。最も端的な例はGPSです。風景も例になります。
移動に関しても、前に進む時、私たちは意思は持つものの、前に壁があれば進めません。
壁は自分自身の外、マップに存在します。私たちは目を通してそれを認識します。
キャラクタ(=私たち)は、常にマップから情報を得て行動や判断をしているのです。
この点からも、自身の座標を持たないという選択は自然なことと言えます。

投稿2017/06/04 06:42

Hiroshi-Aoki

総合スコア804

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

chankane

2017/06/04 07:42

こんにちは、ご回答ありがとうございました。否の意見も欲しかったので大変ありがたいです! >ですが、オブジェクトに座標を持たせてしまうと マップとの二重管理を発端に随所に座標やオブジェクトの捜索をする処理が必要になってきます。 定石や上手い管理の仕方がない限り、オブジェクト捜索と座標計算の化け物になってしまいます。 以上の文章をもう少し噛み砕いて説明してくださると嬉しいです 日本語力がなくて申し訳ありませんm(._.)m
Hiroshi-Aoki

2017/06/04 13:55

新たな疑問を生んでしまいましたね。 少し進んだ段階でのお話なので難しいかもしれません。 作っていく中で私の言っていることが目の前に現れると思うので楽しみにしてください。 一言でいうと「オブジェクトに座標を持たせると、座標管理が大変になる。やる気を失うほどに」ということです。 マップとの二重管理というのは、座標をキャラクタとマップがそれぞれ持つということを指します。 キャラクタが自身の座標を知りたい場面があれば、マップのその座標には何が居るかを知りたい画面もあります。 キャラクタ自身が座標を持つ主な目的は自身の座標を簡単に知りたいからですが、マップにおいても同じことが起き、そのためマップ側でも座標情報とその座標に何が居るかを保持することになります。ここで発生するのが「キャラクタの座標をキャラクタ自身とマップがそれぞれに持つ」という1つの情報を2つの場所で持つという二重管理の状況です。キャラクタの座標(x,y)は一つなのですが、二か所で保持しているため違う座標を指してしまう可能性が生まれてしまいます。 座標に関する処理が必要となる場面について説明します。 キャラクタはキャラクタの座標によると(1,2)の座標にいるはずが、マップ上の管理では(4,5)の位置にいるとなってしまうようなことが起きます。これを起こさないようにするには設計や実装面で注意しなければなりません。キャラクタの座標が変化した場合にはマップ側の管理するキャラクタの座標情報も変更してあげるような同値となるような処理が必要になります。 同値処理を要らないようにするには、マップ側で管理することをやめるのが手っ取り早いのですが、マップ側での管理を行わないとキャラクタの前後左右に何があるのかの管理が難しくなります。キャラクタ以外のオブジェクトで自律的に動くもの(敵キャラ等)がいると難易度が高くなります。処理も複雑になってきます。マップ側で座標を管理する仕組みは欲しくなります。 マップ側で座標を管理すると前述の問題があるので、キャラクタをマップ側から探さなければなりません。マップ側からキャラクタを捜索するということです。捜索する時、キャラクタがもつ座標情報が頼りになりますが、同値処理に問題があれば合致しないことが起こり得ます。 慣れないうちはエラーに苦しみます。エラーを回避するための仕組みを入れたりすることになることが多く、座標計算やオブジェクトの確認処理が多くなり、気づけばそれら処理が随所に埋め込まれたプログラム(=化け物)になってしまっているといことを言いました。 実はキャラクタ側に自身の座標を持たせてもあまりメリットはありません。 キャラクタが自身の座標を知っておきたい主な理由は「簡単に現在位置を知りたい」ですが、それ以外には意味を持ちません。キャラクタがアクションするにあたり、キャラクタ周囲の情報が必要になったとたんにマップの情報を見ることになるからです。 この点はakabeeさんも「キャラクターの周りに何があるかは別管理に…」や「周囲に…」と回答されている部分に重なります。 私は「それをやるのがマップですよ。だったらキャラクタもマップに管理させましょう。」と言っています。 キャラクタが現在座標はマップ側の管理テーブル(=配列)をループを使って自分自身を格納している座標(x,y)を探すことで得られます。ということは前後左右のオブジェクトも、その座標から導き出し取得することができます。 ドラクエ(青鬼)もファイヤーエンブレム(チェス)もキャラクタ自身が行うアクションの本質に違いはありませんし、マップから情報を得て判断すると考えることで処理内容は同じことになります。 長くなってしまいましたし、具体的に伝えるのにも長くなりそうなのでひとまずここまで。 私としてはマップで座標を管理させた方が総合的には汎用性がある楽な仕組みになるものと思います。 マップだけで座標管理を行うプログラムを試作してみて、違いを感じてみると良いでしょう。
chankane

2017/06/05 08:40

まず初めに、中間テストの関係で返信が遅くなりました。申し訳ありません。 ご回答を読ませていただく限り、なにか苦い経験がお有りなのですね?この質問において、あなたのような方の意見はとても参考になります。 さて、簡単にまとめると 1. オブジェクトに座標を持たせると、位置情報が2重になり管理が大変になる 2. だったら統一してやれ!(オブジェクト側で座標を管理すると楽ではないので、マップ側一択) といった感じに解釈しています。 本当の意味で「あ~!わかった!」となりたいため、オブジェクトで座標を管理するパターンと、マップで座標を管理するパターンの2つを用意して、その違いをかみしめたいと思います。また正直ご回答の内容が全て理解できているわけではありません。だから、本当の意味でメリットデメリットが理解できた時にまたこの文章を読み返したいと思います。 たいへん丁寧な回答ありがとうございます! 面白そうな方なので、勝手ながらフォローさせていただきます(*^-^*)
Hiroshi-Aoki

2017/06/05 18:08

解釈は合ってます。 中間テストとは懐かしい響き。 本当の意味で~と書いてくれているので先が楽しみです。
chankane

2017/06/09 14:30

お久しぶりです。作っていて疑問に思ったことがあります。 ・マップは全オブジェクトの座標を管理(「今のところ考えられる方法」に記載のされた内容) ・キャラクタ(オブジェクト)は自分を管理しているマップへの参照をもつ(これは必然) これはオブジェクトの二重管理になりませんか? マップの上では存在することになっているが、キャラクター側では自分を管理しているマップへの参照をもたない。逆に、マップの上では存在しないことになっているが、キャラクター側では自分を管理しているマップへの参照をもつ。 この二重管理は必然ですか?それとも私がなにか勘違いをしていますか?
Hiroshi-Aoki

2017/06/11 02:09

勘違いはされていません。指摘は合っていて二重管理になっています。 この点に気づかれたということは二重管理について本質は伝わったのだと感じています。 質問に回答します。 「必然」と書いたのには私の経験が含まれています。言い換えると「いろいろとやろうとすると、結果、キャラクタがマップの情報を持つことになる。その時キャラクタが持つマップの情報はマップへの参照。」になります。これを端的に「必然」と書きました。 コメントで書いてくださった「マップの上では存在することになっているが~キャラクター側では自分を管理しているマップへの参照をもつ。」は、二重管理をすることで発生する問題点であり、防止すべき状態を示すものです。 二重管理の問題点をお伝えしましたが、二重管理は必要になります。 私が今回伝えたいのは「二重管理は必要。どのレベル(マップ/座標etc)で二重管理するかがポイント」ということです。 マップ制ゲームとして下記の処理内容・条件・実装パターンでどうなるか取り組んでみると意味が伝わると思います。 【処理内容】 ・キャラクタを前後左右に移動させる 【条件】 ・前後左右の移動処理はキャラクタ側に実装する ・マップには障害物(キャラクタがそこには移動できない)がある ・キャラクタは複数いる(プレイヤーキャラクタの他、敵キャラクターもいる) ・マップが複数ある 【実装パターン】 ・キャラクタに座標を持たせて、マップではキャラクタの座標を管理しない ・キャラクタにマップへの参照を持たせて、マップてキャラクタの座標を管理する ・キャラクタには座標もマップへの参照も持たせず、マップでキャラクタの座標を管理する
chankane

2017/06/11 02:26

やはり必然ですか...。となれば上記の自分のコメントみたいな状況にはならないようにしないといけませんね! なんだかおもしろそうです。少し時間がかかるかもしれませんが3パターン実装してみたいと思います。 それでもわからなかったらまた質問します。 ご回答ありがとうございました!(^^)!
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問