まるまるこふこふ

数々の次元が崩壊し、全ての生命が塵と化すのを見てきた。私ほどの闇の心の持ち主でも、そこには何の喜びも無かった。

ゲームエンジン AIMS を触る 1

こんにちは、さいです。
同人ゲームを作らせて頂く機会を得たので、ゲームエンジンを使って
ゲームを作ろうと思います。

今回ご紹介させていただくのは、「ゲームエンジン AIMS」です。

AIMS

AIMS は 2Dのアクション主体のゲームを作成するためのエンジンです。
特徴的なのは、Lua言語でゲームロジックを記述するところです。

D.N.A.Softwaresさんが開発しています。
面白いのは、商業で使われているゲームエンジンではないんですね。
D.N.A.Softwares さんは同人サークルです。

とはいえ、長く歴史のある同人サークルさんで、
AIMS を利用して、これまでたくさんのゲームをリリースされていらっしゃいます。

公式サイトから引用させていただきますが、AIMSが得意とするジャンルは以下です

・2Dゲーム全般
シューティングゲーム
アクションゲーム
テーブルゲーム
etc...

他にもたくさんの2Dゲームを作ることができます。詳細は公式で

またドキュメント類もしっかりしてて、公式にリファレンスがあるのはもちろん、
ガイドブックも pdf で販売されております(2016/06現在)

gumroad.com

なぜ？

世間ではゲームエンジンといえば、Unity とか UE4 がメジャーなようですが、
なぜ AIMS を選択するのか？

  1. 技術的興味
    C++ のようなコンパイル型言語から、Luaのようなスクリプトを動的ロードすることに興味があり、 まずは Lua を触ってみたかった。

  2. 開発環境構築の容易さ
    Unity や UE4 の開発環境構築は大変です。エディタも 使用できるエディタは実質限られてしまいます。 (※僕は触ったことがないため、完全に第一印象だけで 喋ってるのでツッコミ希望です)
    おまけに僕はGUIが苦手です。やりたいことが全てコードを通して命令できることを望みます。 AIMS は Lua で記述できます。Lua は vim で編集できます。 ちょっと工夫すれば、Mac 上で動作確認もできます(これについては別の機会に書きます) いわゆるオーソドックスな webプログラミングの開発環境を流用できそうなところが魅力的でした。

  3. 薄い
    AIMS はフルスタックにゲームエンジンとしての機能を 何もかも揃えているわけではありません。 デメリットのように見えて、それは覚えるべきAPIが少ない点で、 学習コストが低いというメリットになります。

リンク

AIMS Headquarters

D.N.A. Softwares

次回

Mac + vim での開発環境構築について書ければと思います。

sails で migrate されるテーブルのカラムの型定義

さいです。

サーバーサイドのフルスタックMVCフレームワークの sails.js を触ってます。
フルスタックなので migrate 機能があります。
モデル定義するだけで、アプリケーション起動時に自動でテーブル作ってくれるヤツですね。

sail.js のモデルは Waterline なのですが、どのストレージでも同じ型定義で記載できるよう、
integer とか string とかそんな型定義しかありません。

具体的に MySQL でどんな型になるんや！となったので調べました。

Watarline の型定義 -> MySQLの型定義の変換は sails-mysqlモジュールの
lib/sql.js にあります。

v0.12.1 時点だと以下のようになってるっぽいです。(大文字小文字問わない)

type size MySQL上の型
string N(省略した場合 255) varchar(N)
text LONGTEXT
array LONGTEXT
json LONGTEXT
mediumtext mediumtext
longtext longtext
boolean BOOL
integer 8 TINYINT
integer 16 SMALLINT
integer 32(デフォルトサイズ) INT
integer 64 BIGINT
float FLOAT
double FLOAT
decimal DECIMAL
date DATE
datetime DATETIME
time TIME
binary BLOB

ざっと見たけど、 unsigned を数値に設定する方法はないっぽかった。。。

同人誌即売会向けレジアプリ「レジプラ」を例大祭13で使用しました

f:id:sairoutine:20160508213459j:plain

こんにちは、さいです。

わたくし、趣味事として同人サークルを営んでおり、 東方Project や アイドルマスター等のキャラクターの グッズを制作して、同人誌即売会で販売しております。

https://sai-chan.com/rubberstrap.html

2016/05/08 に開催された 東方Projectオンリー同人誌即売会 博麗神社例大祭においても サークル参加してグッズを頒布させていただきました。

ところで、Twitter レジプラさんの下記のようなツイートを拝見しまして、 モニター登録をお願いしたところ、例大祭で使わせて頂けることになりました。

こんな感じでレジプラ土台と、さらにアプリインストール済みのiPhoneを貸して頂けました。

f:id:sairoutine:20160514213839j:plain

土台の中はこんな感じ。スイッチを入れるとコードレスで、 レジプラ土台とiPhone が接続されます。便利！

f:id:sairoutine:20160514214141j:plain

レジプラの商品登録画面

f:id:sairoutine:20160514214817p:plain

商品一覧画面

f:id:sairoutine:20160514214833p:plain

４つ目以降の商品はスライドさせると出てきます

f:id:sairoutine:20160514214902p:plain

お会計はこんな感じ。お釣りの額も自動で表示してくれるのがイカス！

f:id:sairoutine:20160514214913p:plain

そんな感じで、会場ではこんな感じで置いておりました。

f:id:sairoutine:20160508093936j:plain

弊サークルの名物、机を寂しく見せないために とりあえずグッズを並べるの図。

f:id:sairoutine:20160508093929j:plain

おかげさまでたくさんの方に足を止めて頂き、 盛況に終わりました！

レジプラさん、モニターとして使わせて頂きありがとうございました！ 正式に販売される日を楽しみにしております！

f:id:sairoutine:20160508213459j:plain

当日、胸に貼ってたサークル参加証。 サークル参加証の入ったかばんを電車に忘れて、 再発行してもらうアホっぷりだった……

MySQL サーバーを再起動するとAUTO_INCREMENT の値が戻る

InnoDB では AUTO_INCREMENT のカウンタはメモリ上に保持します。

14.6.5.1 従来の InnoDB の自動インクリメントロック https://dev.mysql.com/doc/refman/5.6/ja/innodb-auto-increment-traditional.html

InnoDB テーブルに AUTO_INCREMENT カラムを指定すると、InnoDB データディクショナリ内のテーブルハンドルに、カラムに新しい値を割り当てる際に使用される自動インクリメントカウンタと呼ばれる特別なカウンタが含まれます。このカウンタは、ディスク上には格納されず、メインメモリー内にのみ格納されます。

InnoDB では、ai_col という名前の AUTO_INCREMENT カラムを含むテーブル t に自動インクリメントカウンタを初期化するために、次のようなアルゴリズムが使用されます。サーバーの起動のあとで、テーブル t への最初の挿入をするために、InnoDB は次のステートメントと同等なものを実行します。

SELECT MAX(ai_col) FROM t FOR UPDATE;

何が問題かというと、最新のレコードを削除して MySQL サーバーを再起動すると AUTO_INCREMENT の値が巻き戻る。

>select * from test;

1
2
3
4
5

>show create table test;
CREATE TABLE `test` (
  `id` int(10) NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8;

>delete from test where id = 5;
>show create table test;
CREATE TABLE `test` (
  `id` int(10) NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8;

ここでMySQLを再起動

>show create table test;
CREATE TABLE `test` (
  `id` int(10) NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8;

まあこのように SELECT MAX(id) FROM test FOR UPDATE; の値に巻き戻る。 AUTO_INCREMENTした値が一意であることを見越して、
他のテーブルの外部キーにしてたりすると、整合性が取れなくなってしまう。

対策としては
・外部キー制約入れる
・AUTO_INCREMENTに頼らず、別に採番テーブルを用意する
・論理削除してレコードを delete しない(!)

toho-like-js のソースコードを読む 4

進捗

StageState を読んだ

わかったこと

1.ビット演算子でフラグ管理するの便利(キーの押下、SEの再生等)
2. 画面各要素のマネージャーインスタンス初期化時に、initDrawerを呼んでる
3.キー押下は一旦 KeyFlagQueue に格納され、キュー先頭から使用されていく

StageStateが持つ各シーン

ShootingState
ゲーム画面
TalkState
ボスキャラとの会話シーン
ClearState
ステージクリア
GameOverState
ゲームオーバー

画面の各要素

BackGround
Fighter
FighterOption
Enemy
Boss
Effect
Bullet
Bomb
EnemyBullet
Item
SpellCard

各要素毎に下記のクラスが存在する

Drawer
Factory
Manager
View
Element
FreeList

わからんこと

1.lag の役割(恐らく multiplay 用だと思う)
2.KeyFlagQueue クラスの必要性(恐らく通信プレイの同期のため)
3.viewScore で本来の score から表示の際に調整入れてる理由