CakePHPとLaravelの比較2018

経緯

2016年にこんなCakePHPとLaravelの比較記事を書いた。

CakePHPとLaravelの使い道

また、こちらの記事もCakePHPのみの記事だが完全にLaravelとの比較を意識していた。

CakePHP3の優位性を色々

この頃は正直CakePHPびいきだったが、時も流れ色々と状況や考え方も変わってきたので改めて考察してみた。(人によってはなんで今さらCakeとLaravelの比較なんてやってんだ、と思うかもしれないが)

情報量

検索にしても日本語の情報が非常に少ない気がするので本当に人気があるのかと思ってしまう。

当時Laravelについては上記のように書いていた。

今はどちらも十分。CakePHP3とか、Laravel5とかで検索すれば紛らわしい情報も減るし、困ったらドキュメント見れば大体分かったりする。

ヘルパー

LaravelのHtml, Formヘルパーはなんとなく不足している点が多いような気がする。 実際使ってない人もいるようだ。 radioボタン群すらメソッド一つで作れないとは。

当時上記のように書いていたとおり、FormヘルパーはやっぱCakeの方が楽な気がする。とはいえそんな細かく気にするところでもないかなという気はする。

設定

Laravelは設定量が多い。 パーツを追加する度にCakeだったらこんな設定しなくてもすぐ動かせるのに…。 と思いながら設定をしなければならない。 自由度が高いといえばそうなのかもしれないが、そんな自由度を得てまで時間をかけて開発したいのか、という疑問が湧いてくる。

これ多分Facadeの事を言ってたような気がする。Facadeを自分で作るのは確かに面倒だが、これはテストのやりやすさにも繋がるように便利に作られてるものだし、今となってはそんな気にするようなものじゃないと思う。

でもまあCakeはヘルパーやコンポーネント追加していくだけだからほんとに楽ではある。

あとは

ルーティングなんて設定しない

というのも書かれているが、正直ルーティングを設定するのはどのフレームワークでもあたりまえの事なのでこれも気にするようなことじゃないと思う。

とはいえ設定しなくても動くCakeはほんとに楽なのは楽。ただ、ルーティングを設定することでresourcesの恩恵を受けられコードもシンプルになるし、メリットも大きい。

CakePHPがまずいのは、bakeの自動生成がresources形式になっていないことだ。これがデフォルトでできたらかなり良い。

DebugKit

これはCakeの圧勝に変わりはない。

モデル

Cakeのモデルはほんとに便利。Laravelでも特に不満はないが、Queryがモデルに属しておらずメソッド追加などが出来ないのがちょっと不満。(一応設定すればできるみたいだが)

ただCakeのバリデーションはコードが非常に長い。これはなんとかならないかな。

モデルは一長一短な気がする。

マイグレーション

これも自動生成してくれるCakePHPを褒めちぎってたが、マイグレーションを書くのも今や当たり前の事なので普通に自分で書いている。気にするほどのことでもない。

先進性

JavaScriptについてはCakePHPは遅れている。LaravelはデフォルトでVueとかBootstrapとか使えるのでそれだけでもだいぶ優位。CakePHPはまだjQueryでいいんじゃない? みたいな空気を醸し出していて先進的じゃない。将来どうなるのか心配になる。

他にもLaravelは色々なものと連携できるようにオフィシャルパッケージも続々追加されている。HomesteadやLaradockなど、周辺の開発環境なども色々と考慮されてきている。Laravel本家と周辺共に、みんなが開発しやすい環境を作り上げていこうという活発な姿勢が見られ非常に好感が持て、将来性が期待できる。ここは完全にCakeが敗北しているところ。

というか、ここだけでも今後はLaravelだけでいいかな、という感じすらしてきてしまう。

今年の結論

趣味だったらLaravelを使うと知識や技術も広まりやすいのでおすすめ。

仕事だったら色んなフレームワーク使えた方が扱える案件や考え方の幅が広がる。ただし他言語も含め、composerのようなパッケージ管理は当たり前の様に使われている時代なので、composerを使っていないようなフレームワークはもう覚える意味はないように思う。(全て個人的な見解)

プログラミングをはじめた時のこと Windows3.1編

プログラミングをはじめたのは確か中学生か高校生の頃。

もうはっきり覚えてないけど、中学で年に数回しかなかったPCの授業でタッチタイピングをして驚かれた記憶があるので、多分中学ではやっていたんじゃないかと思う。

はじめて実家で買ったPCは富士通のFM-V。Windows3.1が入っていた。まだファイル名が8文字+拡張子だった頃。

家ではほとんどゲームばかりしていたので、その関係でゲームを作りたいと思うようになっていった。普段から頭の中で自分で作った新しいゲームの妄想などをしていた。 なのでプログラミングについてはずっと興味津々だった。

一度PCを持っている友達の家にいき、ゲームを見せてもらったことがある。しかもそれがその友達の知り合いが作ったゲームということですごく興奮したのを覚えている。 自分でも作れるようになりたかった。

とはいえまだインターネットをやってる人もあまりいなかった時代。まだパソコン通信という名前で一部の人がやっているっぽいことを雑誌か何かで知っていただけだった。 当然うちでは繋がってなかったので、今みたいにネットで調べて勉強、みたいなこともできなかった。ほんとに時間がもったいなかったなと思う。 今の若い人はとてもうらやましい。

しかしある日、とある雑誌を見つけた。なんとそれは、Visual Basicの体験版が同梱されている雑誌。 早速その雑誌を買って、自宅のPCでプログラミングをはじめた。 僕のプログラミングの第一歩。

体験版なので作ったものを保存したりができなかったのだが、それでも毎日すごく夢中になって頑張って何かを作っていた。 多分ちょっとした使い方なんかはその雑誌についていたんじゃないかと思うので、それで色々やっていたと思う。 ウィンドウの背景を青のグラデーションにするのにハマっていたので、作るアプリケーション全て背景がそんな感じになってた。

多分ゲームやプログラミングなど好きなことばかりやって引きこもっていたので、 友達も少なく、どうやって楽しく遊んでいいかもわからず、その後もしばらくは周りと馴染めずに過ごしていたけど、 こうやって楽しくプログラミングをしていた姿が今となると、 将来自分の幼い息子がこうやって何かに夢中になって励むのだろうというまだ見ぬ姿に重なり、 なんとなく誇らしく、微笑ましい気持ちになる。

その後はあまり記憶が定かではないのだが、恐らくおじいちゃんにたのんで、多分学生向けの激安VBの製品版を買ってもらったのではないかと思う。多分高校生くらい?

製品版ともなると、拡張子exeの実行ファイルを作ることができるようになる。それだけでものすごく興奮した。

色々なものを作った記憶がある。一問一答のカードリストを自分で作れるソフトとか、 スタートアップに登録してPC起動時に起動するようにして、10秒以内にパスワードを入力しないとPCをシャットダウンさせるソフトとか。 (弟に文句を言われたので外した。当時は自分の好みにPCの中を整理したかったので、他の人に使われるのが嫌だった)

このあたりも情報収集方法は本屋だけだった。毎月フリーソフトが100個とか入っているCDがついた雑誌を購入していた。 あとは立ち読みして情報収集していたんじゃないかと思う。学校帰りにいつもPCコーナーに立ち寄って本を見ていた。

そういえばふと思い出したけど、すごくハマっていたフリーソフトがあった。 ボールみたいなキャラクタを操作してハンバーガーを集めるゲームで、ステージがテキストで作られているので自分で改造できるという代物。

とても面白くて、しかもフリーソフトということで普通の人が作っているということなのでとても興奮してファンになった。 その人に憧れて、自分も何か作ると似たような体裁の説明書txtを作ったりしていた。 (ネット繋がってないから公開もできないのに) 確か1000円寄付した覚えがある。 作者名もゲーム名も思い出せない。なんだろ… (※思い出しました。FlyingJumpというゲーム)

あと雑誌で、スクリーンセーバーも作れるという方法を見たので、試して作ってみたりした。 手に入れたフリーソフトで自分の声を録音してそれをかもめの声のように高くなるよう変換し、かもめが海を飛んでいるスクリーンセーバーとかを作っていた。 春夏秋冬4パターンを作ろうと思ったが途中で飽きてやめてしまっていた気がする。

スクリーンセーバーを作れるということは描画はできるっぽいんだけど、その時ゲームを作っていたかは全然覚えていない。

そういえば、センター試験の選択問題はBASICのプログラミングがあったので、いつもそれを選んでやっていた。 普通に数学解くよりめちゃくちゃ簡単だった。

あとはすごい技術がたくさん詰まった5000円くらいの分厚い本を買ったのだが、多分他のことにハマったのか受験で忙しくなったのかは忘れたが、 ほとんど使わずじまいになってしまった。

まあそんな感じで、自分では気づいていなかったかもしれないが非常に充実した時間を過ごしていたと思う。 プログラミングが好きな人は、せっかくなのでガッツリハマって楽しんで欲しい。 この時代、やりたいことは何でも調べてできるのだから。

作ったサービスの上位互換サービスがあったことに気づいた

先日下記のようなサービスをリリースした。

torima-p.com

数年前に終了した前略プロフィールというサービスをモチーフにしたもので、 一問一答式のプロフィールを作成することが出来る。

Twitterのサービスなので容易に集客できるだろうと思っていたがそうそううまくいかず、 色々検索したりして調べていたところ、とあるものを見つけた。それが下記。

proffy.jp

完全にとりまプロフィールの上位互換。 互換とかうぬぼれにも甚だしいというか、どこを見ても全然レベルが違うほどしっかり作られている。

  • 書ける内容の種類が豊富
  • かわいらしくておしゃれ
  • コンテンツも非常に多い
  • Instagramとも連携できる
  • 公式ツイッターがおしゃれ
  • 既に集客しっかり出来てユーザーたくさんいる

どうやらとりまプロフィールリリースの1,2ヶ月くらい前にリリースされたばかりらしい。 これでここまでやってるのはすごい。どう考えても勝ち目はない。

ということで別のラインで違ったすごいアイデアが出るまではとりまプロフィールはこのまま寝かすことになった。 切ないがそれほど開発に時間をかけていないのが救い。 (ただ、おかげでどういった作り方や宣伝方法をすると良いかは非常に参考になった。)

ということでプロフィールをつくりたい人は是非Proffyを使いましょう。

WEBサービスを作りたい人への最初の1歩の勉強方法アドバイス

発端

先日プログラミング等でWEBサービスを作りたいのだがどうすればよいか、という問い合わせが来た。

Twitterの奥深く、普段誰も訪れないような僕のアカウントのところまでどうやってたどり着いたかは謎だったが、一応色々考えつつどうやって進めたり勉強したりすればよいかを回答してみた。せっかくなのでその回答を当記事としてまとめてみた。

前提

  • WEBサービスの開発を全くやったことのない方が対象
  • デザインの方をメインでやりつつ開発したいらしい
  • 僕はWEBエンジニアなのでデザイナーではない。ただ、一人で開発することが多く一応フルスタックエンジニアとしてやっているので、デザインやフロントの最低限のことくらいは分かるのではないかと思うのでそれくらいの人によるアドバイス
  • 細かい話をしすぎても役に立たなかったり、初心者ということで意味が分からなくて混乱してやる気を失ってもだめなので、最初の1歩というところに特化
  • 上記全部にあてはまる人のみなので対象となる人は少ないかも
  • ブログなのでなるべく分かりやすくするため推敲済
  • 全て僕の想像なので、最終的には各々自分で決めるべき

返答

ベースとなる考え方

  • 勉強だけよりは、何かを作りながら、わからない所を調べていく方が実践的な勉強になる
  • でも最近は開発に必要な基礎を勉強できるサービスも増えているので、完全にゼロで迷いながら進むよりも最初だけはそのあたりを参考にしてみた方が効率が良いかもしれない

最近周りでProgateがめちゃくちゃ流行っているように思う。プログラミングを勉強している人はみんなProgateをやっているんじゃないかと思うくらいProgateという文字をしょっちゅう見る。

ちらっと調べてみたが、無料プランで結構試せるみたいだし、とりあえず最初の勉強の仕方に悩んだらまずProgateの無料プランを試してみてから考えても良いんじゃないかという気がする。なので参考にProgateは教えておいた。

prog-8.com

ただ、特にがっつりおすすめしているわけではない。

というのも、僕自身が古い人間で、当時はわからないことがあったら検索しつつ試行錯誤して時間をかけて、迷いながらも熱中しつつ結果として勝手に学んでいて色々出来るようになったので、その方法が一番実践的ではあると思う。

ただし、あくまでそれは自分の好きな形なので、世の中すべての人にそんな非効率かもしれない方法をおすすめするわけにはいかない。最初から正しいか間違ってるかわからない方法で時間をかけて試行錯誤させてしまうのはとても無駄で可哀想。

そのため0からでもなんとなく概要が分かる、そんなところとしてProgateを教えた。無料コースならそんなに時間もかからないと思うので、実際にやってみてその後の進め方はまた考える形で良いと思う。 それに、「Progateで○ヶ月勉強してサービスリリースしました」みたいな人を最近良く見かける。ちゃんと学習意欲がある人はそれで作れるっぽい。

ただ、あまりハマってやりすぎるのは良くない。Progateをやっている人たちの中には、何も開発せずに無意味に何周もしてるという人もいる。それはもう覚えたことを活かすことでなく、勉強することがメインになってしまっている。それで満足であれば問題ないが、自分で開発したい、というところが目標であれば決して良いことではない。

なので最初に書いたとおり、まずはざっと概要を教えてくれるところで勉強してみて、あとは実際に何かを作りながら技術を伸ばすのがベストな形だと思う。

実際に勉強する内容と優先度

上から順に優先度が高いものとなる。

HTML&CSS

WEBサービスを作るなら必須のため特筆するところはない。

JavaScript

普通のWEBエンジニアとして開発したいということであれば違うが、今回はデザインをメインでやりたいということだったのでJavaScriptを次点とした。 ブラウザ上で色々動かしたりするのに使うので、最近はWEBデザインをやるならほぼ必須だろうと思う。(とはいえガッツリプログラムを書けなきゃいけないというわけでもないので、とりあえずは概要を知っておくだけでも良いと思う)

ただ、最近はFirebase等もあり、プログラム言語としてはこれだけでもデザイナーさんがWEBサービス全部作れてしまったりもするのですごい。多少深く勉強しても良いと思う。

jQuery

たまたま今回JavaScriptを2番めにしたので、その流れで3番めになっているだけ。 とはいえデザイナーさんでjQueryを使っている人はまだ多いのではないかとも思う。 プログラムを組むというよりは、既にあるライブラリを導入したり改造したりがメインとは思う。

PHP

レンタルサーバーなどで簡単にWEBサービスのプログラムを組むことができる、一番簡単なもの。 (ユーザーや投稿データを保存したりするのに使う)

今回の話がデザイナーでなくエンジニアということであれば、JavaScriptの代わりにこちらが一番だったと思う。 ちゃんとよく分かってなくてもリリースできるので。 (ただしエンジニアの場合であれば個人的にはちゃんと勉強して色々理解したうえでリリースして欲しいのでフレームワークとか使ってほしい)

Ruby, Ruby on Rails

Rubyは役割としてはPHPと同じだが、よくあるレンタルサーバーでは使えない。 でもRuby on Railsというフレームワークのセットで非常に開発しやすくなるので、一人でシステムを高速で作る場合に非常に人気があり、 スタートアップの開発などでも非常によく使われている印象がある。 (PHPの場合はLaravel, CakePHP等のフレームワークがある)

ただ、WEBデザインメインだとフレームワークまで使う必要があるのか? という感じ。 敷居も高く勉強に時間もかかるので、優先的にやるのはおすすめしない。

とはいえ、サーバー側も必要且つリリース環境の用意も可能だったらとりあえずこれで良さそう。 PHPフレームワークに比べ、ワンセットになっている感が恐らく初心者には分かりやすいと思う。

優先度まとめ

何にしろまずはHTML&CSS優先的に。そして、その後ちらっとJavaScript。 あとはどういったサービスを作るかによって変わってくるのでその段階で何を覚えるか決める。 勉強するぞ、という段階では決めづらい。

初期の開発と運用のためのおまけの補足

何かサービスを作っても基本的には誰も人が来ないので、どうやって人を集めるかはよく考えておく必要がある。 例えばTwitterを使った方法で基本的なものでは下記のようなものがある。

  • 開発中の独り言をつぶやくと、アドバイスがもらえたり、徐々にいつの間にか広まったりしてサービス開始時に有利になりやすい
  • 開発してリリース後、サービスを利用したりテストしてくれたりする人が増え、成長しやすい
  • もしフォロワーさんの興味、年代など、共通な属性が見られる場合、そのへんをターゲットにしたサービスにすることでヒットを狙いやすい

ただしフォロワーが多い人向けなので、フォロワーが少ない人は別の方法を模索するか、リリースに向けて増やしておく必要がある。 (大量購入などは無意味なのでちゃんと普通に増やす。仲の良いフォロワーさんが少ない場合もあまり意味ない)

まとめ

とりあえず最初の一歩に特化して書いた。実際にきちんと勉強できるか、リリースしてうまくいくかは全て本人次第。 基本的にはうまくいかないので、ひたすら継続し、体験したことからあらゆることを学習していくことが重要。

Phoenix1.3でex_adminを使う

Phoenixではex_adminという管理画面作成パッケージを導入することで簡単に管理画面が作成できる。

smpallen99/ex_admin: ExAdmin is an auto administration package for Elixir and the Phoenix Framework

しかし依存関係やフォルダ構成の違いの問題で最新のPhoenixではうまく動かない。ただ、よくよく調べてみると下記のphx-1.3ブランチを使えばできるっぽいので試してみた。

https://github.com/smpallen99/ex_admin/tree/phx-1.3

導入方法

phx-1.3ブランチを指定して入れる。ビルドに失敗するのでgettextのバージョンも上げる。

mix.exs

defp deps do
  ...
  {:gettext, "~> 0.13.1"},
  {:ex_admin, github: "smpallen99/ex_admin", branch: "phx-1.3"},
  ...
end

configを追加。

config.exs

config :ex_admin,
  repo: MyProject.Repo,
  module: MyProjectWeb,
  modules: [
    MyProject.ExAdmin.Dashboard,
  ]

後は通常通りのインストールと同じ。

brunch-configの修正

そのままだとex_adminのcssとかが混ざってしまう。brunch-config.jsに修正方法が追記されているので、そのとおりに修正。

またその際、node_modules内のcssをインポートしている場合はcssの設定だけ下記に修正が必要。

        "css/app.css": /^(css|node_modules)/,

モデル追加

mix admin.gen.resource User

これは特に変わりはない。ただ、1.3だとphx.gen.htmlを使っている場合、context module以下にモデルを入れていると思う。例えばAccounts.User等。

なので生成されたadmin/user.ex内のモデルの指定だけ修正しておく。

admin/user.ex(before)

  register_resource MyProject.User do

admin/user.ex(after)

  register_resource MyProject.Accounts.User do

これで動作した。

MediumとDev.toに記事をクロス投稿してみた

調べてみるとMediumとDev.toは自分のブログの記事をクロス投稿できることが分かった。

どういうことかというと、canonical_urlを指定できるので、SEO的にも問題なくマルチポストが出来るということ。

なので当ブログの

Systemdを使ったPhoenixの本番デプロイ詳細例

で早速試してみた。日本語そのまま。

Medium

やり方

普通に記事を投稿するのでなく、stories画面にImport a storyというボタンがあるのでそちらでURLを指定して投稿する。

1日経った結果

f:id:dala:20180329065851p:plain

…。

二人見てくれただけ…。

Dev.to

やり方

投稿時に色々パラメータを手書きできるが、canonical_urlを自分で追加する。

1日経った結果

f:id:dala:20180329070046p:plain

…お! 結構反応ある。

こっちはまだ出来たばかりだから新参でもまだ色々遊べそう?

というかユニコーンってなんだ?

mobageで運営していたゲームを終了させた

概要

mobage & Yahoo! mobageで運営していたゲームを終了申請しており、ついに今月終了となった。 プログラムを見ると2014年のものがいくつかあるので恐らく3年弱くらいになるだろう。

環境

背景

mobage等、課金システムのあるOpenSocialのプラットホームは法人でなくてはならない。 自分はフリーランスでエンジニアをしていたが、 OpenSocialのアプリで稼ぎたいと思ったので、mixiアプリが出始めた頃に法人化した。 それでmixiGREEmobageに登録し、それぞれアプリを出した。

mixiはまだネココさんというアプリが動いていると思う(誰もプレイしてはいないと思うが)。 GREEもネココさんを動かしていたが、サーバー代が厳しいので終了させた。

mobageはエンディングロードというRPGを出した。AndroidとPCブラウザのハイブリッド。 こちらもサーバー代が厳しかったのでさくらの安いVPSに途中で変更してほそぼそと続けていた。

f:id:dala:20180208221803j:plain

f:id:dala:20180208221839j:plain

終了した理由

売上はほとんど無かった。 10連ガチャが初回300円なのだが、3000円で引いているユーザーなんて見たことがない。

でも安いVPSに移動して費用的な負担はほとんど無かったので、記念にずっと残しておこうとは思っていた。 ただ、やっぱり色々懸念点が出てきたので終了することを決めた。 具体的な理由としては下記のようなもの。

問い合わせ対応が大変

基本的に問い合わせはちゃんと24時間以内に1次対応をしなければならない。 しかし、土日だってあるし仕事だってあるので毎日見てられない。 問い合わせが来たとしてもほとんどAndroid経由の営業スパムだし。

さらに、僕が普段使うPCをLinux Mintしたことで問い合わせのソフトが使えなくなってしまった。 問い合わせが来たらWindowsに切り替えるかmacを立ちあげなくてはいけない。 正直もうだいぶ負担だった。

SSL

いつからかChromeSSLでない場合に警告を出すようになった。 世の中はSSLが当たり前に変わっていっている。 恐らく、そのうちChromemobageSSL必須化し、SSL対応を迫られる日が来ることが予想された。

現在無料SSLができるのでそれほど技術的に問題はないのだが、 とはいえ既に稼働中のサーバーであれこれ操作するのは怖い。

それよりも一番問題なのが、先程も書いたようにLinux Mintに変えてしまったので、 開発環境をWindows側に残したままだった。 SSL対応のためにいちいちWindows(起動がすごく重い)に切り替えるのは大変。 しかも実装するとなるとまたあれこれ修正してテストもやり直さなければならない。 かなりの重労働で、ただでさえ仕事で忙しいのに厳しい。

責任

上記の問題点を考えているうちにふと思ったのが、 もし明日、明後日急にSSL必須になったらどうしよう、という思い。

もちろんmobageはちゃんとしていてそういうことは猶予をもってお知らせがあるので問題はないのだが、 例え1,2ヶ月であっても今の自分としては辛い。

そんなこんなやっているうちに対応できずSSL必須化になってしまったら、サービスは止まってしまう。 もしかすると正しく運用出来ないことで責任を追求されたりするのでは…等という考えが頭をめぐった。

サービス終了はもはや当然の決断だった。

最後の問い合わせ

不具合の問い合わせが来たのであれこれやり取りして修正した。 今回はDB側で修正すればよかったので問題なかったのだが、 プログラム側の修正が必要だったらと思うとゾッとした。 これが引き金になったと思う。

終了した

終了申請をし、課金終了の準備をしてお知らせをし、課金終了までに約1ヶ月、そこから終了までに約1ヶ月、無事終了することが出来た。 ちなみにこのあとも問い合わせ対応を行わなければならない。

ソース

公開したが、古く汚いので、動かなくて困っている、くらいの人でないと役には立たないものと思われる。

cocos側のプログラム。

GitHub - dala00/endingroad: Ending Road game client

READMEにも書いてあるが、フリー素材などは念の為再配布にならないよう全部削除している。

PHPで書かれたサーバー側は、 万が一mobageの漏洩させてはならない情報を削除し忘れて漏らしてはいけないので、 結構勢い良く適当にフォルダ毎がっつり削除した。 (それでもまだ怖いくらい)

GitHub - dala00/endingroad-server: Ending Road (server application)

もう不要だしPSR-2すら知らない頃の汚いプログラムなので何の参考にもならないが、 丸々欲しい人がいれば(機密部分は当然省いて)ゆずるので問い合わせして下さい。

一問一答

どんなゲームだったのか

当時リリースされたテラバトルを見て、これなら自分の作ったゲームも売れるんじゃないかと勘違いしてリリースした、簡易ストーリー型のステージクリア型RPG

クソゲーだったか

プレイする人によるのではないかと思う。 クソゲーだと思う人もいるだろうし。頑張って作ったので割と遊べるのではないかとも思う。 フリー素材のクオリティも全般的に良かった。

経験値量的にすごく大変なはずなのにイベントキャラ全部最大レベルまで上げてくれた人もいた。本当に感謝。 ちなみにイベントキャラは+99するとSSRよりちょっと強い。(だった気がする)

リジェクトされなかったのか

一人で作ったので一般のアプリよりはしょぼかったと思うが、そういう理由ではとくにリジェクトされなかった。 不備があったりしたところを直していくとちゃんとリリースまで進めた。

エンディングは

実はエンディングのステージを作らずに終了してしまった。

考えていたものとしては、下記へ続いていくようなストーリー。

エルアネット - Google Play の Android アプリ

つまり偉い人たちが増えすぎた人間を排除するために世界は滅亡するという噂を広めた。 人々は楽園をめざすために冒険して減っていき、楽園に着いてもエルアネットに転送される。 (転送されるのか、偉い人側にいくのかは決めていなかった)

ちなみに舞台は未来の地球という設定。エアルスという名前にしようとしたが、 どうもガンダムで使われているようなのでルシアとかで想像していたと思う。

サーバー解約できて良かったですね

上記のアプリが一緒に入っているので解約できなかった…。 誰もプレイしていないみたいだし停止するか記念にGCPに移動してゼロ円運用(移動が面倒)するか検討中。

再公開はするのか

他に作りたいものがどんどん出てくるしそんなことをする暇はないので可能性は少ないが、 もし気が向いて試して一瞬で可能そうだったらやるかもしれない。 ただし可能性はかなり低い。

まとめ

一人でもソーシャルアプリは作れる。会社で複数人いるならもちろん。 こういったプラットホームは何もしなくてもインストールしてもらえるのでありがたいが、それだけでは絶対に足りない。

通常のゲームと同様、自分たちでちゃんと宣伝し、課金率も上げていかないと運営は成功しない。 やるならきちんとやらなければならない。 ゲームを作ってリリースして運用するのはとても楽しい。

技術的な話はQiitaで。

mobageで運営していたゲームのソースを公開 - Qiita