Intellij IDEAで簡単WEB画面作成
現在ちょっとしたWEBサービスを作っているのですが、
そのWEB画面をIntellij IDEAを使ったら思っていたより楽だったので紹介したいと思います。
IDEを使うまでもないって思われるかもしれませんが、便利なものは使おうというスタンスです☆
Step1.必要なものをそろえる
- 今回はIntellij IDEA12を使います。WebStormでも同じことができます。持ってない方はこちらから購入できます。
- Google Chromeの最新版
- Sassをインストール（インストール方法はググってね。）
Step2.Intellij IDEAにプラグインをインストールする
今回使うプラグインは下記の2つです。Preferencesからpluginを選択してインストールしてください。
Step3.必要な物はそろった！あとは書くだけ！
プロジェクトを新規に作成して、index.htmlとcss、scssフォルダーを作成します。
scssフォルダー内にstyle.scssというファイルを作成するとscssをFlie Watchersで監視するか尋ねられるので、add wathcerをクリックして監視対象にしてください。
PreferencesからFile Wachersを選択すると追加したscssの設定が確認できるので、cssの出力先をcssフォルダーになるように引数を変更しましょう。
試しにこんな感じで書いてみます。
するとcssフォルダー内にstyle.cssが作成されていることが確認できます。
このcssはscssに変更があるたびに自動更新されるので、開発中はcssを意識する必要ありません。
次にViewのLiveEditにチェックが入っていることを確認してindex.htmlをブラウザで開きます。
この状態でindex.htmlやstyle.scssに変更があると自動的にファイルが読み込まれブラウザに反映されます。
いちいち変更したらブラウザを更新するって手間が省けるので便利です。
以上で簡単ですがWEB画面作成のお話は終わりです。
ちょっとしたページを作成したいってときはお試しください。
つかったサンプルはGithubに上げました。
【cocos2d-x】CCLabelBMFontでADVゲーム風の文字送りを実現する
文字を少しずつ表示していく表現はゲームでよく使われていますね。
ADVゲームに限らず、会話パート的な画面を実装する場面もあるかと思います。
今回はCCLabelBMFontの特性を利用して簡単に文字送りを行う方法を紹介します。
一般的には表示する文字列のうち、文字送り途中の文字列を管理するテキストバッファ
を用意して、全表示状態の文字列から少しずつ切り出してテキストバッファに反映し、
描画するという流れだと思います。
しかし今回紹介するのはそのやり方ではありません。
話は変わりますがCCLabelBMFontの子要素は1文字毎のCCSpriteの配列となっており、下記の図のように
各Spriteにアクセスできます。
今回はこの仕組みを利用し、はじめにCCLabelBMFont内の全Spriteを非表示状態にしておき、1文字ずつSpriteにアクセスして表示状態にすることで文字送り表現を実現してみます。
その他にも各文字にCCActionを割り当てて1文字毎に別々のアニメーションをさせてみたりと
工夫の余地がありそうです。
CCLabelBMFontに文字送りと、特定の文字列の文字色・文字サイズを変更可能な機能を
追加してみました。
gear1554/CCLabelAttributedBMFontTest · GitHub 
おまけに猫とニャーニャーに該当するSpriteの色と文字サイズを変更しています。
使い方、仕組みは下記の通りです。
CCLabelAttributedBMFontの設定、使い方
これで簡易的な会話パートの実装も効率よく進められそうです。
BlueStacks App Playerで快適なAndroidアプリ開発 Part.1
皆さんはAndroidアプリ開発の際、何を使って動作確認を行っていますか？
SDK付属のAndroidエミュレータは重くて使いたくないですし、実機でも良いですが開発時はiOSシミュレータのようにサクッと動かしたいですよね。
Intel HAXMとx86イメージでAndroidエミュレータの動作を高速化させることは可能ですが、Google MapsなどGoogle Play Sericeを使ったアプリが動きません……（方法が無いわけではありませんが不安定です）
そこでBlueStacks App Player（以下BlueStacks）というAndroidエミュレータを使いましょう。
どれだけ速いのか。
AnTuTu Benchmarkで私の持っている端末（203SH）と比較してみると、、
203SH: 17305
BlueStacks: 38436
なんと2倍以上スコア差が出ました。（というか203SHが思ったより低くてショック。。）
性能もそうですが、実機ではないためネットワーク速度も早く非常に便利です。
また、課金処理等も問題なく行うことができますし、Unityのアプリなども動作します。
BlueStacks以外ではGenymotionというVirtualBox上で動作するエミュレータがあり、こちらも非常に高速ですが、やや導入が面倒なのと動作が少し不安定な印象です。
次回は開発時に行うと便利な設定等を紹介していきます。 目指せ開発効率10倍！
Photoshop CC 写真家向けプログラムが3月31日まで延長
再び、月額1,000円のキャンペーンが延長したようです。
また、「CS3以降の製品所有者」という条件が無くなり誰でも購入することができます。
去年も同様に期間限定で誰でも購入できる状態でしたが、見逃していた方（私）には朗報です。
エンジニアとしては月額1,000円でも割高な感じがしますが、Windows・Macの両方で使えるのは良いですね。
Photoshop 写真家向けプログラム
Photoshop CCとLightroom 5に加え20GBのクラウドストレージが月額1,000円で利用できるというキャンペーンで、「Photoshop 写真業界向けプログラム」として去年からスタートし、現在は「Photoshop 写真家向けプログラム」という名称になっている。
Cocos2d-xにて画面間で共有できるレイヤーを活用する方法
Cocos2d-xを触っていて
- 通知系のポップアップを表示させた後に消えるような処理をやりたいけど、画面遷移後も一定時間は必ず表示し続けるようにしたい(PS3のゲームでトロフィー獲得時に出現する通知みたいな感じのやつ)
- 画面の左上に常にデバッグ用に各種パラメータを表示するようにしたい
これをやろうとしてハマった内容をメモしておきます。
これらの処理を正攻法で実現しようとすることを考える。
replaceScene()、pushScene()で画面遷移すると、当然ながら画面遷移先で前画面の内容が消えてしまいます。pushScene()の場合は、前画面の内容は消えませんが、遷移先の画面が被さる形になるため、表示内容的には画面から消えてしまいますね。
通知のポップアップとデバッグ出力系のレイアウトは、画面遷移時に消えてもらっては困るのです。
画面遷移直前に共有したい画面を取り出して次画面に引き渡す案も考えましたが、影響範囲が大きくなってしまうので断念しました。
試行錯誤した結果、こんな感じで実現できました。
// AppDelegate.cpp
bool AppDelegate::applicationDidFinishLaunching() {
/**
省略
*/ // 共有レイヤー追加 CCDirector::sharedDirector()->setNotificationNode(CCNode::create());
// 共有レイヤー内にデバッグ用レイヤー追加 DebugLayer *debugLayer = DebugLayer::create(); debugLayer->setTag(999); CCDirector::sharedDirector()->getNotificationNode()->addChild((CCNode*)debugLayer); debugLayer->onEnter();
}
各画面からデバッグ用レイヤーへアクセスする方法。
CCDirector::sharedDirector()->getNotificationNode()->getChildByTag(999); // 予め指定したタグ番号で参照してみる
本来の想定される使われ方とは違うのかもしれませんが、CCDirectorクラス内のm_pNotificationNodeというCCLayer*型のメンバを利用することで実現できました。
cocos2d-xでSTGを作るために(当たり判定編)
始めてブログというものを書いてみました。gear1554です。
このブログには複数人の中の人が居るのですが、とりあえず私が1番最初の更新かもしれません。
最近coccos2d-xが流行り始めてきたので、早速ゲームを作ってみようと実践している方は多いはず。
実装のセオリーがそこそこ確立しているゲームの定番？といえばシューティングゲーム(STG)かアドベンチャーゲーム(ADV)ですよね。
今回はcocos2d-xでSTGを作る場合の当たり判定について書きたいと思います。
シューティングゲームでここ数年(でもないかも)多いのは縦スクロールの弾幕STGでしょうか。
主に敵機の弾が大量に飛んできて、それを避けるアレです。
ゲーム画面内のオブジェクト(自機、敵機、弾)の数が多ければ多いほど、オブジェクト同士が当たっているかを判定する処理が行われる回数は増えていきます。
1番実装が簡単なのが、総当たりで当たっているかをチェックする方法ですが、処理のコストは1番大きいです。forループをぶん回すことになるわけですから・・・
下記のようにゲーム画面をグリッド状にグループ分けして、グループ内同士だけで判定する方法というのがあり、これをはじめて知った時は目から鱗でした。
シューティングゲームにおける弾の空間分割 - 当たり判定 - tomoemonの日記
この空間グループ内同士で当たり判定を調べる手法を
cocos2d-xで利用可能なクラスとして作成してみました。
GitHubで公開しているCollisionDetectionクラスはCCNodeが入っているCCArrayを渡すと上記の空間分割の手法で当たり判定をやってくれます。
gear1554/CollisionDetectionTest · GitHub
CollisionDetectionTest - YouTube
動画では実際にどんな感じで空間の分割が行われ、判定回数がどうなっているかを視覚化
するためにグリッド状の格子と、空間内のオブジェクト数を表示しています。
左上の緑のデバッグ情報は下記の情報を表示しています。
- SpaceLevel:空間の分割レベル
- CheckHitCount:1フレームに当たり判定のチェックを行った回数
- ScanSpaceCount:1フレームに空間の走査を行った回数(空間の分割レベルが上がるにつれ増大)
- HitObjectPair:当たっているオブジェクトのペアの数
- GameObjectCount:画面上に表示されているオブジェクトの数
- DelayTime:1フレームあたりの処理にかかった所用時間(秒)
グリッド状の格子とラベルの描画のコストが思った以上に大きく、
FPSが30前後に見えますが、グリッドとラベルの表示を止めると60FPS出ていました。
グリッドはオフスクリーンのレンダリング、ラベルはビットマップフォントを使いましたが、描画に要する処理コストはやっぱり高い・・・
総当たりの判定の場合は、70個前後のオブジェクトの計算に1フレームあたり約2000回、
空間分割(84分割)による判定の場合は1フレームあたり約400~600回。
少なくとも総当たりの判定よりは判定回数を抑えられていました。
空間の分割数によってかなり計算回数が変わってきます。
空間分割レベル0(総当たり)
空間分割レベル1
空間分割レベル2
空間分割レベル3
空間分割レベル4
空間分割レベル4にもなると、空間を走査するコストも増大するので、空間分割レベル2〜3辺りが最適な感じ
Box2Dを使って当たり判定を実装したこともありましたが、STGで貫通弾をやろうとした際にオブジェクト同士が必要以上に重なると極端に処理が重くなってしまい、断念しました。複雑な図形の判定が簡単に出来るのは非常に魅力的でしたが・・・
STGに限らず、アクションゲーム等の当たり判定を行うゲームにも流用してみようと思います。
