たけてぃーの開発ブログ

エンジニア視点からWebサービスについて考える

【pixiv 2016 SUMMER BOOT CAMP】インターン行ってきた

概要

日時

  • 2016年8月29日(月)~9月2日(金)平日5日間

  • 10:00~19:00(休憩1時間)

インターン内容

本プログラムでは、インターン生で複数のチームをつくり、【実際に社内で取り組んでいる課題解決 / 新サービスの企画・実装】などを行ってもらいます。 インターンシップではありますが、企画して終わりではなく、ユーザーに向けてリリースし、結果をユーザーの入会率や開封率など、具体的な数字で振り返ります。 机上の空論ではなく、ビジネスの現場でサービスがどのようにユーザーに評価されるのか、是非このリアルを体験してください。 また、ユーザーが新たにどのようなサービスを求めているかを考え、企画・開発し、最終日には役員を前にプレゼンしていただきます。 分のアイデアがビジネスとして通用するのか試してみたい方も是非チャレンジしてください! サービスをつくる上で必要な知識・技術は社員がしっかりサポートしていきます。 ピクシブ社内の実際の会議にも多数参加いただき、開発の裏側も見ていただく事ができます。 1人では学べない、人と人との働きで切磋琢磨されるスキルとコミュニケーションを学んでください。

「pixiv 2016 SUMMER BOOT CAMP」 エントリー

実際に取り組んだこと

pixiv本サイトメンテナンス

ほぼほぼ社員と同じような生活を1週間する、といった感じだ。

どうして申し込んだか

GitHub採用」というものがあり、自分のレポジトリや作品を提出するだけで合否が決まるのはいちいち面接せずに(1度はしたが)楽そう、というのとPixivほど大きなWebサービスで使われてる技術を学びたかったからだ。

実際仕事してみて

僕がいただいた仕事は「バグフィックス」と「リファクタリング」だ。割と普段からやってる仕事なのでそんなに難しくもなかったし、悩んだのはpixiv特有の仕様(独自フレームワークを使っていたりなどなど)くらいだった。地味だしそんなに語れることがない。

面白かったのはインフラ周りの話だ。pixivは巨大なイラストサイトなのでDBもストレージも巨大だ。そのようなインフラを効率良く回すための取り組みを聞けてすごい勉強になり、またインフラに対して興味が持てた。

会社はどうだったか

会社の社風と社員(特にメンターをしていただいたtadsan)の話をしていく。

会社と社風について

  • エンジニアが大事にされている
  • 自由に発言できる
  • 新しい技術や情報に敏感
  • 自分のサービス愛が強い
  • 技術的な話が常に飛び交っている

プログラミング大好き人間としてはとてつもなく居心地がよかった住みたい(自己紹介の時にjavascript/phpが好きです!って言っても引かれなかった等)

また飲み物がタダで近くに昼食取れる場所が多かったので快適だった。

社員について(メンターのtadsanとのやり取りの話など)

「なんでなの?」「どうしてなの?」「僕はこう思うけど、どうしたらいいの?」「今の問題とは関係がないけれど、ここの部分の処理はどうしてやっているの?」という質問をかなりしたのだが、すべての質問に対して明確に答えていただいがのがすごいすごい嬉しかったのと同時に、社員のプログラミングに対しての知識と理解の深さを感じた。

例えば「Docsってなんで書くの?」って質問だと、普通なら「決まりだから」などといった返答しかされないのだが、「PSR-5 PHPDoc Standardを調べてみ」や「静的解析について調べてみ」、「ついでにこの記事も〜」などと知識が深まるような説明をしていただいた。

最新のPHPの情報、動向、処理系、SQLのQueryについて、ルーティング、フレームワークなどなど多くの話題に対して深い知識と自分の意見を持っていて勉強になった。と同時に自分の知識の浅さや経験のなさを感じたので今後の課題が見えてきたのですごいよかった。(会社で徹夜で喋り続けたりした)

また、仕事でコーディングするのは当然としてさらに面白いモノを作り出したいと思っている社員が多かった。個人で色々作る人、OSSコントリビュートする人、記事を書く人など様々な人がいた。

僕のメンターのtadsanの記事はQiitaでめちゃくちゃお世話になっていたので配属されて実際に会った時感動した。

感想

月並みな感想だがとてもとてもとてもとてもとても楽しかった。過去最高に楽しい職場だった。

5日間という短い期間だったが、プログラミングについて議論したり、新しい知識を得たり、実際に業務で使われているコードを読み、会議に参加することによって実際にスケジューリング経験し、「一つのサービスをみんなで創り上げていく」ということを経験できて楽しかった。

pixivの皆様(特にメンターのtadsan)本当にお世話になりました!

P.S.

もし入社したらその時はよろしくお願いします!

「この過労死がすごい」もう一度やりましょう!

サービス開発に対して思っていることをまとめる

インターンや面接、様々な場面で自分の考えや技術的なことを喋る機会が多いのですが、喋るのがあまり得意ではないのと時間が限られていて伝えきれないことが多いのでブログにまとめていきます。所々話が重複してるところもありますが説明のためです。

技術的なことや実際のソースコードqiitaGitHubにまとめているのでそちらをどうぞ

サービスの開発改善していく上で一番大事なことってなんだろう?

プログラミングや企画、デザインなど全てに共通するものなのですが、何をやるにしてもこの疑問が一番大事だと思います。「収益を増やす」、「ユーザー数を増やす」、「使ってくれているユーザーがもっと快適に操作できるようにする」、「自分たちの開発能率を上げる」など様々な目標があげられると思います。

その目標を達成するためにはどうすればいいでしょうか?

方法は非常にたくさんあげられると思います。

例えば、「使ってくれているユーザーがもっと快適に操作できるようにする」という目標に対してのアプローチを考えてみます。

1. スマホユーザーに対してのアプローチ

スマートフォンは今や若者の普及率が9割を超えているという調査(総務省調査)があるように普通に使われているものです。Androidユーザーが3割、iOSユーザーが7割くらい(おおよそ)です。さて、スマホユーザーはスマートフォンを使用してる時に何をやっているでしょうか?基本的にブラウザを開くよりもネイティブ(スマホ)アプリを開いていることが多いとおもいます。

では、ユーザーのためにネイティブアプリを作ればそれで本当にいいのでしょうか?

答えはYesでありNoだとおもいます。人的、金銭的、時間的にリソースは限られています。xamarinは置いといて、基本的にAndroidiOS開発は別です。レスポンシブルデザインじゃダメなの?本当にネイティブアプリを作るだけの価値があるの?と言ったことをきちんと考えてそれでも「やはり必要だよね」となれば開発するべきだと僕は思っています。(当たり前の話ですが....)

スマートフォンにはPCと比べてメリットもデメリットもあります。メリットとしてあげられるのは「外出時でも気軽に見ることができる」などです。逆にデメリットは「通信が安定しない」や「処理速度が遅い」、「機種によって画面サイズもOSのバージョンの挙動も様々(Androidが顕著らしい)」などがあげられます。

さて、このようなデメリットを埋めるためにはどうすればいいでしょうか?

一つは「通信量を抑える」というものが考えられます。ではどのようにしたら通信量を抑えられるでしょうか?DBから引っ張ってくるデータの量を最適化する(無駄にjoinしてないか)、xmlではなくjsonで送る、無駄なviewコードを書かない、ソースコードを圧縮する、など様々考えられます。

また「処理速度を改善する」というものも考えられます。計算回数を減らす(アルゴリズムの見直し)、データバインド数を減らす、メモリ管理はどうか、細かい高速化Tipsはたくさんあります。

当然改善すべきところは改善すべきなのは当たり前ですが、これは本当に優先事項の高いことなのでしょうか?Yesならばすぐに改善すべきですし、Noならば別のものを改善してから取り組むべきです。

2.PCユーザーに対してのアプローチ

PCはスマートフォンと比べて処理速度も高く画面も大きい場合が殆どです。また通信が安定している場所で開くことが多いのである程度アニメーションを入れたリッチなサイトにしても問題無いとおもいます。

さて、サービスを使ってくれているユーザーはどの端末からアクセスするでしょうか?僕が今やっている開発では8割以上がスマートフォンからのアクセスです。では、どのように開発すればいいでしょうか?

一つの方法としては、「PC版とスマホ版で切り分ける」という方法です。ユーザーエージェント毎にPCページとスマホページを切り替えということができるのでこの方法でもいいでしょう。

また、スマホPC共に表示できるレスポンシブルデザインもいいでしょう。bootstrap使えば簡単に実装できますし、別々に作るよりも開発効率はいいです。

3.バグについて

「バグの無いシステムなど存在し無い」とよく言われていますが、どうしてバグがでるのか、バグが出ると何が困るのか、どうやったらバグが出にくくなるのか、と言ったことについて考えていきます。

どうしてバグは出るのでしょうか?僕は「人間はミスをする生き物」だからだと思っています。ちょっと処理を書き間違えた、変数名をミスった、エラー処理をしてなかったとか様々ありますが、ミスをするのはしょうがないです。「闘うプログラマ」でも同じようなことが書いてありました。世界中の天才と呼ばれるプログラマが集まってWindowsNTの開発を行ってたのですがバグが膨大な数出たそうです。

さて、バグが出るのはしょうがないとして、バグが出るとどんな問題が生じるのでしょうか?たくさん考えられますが、「ユーザーから信頼されなくなる」のが一番の痛手なのではないでしょうか?自分の個人情報などをばら撒かれるor自分に危害が及ぶことをわかっていてそのサービスを使いたいでしょうか?サービスの内容以前の問題になってきます。バグ修正は最重要項目だと僕は思っています。

ここが一番肝心、バグはどうやったら減るorなくなるのでしょうか?TDD(テスト駆動型開発)やデバッガなど様々な手法方法が考えられてきました。それぞれすごく役に立ちとても良いと思うのですが、僕が一番大事だなと思うことは「ソースコードを綺麗に書く」です。UNIX哲学に「一つのことを、うまくやれ」という言葉があります。シンプルな方がいいんです。他にも素敵なことが書いてあるので詳しくはWiki

さて、ソースコードを綺麗に書くにはどうすればいいでしょうか?

僕が普段心がけてることは以下の通りです。

視覚的にソースコードを美しくする

デザインの4原則「反復」「整列」「コントラスト」「近接」が役に立ちます。変数定義、ロジックをなるべく"近接"させる。=;などで"整列"する。それぞれの関数の中の処理を「反復」して一貫する。syntax highlightで「コントラスト」する(例がいまいち...)。

このようなことを気をつけるだけで圧倒的にコードが見やすくなります。(当然コーディング規約も大事だが)

また、フォントや背景色にもこだわることによってより視覚的に見やすくなると思います。

あとはファイルの大きさも150行くらいまでにするとぱっと見わかりやすくなるのではないでしょうか?

なるべく早くreturnするようにする

多重ネストしたコードは可読性が下がります。さっさとreturnして綺麗にしましょう。

ファイル分割を美しくする

どのファイルに何があるか、どこを編集すればいいのか、どうやって追加すればいいかの理解がしやすくなるとコード書く早さもバグも減ると思います。

意味のないコードを書かない

使われていないコードは本当に知りたいコードを探すときにノイズになってしまいます。なるべく書かないようにしたいものです。

データのフローを意識する

データがどのように流れているのかということを意識するとバグがどこで起きたのかすぐに特定できます。データの流れはデザインパターンによって決められることが多いとおもいます。

アンチパターンやセキュリティ的に問題になりそうなところをあらかじめ勉強しておく

qiitastack overflowなど様々な情報共有サイトがあります。そこで他人のコードを読んだりバグがでそうなパターンを読んだり実際に趣味でコード書いてみたりするようにしています。

結論

時間、人手、金は限られているのでその中で最大限目標を達成するためにはどうすればいいのだろうか?何が一番優先順位が高いのだろうか?ということを常に考え実行していくことが重要だと思っています。その目標を達成するためには様々なアプローチの仕方があってそれぞれのアプローチの仕方が本当に正しいのかを考えながら実践していくことが重要だ、また目標を達成する手段を増やすために個人でも勉強をしなければならない、と僕は思っています。

初めから処理速度だとか通信量だとかいずれ改善しなければならないだろうことを意識できていたら2度手間になることはないですからね。

最後に

まだプログラミングを初めて日が浅いので様々な仕事を受けてもっともっと自分の中で改良していけたらなぁと思っています。

フロントエンドの技術選定をした時に行ったこと(まだ検討中)

暑い暑いとても暑いです。

現在お仕事いただいてる現場でこんな話になりました。

僕「そういえばこのサービスではフロントエンドとバックエンドわけないんですか?」

先輩「今はPure Railsだけどそろそろわけないと限界かなぁ・・・じゃあフロントエンドと分けるためにはどうすればいい?何を使えばいい?」

僕「うーん・・・わからない」

先輩「じゃあ調べてきて」

というわけで、フロントエンドの技術選定を任されました。

やはり現代のサービス開発においてはWebAPIとフロントエンドを切り分けるのは当然の発想です。

qiitaに前に書いたので暇だったらどうぞ→エンジニア視点から見るWebサービスの全体像(qiita)

理想像

WebAPIとフロントエンドをきっちりわけて、フロントエンドをSPAに、WebAPIrailsからより高速な物に差し替える。

ついでにモバイルネイティブアプリも作れたならなぁ

満たすべき条件

こんな条件が挙げられました

  1. JS/CSS/HTMLまわりを一手に担ってくれること(フロントエンドフレームワークの必須要件?)

  2. ES6からトランスパイル、SCSSからCSSへのプリコンパイルが出来る。 できたらslimやjadeっぽい記法でHTMLが書けたら嬉しいけど必須ではない。

  3. 今後の時代の変化についていきやすいこと(エコシステムの存在・デファクトスタンダードになっていること、など)

  4. 何らかのユニットテスト機構が標準で入っているか、簡単に実行出来るようになっていること

デファクトスタンダードとは「事実上の標準」という意味です。

そもそもViewをレンダリングする方法について

主に3種類あるのではないだろうか

1.サーバーサイドのテンプレートエンジン

2.半々のもの(gemjavascript libraryを管理したり、埋め込み型)

3.完全に独立したhtml,css,javascript

将来的には3を目指したいが、2→3と開発を進めていくのが妥当かなぁと

そもそもフロントエンドにおけるフレームワークってなんなの?

僕「実はこの前Riot.js+Fluxフレームワーク(GitHub)みたいなの作ったんで使いませんか?gulpガッツリ書いて超効率よくかけるようにしましたよ!」

先輩「確かにそれはいいんだけど、主流に乗りたいし、それ誰が管理できるの?フレームワークとかないの?」

僕「そういえばフロントエンドのフレームワークってなんだ?」

調べてみたらフロントエンドにおける「フレームワーク」はテストツール、DOM操作、Ajax関係、mockなどなど多くの拡張ライブラリを備えたライブラリのことみたいですね(要検証)

RailsLaravelとか僕が思い浮かべてたフレームワークと呼ばれる物はYeomanなどのコードジェネレーターを使わなくちゃできないみたいです。

じゃあjavascriptのライブラリどうする?

結論から言うとReact.jsになりそうです。(僕はRiot.jsがすごい気に入ったんですがやっぱりあれば色々足りない・・・・)

理由: - Fluxがとても良く、それを良く実装できるから - コミュニティが大きい - 参考記事が多い - テストツールもある - ソースコードも綺麗にかける

まぁただ一つ嫌な点はjavascript中にhtmlを書くのが個人的には気に入らない・・・・

参考にした記事

Wantedlyの記事

React + Reduxを使ったWebアプリケーション開発速習会@Wantedly(qiita)

Railsで構築しているWebサービスをjQueryベースからReactに移行する時の知見

境遇が似てたWantedly様に圧倒的感謝!!!(いい記事ありがとうございますっ!)

最後に

まだ決まってるわけではないのですが、多分この方針でいくと思う。

フリーランスのエンジニアとして仕事を始める

7月に入り気温も上がりすっかり夏になりました。

ここ2ヶ月で起こったことをまとめて現在の状態と今後の展望についてまとめていこうと思います。

5月

バイト先の新サービスに向けてWebAPIをLaravelで、フロントエンドをAngularjs+Fluxで開発して準備をする。骨組みが完成し、いつでも即開発できるような状態まで持っていけていた。

6月

  • 6/2

バイト先で新サービスの開発が中止、その場で即バイトの首を切られる。(かなり凹んだ)

  • 6/3

たまたま筑波大卒の方Sさんとご飯食べに行く機会があり、事情を告げる。

  • 6/4 ~ 6/13

Sさんの大学時代の友人Aさんを紹介してもらう。Aさんは現在都内でフリーランスのエンジニアをやっていて、そのつてで仕事の紹介をしていただく。

  • 6/14

紹介先の方と面接をし、その場で即githubのレポジトリをいただき、開発をはじめる。雇われではなく、受託開発なのでフリーランスとして働き始める。

  • 6/14 ~

現在はその仕事のみをやっているが、他の方からもオファーがきているので他にもやるかもしれない。

フリーランスになって1ヶ月で思ったこと

  • 技術力も大事だが、コミュニケーション能力も大事

依頼主の要望を適切にまとめ、それを実装する。

  • リモートワークが主なので文章を美しく書く必要がある

今自分が何を思っていて、何が必要で、何を聞いているのか明確かつ答えやすい形で質問することが重要である。

自分で1から実装するなら別だが、他の方が書いたものを使うのであればとにかくソースコードを理解し、うまく利用して実装するのが重要である。

  • 自分からアイディアを提案し、その実装コストを説明する

いわゆる「コスパの良い」実装方法を提案することが重要である。

今後の展望

今現在いただいている仕事で大幅なリニューアル(Pure Railsで作られたものをフロントエンドとWebAPIに分ける)を提案したら好感触だったのでその開発をやると思う。他にもissueを片付けたり。

友人とゲーム開発をやって売ろうという話や、新サービス(SNS)の開発をして運用する予定(確定)。

「起業するからエンジニアとして手伝ってくれ」という誘いを受けたのでその開発をやる予定(予定は未定)。

技術的なこと

現在僕のできることはこんなもんですかね

SCSSを使ったりも...

  • javascriptのライブラリを用いたフロントエンド開発

javascriptのライブラリはjQuery, Angularjs, React.js, Riot.jsを使ってきた

デザインパターンFLUXがマイブーム

ビルドツールgulpを使い、ビルドシステムを作ったり

  • WebAPI制作

Laravelを使ったWebAPI制作(認証はJWTが便利ですね〜)

これは業務経験もあるし、個人開発もあるから割と慣れてる

最後に

今は大学生なのであまり開発にも打ちこめていなく、上司や教えてくれる人が少ないので、どうしても独学に頼らざるを得ない状態です。さっさと社会人になってもっともっと開発力やコミュニケーション能力を高めていきたい。

戯言

想像以上に開発力よりもコミュニケーション能力を問われるんですね。開発力を高めるよりもコミュニケーション能力を高めた方が今後稼げる.....?

エンジニア視点から見るWebサービスの全体像

こんにちは、たけてぃーです。ここ1年webサービスを作ったり案を練ったり勉強したりしたことを踏まえて現在のWebサービスの形についての記事を書いていこうと思います。

目的

技術的な視点でWebサービスの全体の設計を大雑把に解説考察することにより、全体像を非エンジニアにも理解してもらう。

WebAPIの役割と重要性について理解してもらう。

現在と過去のWebサービスの形

過去、現在のWebサービスの形は下図のようになっています。

f:id:bararararatty:20160526213700p:plain

用語解説

  • DB・・・データベース(個人情報などデータを格納する場所)

  • WebAPI・・・特定のURLに値とともにアクセスするとデータベースから必要なデータを取ってきてそれをクライアント(ユーザー側)にそのデータを送信する。

  • PC・・・パソコンのアプリケーション

  • Browser・・・InternetExploreやChromeといったブラウザのこと

  • Developer・・・WebAPIを利用する外部の開発者

  • Phone・・・スマートフォンのネイティブアプリケーション

  • Analyze・・・データ解析

  • WebSite・・・静的webサイト

過去

  • ブラウザからWebサイトにアクセスして、WebサイトはDBと一体になっていて必要になり次第DBからデータを引っ張ってくる。

  • ある程度DBにデータが溜まったら、そのデータを解析してWebサイトに反映させたりマーケティングに活かしたりする。

現在

  • DBからデータを引っ張ってくるための玄関口としてWebAPIを用意する。

  • WebAPIからデータを引っ張ってきてフロントエンド(Webサイト)を構築する。

  • WebAPIを多種多様なプラットフォーム(例:PC,SmartPhone)から叩けるよう(データを引っ張ってくる)にし、ネイティブアプリを作る。

  • WebAPIを叩き(データを引っ張ってくる)、DBにあるデータを解析してマーケティングに活かす。

現在のWebサービスの中核にあるものは「WebAPI」である

WebAPIとはDBからデータを引っ張ってくるための玄関口であり、上図のように様々なプラットフォームからアクセスすることができます。これにより、汎用度もあがり、また開発の仕事の分担も楽になります。

WebAPIのメリット

  • WebAPIを作ることによって多種多様なプラットフォームからアクセスできるようになり、サービスの拡張がしやすくなる。

  • WebAPIを外部に公開することによって、外部の開発者が使えるようになり、宣伝にもなり、またそのサービスに新たな価値が見出される可能性がある。

  • サーバーサイドとそれ以外を分けることにより、仕事の分担が楽になる。

  • WebAPIはバージョン管理ができるので、古いものと競合せずに新しいものが作れる。

  • 処理が分けられてるのでバグが起きた時に特定しやすい。

WebAPIのデメリット

  • 大勢の目前に晒されるのでセキュリティに細心の注意が必要になるし、エンジニアの能力も必要になってくる。

  • ブラウザやスマホからWebAPIを叩く(データを引っ張ってくる)時の通信の処理を書く分、エンジニアの能力が必要になってくる。

結論

WebAPIを使うことによって多少のデメリットがあるものの、開発面でもマーケティング面でも非常に多くのメリットがある。

最後に

これは自分が今まで学んできたことなので正しいとは限りません。多くの批判コメントが来ることを望んでいます。

プログラミング始めてから1年を振り返って

こんにちは、たけてぃーです。

プログラミングを真面目に始めて1年ちょい、ここらで1年間やってきたことを振り返っていこうと思います。

2015年(大学2年生)

4月

たまたまイベントで知り合った社会人の方に「今作ってるサービスあるから一緒にコード書かないか?必要な部分は教える」と誘われ、HTML,CSSを勉強し始める。ほぼ0からのスタートだった。

5月〜7月

javascriptというものをいじり始める。サンプルコードを書いて動かしてニヤニヤしてた。

8月

angularjsを毎日毎日いじり続ける。別の社会人の方にビジネスやマーケティングについて色々教わる。biboroレポジトリをいただき、微微微微力ながら手伝う。

9月〜10月

前のバイト先(本屋)が潰れたのがきっかけでベンチャー企業でバイトすることになった。最初にやったのはCakePHPでメール送信機能と管理者画面のビューの作成だった。ここで始めてサーバーサイド(PHP)を触る。

11月〜12月

バイト先のイベントの得点集計プログラムを組む。ぶっつけ本番でバグが0だったが、色々機能追加の注文が来てシステム開発の大変さを知る。社会人の方2人と新サービスの開発を始める。学園祭に向けてゲームを作る→記事

2016年

1月〜2月

外注に出してたバイト先のwebサイト開発の現場が炎上する。コアな部分の開発は手伝ってないが、かなりコードは書いた(と思う)。また、新サービスの方の開発も行う。過剰に働くとキャパシティオーバーになるんだなぁということを学んだ。

3月〜5月(現在)

バイト先の新サービス開発に向けてバックエンド、フロントエンドのひな形を作る。(目的はそれだけじゃないが)

今後半年くらいでやりたいこと

  • 自分が今作りたい新サービスを作る

  • バイト先の新サービスの開発

  • ゲーム制作

まとめ

色々凹むことや考えされられること、叱られることが多かった1年だったが結果として自分の成長に繋がったように思える。本当に社会人の方2人には感謝している。

今後は自分で考えてサービスを作ったり、活動をしていきたいと思う。

チャリ走風シューティングゲームをenchant.jsで作ってみた

風も冷たくもうすっかり冬ですね。どうもたけてぃーです。

最近はバイトでCakePHPを使ってweb開発をしたり、javascriptのnodeモジュールとかを弄っていましたが、大学祭に向けてゲームを作らなくちゃいけないということでenchant.jsを使ってチャリ走風シューティングゲーム二輪無双」をつくってみました!

(リザルト画面が間に合わなかったからまだ未完成っちゃ未完成)

リンク→「GitHub

f:id:bararararatty:20151124111143p:plain

ゲームの内容

走って撃って走りまくる旧感覚アクションゲーム!

操作説明

タイトル画面をクリック後、Zボタンで敵を倒してポイントを稼げ!

index.htmlで起動します

簡単なコード解説

かなりソースコードを綺麗に書けたなぁと自画自賛しています。

簡単に言うと、クラス作ってインスタンスつくってシーンにぶち込むだけです。特に小難しい処理はしていないですね。

シーン管理

var titleScene = function(){
    var scene = new Scene();
    scene.addChild(new Title(scene));
    return scene;
}

var gameScene = function(){
    var scene = new Scene();
    scene.addChild(new Background(scene));
    scene.addChild(new Ground(scene));
    scene.addChild(new MetreLabel(scene));
    scene.addChild(new PointLabel(scene));
    scene.addChild(new Player(scene));
    return scene;
}

core.pushScene(titleScene());

classのインスタンスをつくってsceneをプッシュして描画する感じですね〜簡単

敵基底クラス

var EnemyBase = Class.create(Sprite, {
    initialize: function(SPX, SPY, scene_){
        Sprite.call(this, SPX, SPY);
        this.x    = SPORN_ENEMY;
        this.scale(EXPANSION, EXPANSION);
        this.addEventListener('enterframe', function(){
            if(this.x < 0){
                this.remove(scene_);
            }
        });
        scene_.addChild(this);
    },
    remove: function(scene_){
        scene_.removeChild(this);
        delete this;
    }
});

敵の数は3〜4個以上あるみたいだったので基底クラスつくって楽しました。デストラクタはどうせどの敵にも適用されるからね

this.scale(EXPANSION, EXPANSION);は画像が小さかったから縦横共に1.5倍にしてるだけです。

ファイル分割

<head>
    <meta charset="utf-8">
    <title>二輪無双</title>
    <script src="./js/enchant.js"></script>
    <script src="./js/config.js"></script>
    <script src="./js/funcs.js"></script>
    <script src="./js/main.js"></script>
    <style type="text/css">
        html, body {
            margin: 0;
            padding: 0;
        }
    </style>
</head>

一応ファイル分割しました。さすがにmain.jsに400行書いてあったのでまずいなぁと思いました。

作った感想

開発期間が3日(サボってたから)だったので死ぬ気になって書いたから疲れた。余裕を持って開発するべきですね反省

画像とゲームバランス調整はサークルの友人のゴーショーくんにしてもらいました。一番の鬼門だった画像が外注できて本当によかった。

このゲームのソースコードについて

どうぞご自由に改変していただいて結構です。ぜひこのゲームを元にさらに面白いゲームを作ってください。そしたら僕もやってみたいです。

リザルト画面が作り終えてないなど、まだ不完全なのでちょこちょこ直していきたいと思っています