iPhoneXが発売され、いわゆるアスペクト比2:1の端末が増えてきました
AndroidでもGaraxy S8、LG G8などが2:1に近いアスペクト比となっており、GoogleもAndroidアプリ開発者に対し、アスペクト比2:1以上の画面に対応することを促しています
例えば横スクロールのアクションゲームで、タブレット端末でよくある4:3の端末と
2:1の両対応を単純にしようとするとこのような画面になってしまいます
これだとステージの先、見えている敵キャラが違うためゲームの難易度に大きな違いが生じてしまいます
4:3のアスペクト比を基本にして、それよりも横長なら両端黒帯ってのは簡単な対応ですが、それは避けたいところですので、いくつか対応案を考えてみました
1つ目は2:1の横幅を基本として天井(空)の拡縮で対応する横幅固定の下寄せ
こんな感じ
見た目にかなり差が出ますが、見えているステージの範囲は同じになるので難易度に違いは出なくなるかと
2つ目は横スクロールでも天井がある場合や、シューティングの場合ステージの縦幅を変えるのは都合が悪い時に対応する横幅固定の真ん中寄せ
横幅は2:1を基本にして上下の地面と天井部分を拡縮します
ものによっては地面と天井の比率を変えてもよいかと思います
3つ目は2:1端末が増えてきたとはいえ、主流はまだまだ16:9のワイドなので、それを基本として調整するバランス型
横幅は16:9のワイドを基本にして、2:1端末では影響が出にくい自キャラの後ろ部分を拡縮してやります
4:3では上部分を拡縮して対応
以上3つの手法を紹介しましたが、やり方はまだまだあると思います
要はメインとなるステージの縦と横幅で変えられないところ、アスペクト比が変えられるのかというところを決めて、基本とする端末のアスペクト比からサイズ差を吸収する調整枠を決定するという流れになるかと思います
2017年11月21日火曜日
2014年2月4日火曜日
新作Androidアプリ開発 画面設計編
前回紹介した新作アプリについていろいろと書いていこうと思います
なにはともあれまずは画面設計
こんな感じ、中央バスケットコート部分はアスペクト固定の縦100%でセット
端末による画面サイズの違いを可変部分で吸収します
コート部分左上を原点(0,0)としてボールやゴールを扱うことにする
タッチや描画と実座標を合わせるためCourtクラスをつくる
こんな感じでSIZEに実座標の大きさをいれてコンストラクタのRect r に描画するピクセル単位のサイズをセットする
あとはgetDPlotメソッドのように、実座標の位置を与えて描画位置を返すメソッドを作成して、実座標から描画位置を取得してボールの描画などを行います
なにはともあれまずは画面設計
こんな感じ、中央バスケットコート部分はアスペクト固定の縦100%でセット
端末による画面サイズの違いを可変部分で吸収します
コート部分左上を原点(0,0)としてボールやゴールを扱うことにする
タッチや描画と実座標を合わせるためCourtクラスをつくる
public class Court {
final public Rect SIZE = new Rect(0, 0, 15000, 12750); //(mm)
final public int BALL_R = 122;
final public int RING_R = 230;
final public Point RING_CENTER = new Point(7500, 1790);
public static Rect view;
public Court(Rect r) {
view = r;
}
public Point getDPlot(Point point) {
int x = view.left + ((point.x * view.width()) / SIZE.width());
int y = view.top + ((point.y * view.height()) / SIZE.height());
return new Point(x, y);
}
}
こんな感じでSIZEに実座標の大きさをいれてコンストラクタのRect r に描画するピクセル単位のサイズをセットする
あとはgetDPlotメソッドのように、実座標の位置を与えて描画位置を返すメソッドを作成して、実座標から描画位置を取得してボールの描画などを行います
2013年5月16日木曜日
SurfaceViewでの複数解像度に対応した画面設計
Androidでは多様な端末が存在しており、解像度も縦横比も異なるさまざまな画面に対応しなければなりません。
これに対処するには用途に応じて画面に対する比率で大きさを決める部分、縦横比を固定する部分、引き伸ばしてもいい部分というように分割して考える必要があります。
例えば拙作のFactoryではこのような分割をして画面を設計しました。
画面に対して上下を55:45に分けて液晶描画とボタン描画部にとっています。
上部分の液晶表示部は横を全体widthの90%としていますが、縦横比は変えたくない部分なので縦はそれに対しての77%にしています。
この設計でいくとXperia Z、LG L-06D、初代Xperia SO-01Bなどでは以下のような実寸になります。
改めて計算してみると数あるAndroidスマートフォンの中でも、おそらく最も縦横比の縦が短いと思われるJOJO携帯ことLG L-06Dですが、上下分割の上の部分494pxに対して液晶表示枠の縦が768×0.9.×0.77=532pxになっていてはみ出してしまっています。
今頃気づいたんですがこれは完全に設計ミスですね…
LG L-06Dユーザーの方ごめんなさい。
これに対処するには用途に応じて画面に対する比率で大きさを決める部分、縦横比を固定する部分、引き伸ばしてもいい部分というように分割して考える必要があります。
例えば拙作のFactoryではこのような分割をして画面を設計しました。
画面に対して上下を55:45に分けて液晶描画とボタン描画部にとっています。
上部分の液晶表示部は横を全体widthの90%としていますが、縦横比は変えたくない部分なので縦はそれに対しての77%にしています。
この設計でいくとXperia Z、LG L-06D、初代Xperia SO-01Bなどでは以下のような実寸になります。
改めて計算してみると数あるAndroidスマートフォンの中でも、おそらく最も縦横比の縦が短いと思われるJOJO携帯ことLG L-06Dですが、上下分割の上の部分494pxに対して液晶表示枠の縦が768×0.9.×0.77=532pxになっていてはみ出してしまっています。
今頃気づいたんですがこれは完全に設計ミスですね…
LG L-06Dユーザーの方ごめんなさい。
2013年4月18日木曜日
Androidアプリの設計
さて、作りたいアプリが決まったら設計に入ります。
これは人によって違うでしょうが、私の場合アプリに必要な画面を紙に全部書いていきます。
規模によっても違いますが、いままで作ってきたのではこれがそのまま設計書になります。
今回のPhotoRouletteの場合下のような感じ、大変汚い殴り書きで恥ずかしい…
画面を書いたらその中で必要な機能を書いておきます。
そのあとはこの中で必要になりそうなクラスで主要なデータになるやつと複雑なやつは
大雑把にクラス設計をしておきます。
今回の場合はルーレットのデータになるクラスを作りました。
それほど複雑なアプリでなければこれで私の場合これで設計完了です。
これは人によって違うでしょうが、私の場合アプリに必要な画面を紙に全部書いていきます。
規模によっても違いますが、いままで作ってきたのではこれがそのまま設計書になります。
今回のPhotoRouletteの場合下のような感じ、大変汚い殴り書きで恥ずかしい…
画面を書いたらその中で必要な機能を書いておきます。
そのあとはこの中で必要になりそうなクラスで主要なデータになるやつと複雑なやつは
大雑把にクラス設計をしておきます。
今回の場合はルーレットのデータになるクラスを作りました。
public class Roulette {
String name = "";
Date date = null;
int count = 0;
Bitmap image = null;
ArrayList<Bitmap> images;
}
それほど複雑なアプリでなければこれで私の場合これで設計完了です。
登録:
投稿 (Atom)







