スプーキーズのちょっとTech。

SPOOKIES社内のより技工的な、専門的なブログページです。

個人的に良く使うGulpライブラリ達

gulp npm nodejs

初めまして！アルバイトの吉田です！

spookies内では初めてのブログ投稿ですが頑張って書いていきます！

Gulp

今回はタスク自動化ツールとして有名なGulpで私が個人的に良く使うライブラリを紹介していこうと思います。

個人的に良く使うライブラリ達

1. require-dir

www.npmjs.com

いきなりGulp系のライブラリではないですが・・・ 指定したディレクトリ内のファイルをrequireしてくれるライブラリです！

やってることは単純ですがこれがあると gulpfile.js が

const requireDir = require('require-dir');
return requireDir('./gulp');

2行で済みます！便利！

後は gulp フォルダに処理毎に書かれたjsファイルを入れてあげるだけで良い感じに仕上がります！

2. yargs

www.npmjs.com

簡単に引数を使うことができるライブラリです！

これを使うとGulp時にソースマップを付けるかや圧縮を行うかなどの指定ができるようになるので、わざわざ別タスクとして作る必要がなくなります。

3. gulp-if

www.npmjs.com

Gulp版if関数ライブラリです！

単純にGulp用に作成されたif文の様なものなので簡単に扱えます。

単純だけど使用頻度は高い・・・そんなライブラリです。

4. gulp-watch

www.npmjs.com

ファイル変更を検知してタスクを実行できるライブラリです！

「こんなライブラリ使わなくてもGulpの標準機能にwatchあるからそれ使えばよくない？」と思われるかもしれません。

このライブラリでは標準ではしてくれない新規ファイルに対してのタスク実行も行ってくれる優れものなのです！

開発し初めた段階でこのライブラリを使用していると、とても幸せになれます。

5. gulp-sequence

www.npmjs.com

Gulpタスクを順番に実行してくれるライブラリです！

このライブラリの便利なところは初期化処理をタスクとして実行したい時に、初期化タスク中に別のタスクが始まるのを防げます。

※Gulp4では標準化されているようです。

あとがき

他にも色々使用しているものがありますが良く使うのはこの辺のライブラリです。

http://www.npmjs.com で「gulp」と検索すると他にも色々なライブラリが見つかるので是非

僕の考えた最強のGulpランナー

を作ってみてはいかがでしょうか！

Cloud Native Kansai #3 でLTをしてきました

kubernetes docker

こんにちは。アンバサダーの id:masayuki14 です。新しいカメラがほしい。
そんなことより今回もCloud Native Kansai に参加してきました。3回目です。#1 #2 のレポートはこちらです。

イベントが公開された後すぐに定員オーバーになっていたので、参加するにはLT枠しかないなーということで、今回はLTでの参加です。過去2回の参加でCloud NativeとかKubernetesの概要はわかった気にはなったんですが、やはり自分の手を動かさないと身につかないぞ、ということでこの1ヶ月ほどの間でいろいろと試したことを発表しました。やはり人前での発表ってのは緊張する。

cnjp.connpass.com

会場は今回もMOTEXさんの提供で、これまでの大きなホールではなくカフェスペースでした。いつもありがとうございます。LTは全部で7本でどの発表も面白かったです。仙台でも同時開催となっていたらしく、急遽リモートでつないで仙台にも発表が配信されました。
こんな感じだったようです。

わたしの発表も仙台からツイートされててなんかすごい！

ということでLTで使ったスライドはこちらです。

前回のLTで紹介されていた Compose on Kubernetes を使ってみようということでいろいろやったことを10分で収まるようにまとめて話してきました。自作のdocker-compose.yml をローカルで動かすまでにもけっこういろいろやったんですが、その部分はばっさりカットしてGKEで動かす部分を中心にしました。

そのあたりの詳しいことはおいおいブログで書いていこうと思います。とりあえず1つ目のエントリーはこちら。

masayuki14.hatenablog.com

話のオチとしては「GKEで動かないよー」ということで、未だにIssueもレスがないのでもう普通にKubernetesで動かすしかねーな、って感じです。
うまく問題解決まで行けたら続編としてまたLTしたいなと思います。

さて、次回はまた大きなホールでの4回目です。参加者も多く注目度の高さが伺えますね。

cnjp.connpass.com

懇親会でインフラについて聞いた話によると、お客さんのオーダー通りに作るのでEC2とかRDSとかで用意することがほとんどだからコンテナでインフラ作りたいけどそれはできない、というのが現状のようです。
コンテナでインフラ作ることを考えると、それを前提とした開発環境やCI/CD環境が必要になるし、インフラ屋さん視点だと、それはお客さんの方がやることだからインフラ屋さんがやる領域ではないし、仮にそういう体制で開発してたらインフラも自分たちで作ってそうですよね～、という感じで話していました。まだまだコンテナでやっていこう、っていうもの自体が広がってない印象です。
また、京都から来ている方とも繋がれたので、次は京都の勉強会で会いましょうって感じで良かったです。

ほか、アウトプットの話もでました。なかなか続けるの難しいっていうところは同じように感じていて、やはり小さいものを量産していくほうがいいよね、っていうところも共通認識。
毎日15分で書けるものを出す、など小さく続けるアイデアも得られて、これは真似しようとおもいました。やります。

他のLTはこんな感じ

すべてのスライドが公開されているわけではないので見れるものだけ。
個人的には1つ目のスライドがおすすめです。

ブログもあります。

kenfdev.hateblo.jp

f:id:rhymester19:20190628165232p:plain

2019開発合宿〜奈良県吉野〜

こんにちは。桜の蕾に春を感じるこの季節、皆様いかがお過ごしでしょうか？
先日、久しぶりの開発合宿を行いました。

1年ぶりの開発合宿

前回は、冬の金沢でした。雪が降り、とても綺麗だったことを覚えています。

blog.spookies.co.jp

今回の目的地は、当初は静岡や名古屋あたりを候補としていたのですが、 参加者全員が集まって夜通しで開発できる部屋があるとなると、やはりなかなか見つからず。
Airbnbでいろいろ探した結果、奈良の吉野になりました。

今回お世話になったのは、こちらの「時乃家 奈良吉野」さん

www.airbnb.jp

時乃家 奈良吉野

自然がすぐ近くにあり、
徒歩圏内にはスーパーやコンビニもないので
雑念にとらわれることなく、モクモクと開発ができるいい宿でした。
（とはいえお腹も減るので、買い出しの為にレンタカーは借りました）

今回の目標は

ゲームジャムです。
各2名でチームを組んで、Unityを使ってゲームを作る。
出来たゲームを公開まで持っていきましょうという内容です。
ゲームを作ったことがない、作品を公開したことがないというメンバーもいましたので、リリースボタンを押すドキドキ感まで楽しんでもらいました。

結果

6つのゲームが出来ました。

「Unity Deck Builder」
1人用デッキ構築型アドベンチャーゲーム！ 
20ターン目に出てくるボスを倒そう！ 
それまでにより多く勝利点を得るというハイスコア要素あり！

Unity Deck Builder | フリーゲーム投稿サイト unityroom

「PeckMan~動物たちの平和な森で~」
ここは動物たちの暮らす平和な森。 
今日はどんなことをして遊ぼうかな...。

PeckMan~動物たちの平和な森で~ | フリーゲーム投稿サイト unityroom

「10 second rebound」
10秒以内に右側にある穴に落とせ！ 
ステージエディット機能搭載！ 
加速・減速スキルでボールを制御しよう！

10 second rebound | フリーゲーム投稿サイト unityroom

「Medieval Labyrinth」
ブロックをうまく移動させて、全ての宝石を集めるゲームです。

Medieval Labyrinth | フリーゲーム投稿サイト unityroom

「トレジャーハンター」
マップを歩き回ってお宝を探せ！

トレジャーハンター | フリーゲーム投稿サイト unityroom

「刹那のババーン王」
あなたが真のババーン王だ！

刹那のババーン王 | フリーゲーム投稿サイト unityroom

オプション

みんなで料理、夜通しゲームなどなど。
京都・東京メンバーの交流もいい感じです。

晩ごはん食べながらもアイデア出し

f:id:spookies-nishimura:20190324121400j:plain:w500
なんか楽しそうに話してた

吉野といえば千本桜。
もちろん、まだ全く咲いてません。

f:id:spookies-nishimura:20190324120948j:plain:w500
脳内補完で満開の桜

まとめ

短い時間の中、普段のメンバーとは異なるチームで
それぞれアイデアを出しつつ、形にしていく良い経験が出来ました。
会社としても今年はアプリを出していくので、
それの良いきっかけともなりました。

次の合宿は暖かい季節に行きたいな。

集合写真

Cloud Native Kansai #2 に参加してきた

アンバサダー kubernetes community

f:id:masayuki14:20190315185959j:plain

こんにちは。アンバサダーの id:masayuki14 です。 前回に引き続き今回も参加してきました。
前回のレポートはこちら Cloud Native Kansai #1 に参加しました - スプーキーズのちょっとTech。 その後、雑誌のk8s特集などを読んだりして、以前よりは理解が深まったもののまだ動かすまでには至ってないので、今後も引き続き取り組んでいきます。

cnjp.connpass.com

前半には Cloud Native プロフェッショナルな発表が続き、後半のLTタイムでは〇〇やってみた系の話もあったので前回に比べバリエーションに富んだ内容でした。後半の発表は未経験の身からすると次のステップをイメージしやすいいい内容だったと思います。

1. Kubernetes and Cloud Native Products

前回参加できなかったことのお詫びから始まり、CyberAgentの紹介を経て本題に入りました。ラズパイで組まれたクラスタってカッコイイですね！ CNCF( Cloud Native Computing Foundation )とは何か、であったりCloud Native とはどういうものか、ということが今回も解説されました。 k8sを利用するにあたり、その背景にある思想がどういうものかを理解することが重要だということがわかります。

また、「Manifestが変更されたとき何が起こっているのか」を題材にしたControl Loopの話は玄人向けという感じで、つよい人になればk8sをOSのようにしてその上で自由に動き回れるのか、という輝かしい未来が想像できました。

むやみに社内ツールを作ろうとする人には それGoogle (が作っているOSS) に勝てるの？ というパワーワードで立ち向かいましょう。

2. 30分でわかる Google Kubernetes Engine

残念ながら資料はありませんでした。

Googleのサービスはほとんどすべてがコンテナで動いていて1週間で40億のコンテナが起動されているようです。すごい。 そもそもk8sはGoogleで使われていた独自のクラスタ管理システム Borg がベースになっています。 GoogleとLinuxFoundationが共同でCNCFを設立した時にOSSとして公開しk8sとなり、今でも多くの開発エンジニアが参画しているようです。

引き続きGKEの紹介となりました。先の話も含めマネージドk8sを使う場合はGKEを使うのがよさそう、っていう印象を受けました。

一番驚いたのが、Google Cloud Load Balancer を使えば単一IPで世界で一番近い場所で動くというものでした。Googleすっげー。そして大阪リージョンも年内にリリース予定とのこと。

3. Webアプリ開発向け ゆるふわDocker使いがCloud Naive開発に必要なetc.

メインのセッションの中では一番現場に近い話をされていたと思います。

k8sを使うってことは組織を変えるくらいの覚悟が必要だぞ、と。流行ってるっぽいからやってみよぜ！っていうのは止めろ、ということのようです。 システムの設計やデザインがそもそもCloudNativeを実現するための状態になっていないとk8sを導入することすら難しそうでした。 やはりCloudNativeの思想を理解し、そのロードマップに沿った形でシステムを作っていき、その先に覚悟を持ってk8sを導入しましょうというのが失敗のない手順なんだと思います。

発表された やっさん(@yassan168) さんは京都の方のようで、次の [京都] テクテクテック #8 サーバ監視や負荷テストどうやってるの？ - connpass にも参加されるようなので、その時にでもお話したいと思います。楽しみが増えた。

4. Datadog ここ掘れワンワン 春の陣

とりあえず1番かっこよかったです。可視化ってやはり大事だし、だからこそ見えてくるものがある、というのが伝わってきました。

コンテナ時代の監視はどうなるか、 cattle, not pets ペットではなく家畜のように扱うというのが1つの答えのようです。気になる方は14日間のトライアルを試してみましょう！とりあえずインストールすれば勝手にいろんなデータを集めて可視化してくれます。

[LT] 1. DockerからKubernetesへのシフト

個人的には一番ささった、というか知りたい部分の内容でした。Dockerは使ってるけど、そこからどうやってk8sに移っていったらいいんだろうという疑問を持っていたので Compose on Kubernetes を早速試してみたいと思います。

あら、わたしの端末にも。

f:id:masayuki14:20190319163711p:plain
ほら、あたなの端末でも Kubernetes

[LT] 2. VUIエンジニアが考えるVUIでKuberenetes

こんなことってありますよね。

  • デプロイ後にお使いを頼まれて、お使い中に状態を確認したい
  • 料理中にふと、ポッドの数を増やしたい

いやー、ほんとあるあるですよ。こんなときはこれ！

すばらしい！！

[LT] 3. DockerからKubernetesへのシフト

そして最後はこちら。楽しみながら開発して守備範囲を広げていくってのはエンジニアにとって大事だなあと思います。

まとめ

前回に引き続きMOTEXさんの広い会場で盛りだくさんの内容の勉強会でした。 Compose on Kubernetes を試しつつGKEあたりを使ってプロダクトリリースを夏までにやりたい、そう誓った早春の夜でした。

その他のブログなど

LT3 の発表をされた id:kenfdev さんのブログで紹介されています。 kenfdev.hateblo.jp

radiocat.hatenablog.com

dev.classmethod.jp

togetter.com

はんなりPython#14で発表を行いました

community アンバサダー python

f:id:masayuki14:20190215192735j:plain
NOTA Inc のロゴが大きく壁に！！

アンバサダーの id:masayuki14 です。先日開催された はんなりPython #14 - connpass の勉強会で発表を行いました。 はんなりPythonの会は京都のPythonコミュニティで私も運営に参加しています。

今回はNOTA Inc. さんのオフィスをお借りしての開催となりました。 NOTAさんが開発されているScrapbox を使って参加者同士のコミュニケーションを促進する試みなど新しいことにチャレンジした会になりました。

詳しい様子は公式ブログとScrapboxでご覧いただけます！

hannaripython.hatenadiary.com

scrapbox.io

発表について

今回の発表は、いま取り組んでいる個人プロダクトを進める上で実践していることをまとめてみよう、というところが出発点で作成しました。

1年前にはんなりPythonの会を始めるにあたって、「これをきっかけにPythonや機械学習をやってやろうじゃないか！」と意気込んでみたものの2ヶ月ほどしか続かなかったという過去があります。

この頃に作ったのが以下のスライドです。

  • はじめての Hello Python
  • Annaconda と Miniconda
  • Jupyter Notebook 入門

Presentations by Masa - Speaker Deck

どれもPythonを取り巻く状況や開発環境についての内容です。 当時の目的が「Pythonやってやろう」なので

  • Pythonの周辺知識を手に入れる
  • Pythonを動かす環境をつくる

をやってしまうと目的を達成したことになってしまったんですね。 これではその先へ進むことができません。 すでにプログラミングは十分やっているので、Pythonでプログラミングを学ぶわけでもなく、機械学習をつかって分析したいデータがあったり状況にいるわけでもないので、Pythonをやっていく動機がないわけです。

プログラミングという手段とモノづくりの楽しさ

プログラミングというのは

  • ソフトウェアを作る
  • 問題をコンピュータを使って解決する
  • 自動化する

などを達成するための手段であり、これらを達成するところやその過程に、モノづくりの楽しさがたくさん潜んでいます。 そのためプログラミング自体を扱うことは目的になりにくい性質があります。

プログラミングを始めた頃に、プログラムを書いて動かして「わー動いた、すごい！楽しい！」というのはもちろんあるんですが、ある程プログラミングの経験がついてくるとそういうわけにはいかなくなります。

まさに「Pythonやってやろう」がそういう状況です。

経験を積むほどに、プログラミングの先にある目的がはっきりしていないと、プログラミングが持つモノづくりの楽しさを感じることできなくなっていきます。

取り組んでいる個人プロダクト

そんな中、1ヶ月ほど前から個人プロダクトの開発を始めました。 これは1年前の「Pythonやってやろう」よりも先にある「プロダクト作ろう」が目的なので、手段としてのPythonを使っていくことができます。

これまでも個人プロジェクトを始めては放置、始めては放置、を繰り返しているので、今回こそはという思いがあります（いつも思っていますが）。 そんな中「フロー理論」にたどり着きます。何年か前にバズっていたので記憶にはあったのですが、改めて調べてみた結果「意図的にフロー状態を作って進めていけばうまくいくかもしれない」という思いに至りました。

「すこしだけ難しい課題を設定すること」をいかにうまくやるか、という方法を考えて試行錯誤した結果が、発表の中にもあるように「やれることにやりたいことを積み上げる」という方法です。

今の所うまくいっているのでこの調子でプロダクトの完成まで突っ走りたいと思います。

発表の構成

構成は以下のようにしました。

  • 問題提起
  • 解決のための方法論
  • 具体的な実践方法
  • まとめ

わりとよく見る構成だと思います。 発表後に振り返ってみると、試行錯誤の結果を抽象化して方法論としてまとめているので、順番としては逆になっていると気づきました。 これだとなんか堅苦しい感じになったんじゃないかなと。

  • 開発してるよ
  • 失敗したくないよ
  • 試行錯誤したよ
  • こうやったらうまくいったよ

みたいなストーリーで発表したほうが良かったかもなぁとは思いますが、どちらもやった上でフィードバックをもらわないとわからないので、 また別の機会があれば構成を変えて発表したいと思います。

懇親会で

閉会後の懇親会で「最近Pythonの勉強してるけどうまくいかなくて不安が大きかったけど、フロー理論の話でそれが腑に落ちたので、また仕切り直して勉強再開します」というような声を頂いたので、発表して良かったなという気持ちになりました。

ありがとうございました。

Cloud Native Kansai #1 に参加しました

アンバサダー community kubernetes

f:id:masayuki14:20190201190107j:plain

こんにちは。アンバサダーの id:masayuki14 です。先日CloudNativeKansai#1に参加してきました。

cnjp.connpass.com

CloudNativeJPコミュニティにより主催されていて、全国でミートアップイベントが開催されています。イベント名の通り関西では今回がはじめての開催でしたが、2時間半の間に7つの発表が詰め込まれている内容の濃いイベントでした。

全体的にKubanetesを取り巻く周辺の環境を紹介する内容が多く AWS, GCP, Azure といったマネージドサービスの利用環境が充実してきたんだなという印象でした。

Talk1 Cloud Native Journey with Kubernetes

1つ目の発表で印象的だったのは、CloudNativeComputingFoundationからKubernetes利用までのロードマップが示されているという部分。 現状はいくつかのDockerコンテナを用途に合わせて使っている程度なのでstep1くらいにいるけど、徐々にk8sを使うところまで持っていきたい。 経験者が語るように、はじめからマネージドサービスを使ってみようと思います。

Talk2 Amazon EKS Quick Dive

残念ながらKubernetesをまださわったことがないので、内容があまり入ってこなかったんですが、EKSを使うにあたりチュートリアルが用意されているとのことなので、その時が来たらお世話になりたい所存です。

Amazon EKS Workshop :: Amazon EKS Workshop

Talk3 AKS をいちばん楽に始める方法

CI/CDにはAzureで紹介されたDevOpsを使ってみようと思いました。個人利用だと無料だし。 GitHubがMicrosoftに買収されたので今後このあたりが連携しやすくなることに期待。 全力で思考停止していきたい。

Talk4 地方におけるCloud Native

情報のキャッチアップが大変というのは業界の常ですね。いろいろな情報に触れられることで、できそうなことの多さとできることの少なさのギャップに、うまく折り合いをつけていかないといけませんね。

個人的ピークはカブトムシのMRIでした。貴重な映像だった。

Talk5 GitOpsでKubernetesのYAML管理

GitOpsというワードは初めて知りました。いろいろあるんですね。 そしてここでもマネージドサービスを使ったほうがいいという知見を得ました。kubectl コマンド使うもんじゃないみたい。

Talk6 Kubernetesで機械学習基盤（GPU）を構築している話

マイクロサービスには気をつけようと思います。

発表中にcomets 発表スライド上にコメントが流せるサービスというサービスを使ってスライドにコメントが飛び交ってたので全然集中できないっていう。

Talk7 Get started on Cloud Native with Rancher !!

Rancherというプロダクトの紹介で初めて知りました。とても便利そう。

全体の感想

いろいろなサービスや技術や背景の思想がありますが、新しいものを使えばそれでいいというわけでもなく、目の前にあるチームや組織や文化やエンジニアのスキルなどの環境にあわせていかなあかんなぁと思いました。

個人的に今年の目標として Docker/Kubernetes の利用を掲げているので、1年かけて取り組んでいきたいと思っています。ちょうど個人的に作りはじめたプロダクトがあるのでこれと絡めて使っていけるとサイコーな感じです。

イベントのクロージングで第二回のイベントが公開されました。興味がある方はおはやめにどうぞ。

cnjp.connpass.com

その他のまとめなど

togetterまとめが作成されています。

togetter.com

chocopurin.hatenablog.com

他にも紹介しているブログを見つけたらリンクを追加しようと思います。

3D空間で「野球っぽい挙動」を表現するために学んだこと

はじめまして!アルバイトのkouhiraです！

いきなりですが、僕は三度の飯よりも野球が好きだと自負しています。三度の飯もかなり好きな方なので、野球に対する愛はそんじゃそこらの人には負けない自信があります。

そしてもちろん、プログラミングも大好きです。こちらはまだまだ勉強することの多い身ですが、毎日楽しくスプーキーズでもコードを書いています。

野球オタクがプログラミングという趣味を持った場合、当然「自分で野球ゲームを表現してみたい！」という目標を持ちますよね？(持ちませんか？)

僕もご多分に漏れずそんな目標を抱いていて、その足がかりとして、「Minecraft」というゲーム内で野球をするプラグイン(Steamゲーにありがちな「MOD」の亜種みたいなものだと思ってください)を趣味で作成しています。

そして先日、社内勉強会で発表する機会があり、僕はそのプラグイン作成時に学んだ知識について発表しました。(スプーキーズの社内勉強会は業務内容と微塵も関係なくても温かく聞いてもらえます！)今回は、その時に発表させていただいた内容を紹介させていただこうと思います！

前提としている環境はかなり特殊ですが、環境に依存しない内容に絞って紹介するつもりですので、もし役に立ちそうな知識があれば、スポーツゲーム作成などの際の参考にしていただければ嬉しいです！

※物理の知識について書いた箇所がありますが、書いている僕は高校物理すら習っていない根っからの文系です…なにか誤りなどありましたら申し訳ありません…。

前提

  • SpigotというMinecraftの公式サーバーソフトウェア上が動作環境。
  • MinecraftのJava Editionで動作するものなので、開発言語はJava。
  • イベント駆動（ゲーム中にこういうエンティティがこういう挙動を行ったとき、といったものに対応してリスナーを書いていく形式）で概ね書く。
  • イベントとは無関係に定期的に実行したい動作はRunnableというものを定義し、実行間隔などを指定して呼び出す形式。
  • 基本的なプレイヤーの動きはMinecraftにデフォルトで搭載されているものが利用でき、野球の根幹を成す「投げる」という動作は雪玉というアイテムを利用している。
  • 物体の移動は「速度」として三次元ベクトルを付与する形。
    • その瞬間(0.05秒=1tick)の(xの移動量,yの移動量,zの移動量)というのがここでの「ベクトル」(yが上下方向)

投球

  • 野球における投球を満足できる程度に再現しようとすると、球速や軌道をある程度プレイヤーの思うように操れる必要がある
  • つまり、変化球を実装しなくてはならない
  • 投球を行った時に起動し、以降毎tick実行されるRunnableの中で投じられた雪玉の運動のベクトルを少しづつ操ってやるようにした
  • プレイヤーがどの球種を投げようとしているかを指定するのは、Minecraftにデフォルトで存在する「アイテムに名前を付ける」という機能を用い、「この名前ならば毎tickこれだけの変化」というのを定義しておき、それぞれのプレイヤーが投球前に名付けを行う形にしている
import org.bukkit.entity.Projectile;
import org.bukkit.scheduler.BukkitRunnable;
import org.bukkit.util.Vector;

public class BallMovingTask extends BukkitRunnable {
    private Vector move;
    private Projectile ball;
    public BallMovingTask(Projectile ball, Vector move) {
        this.ball = ball;
        this.move = move;
    }
    @Override
    public void run() {
        // ボールの速度を取得し
        Vector velocity = ball.getVelocity();
        // 変化のベクトルを加えて
        velocity.add(move);
        // ボールの速度を上書き
        ball.setVelocity(velocity);
    }

}

問題

  • このままだと、「真上方向にストレート（上方向に変化するボールとして定義したとする）を投げた時」などに（特に）挙動がおかしくなる
  • 上に上に変化し続けて、ただなかなか落ちてこないというだけのボールになってしまう
  • 投球だけなら真上方向に投げるのがレアケースなのでそこまで問題にならないが、現実の野球でフライが伸びたり切れたりするのを考えると、この「発射後の軌道の変化」は打球にも適用したい
  • となると、真上のフライはそこそこありうる打球なのでよくない

    解決策

  • そもそも期待する挙動はなにか？
  • バックスピンで上方向に上がる打球というと現実でいうとキャッチャーフライ

  • http:// https://youtu.be/sdRoiiI8KeQ?t=5

  • 上記動画を見ると、必ずキャッチャーはキャッチャーフライ捕球時に後ろ(バックネット方向)を見て捕球している

  • 体の前に飛ぶ打球なのにわざわざ後ろを向いて捕球するのは、キャッチャーフライが後ろに向かって上がった後、前に戻ってきながら落ちてくる打球だから(キャッチャー経験者は小学生の時期に習います)
  • ゲーム内でもこの挙動を再現したい
  • つまり「ℓ（リットル）」の字のような軌道になってほしい

現実の物理

  • そもそも回転する球の軌道が変化するのは、「マグヌス効果」というものによるらしい
  • バックスピンなら、上部の空気がより早く後ろに流される→上の方の空気が薄くなってそちらに引っ張られるという原理（※自分のレベルでの理解）
  • 引っ張られる力は運動のベクトルと回転のベクトル表現の「外積」に比例する
  • 向きを回転軸（反時計回りになるように取る）、大きさを回転の大きさとして定義されるのが「回転のベクトル表現」
  • あるベクトルともう一つの他のベクトルに対し、そのそれぞれに垂直なベクトルが「外積」
  • 同じ方向のベクトル同士の外積は零ベクトルになる
    • 進行方向と回転軸が一致する縦のスライダーと、回転数がそもそも少ないフォークボールはともに重力によって「落ちる」球になる
  • ちなみに変化量はその瞬間の球速や回転量に依存するらしい
  • だいたいボールの直径を73mm、大気の状態が標準状態として、1Tickあたり1/8 * π * π * 1.205 * 0.073^3 * 球速 * 一秒あたりの回転数くらい（参考にしたスライド）になる。
import org.bukkit.entity.Projectile;
import org.bukkit.scheduler.BukkitRunnable;
import org.bukkit.util.Vector;

public class BallMovingTask extends BukkitRunnable {
    // 回転のベクトル表現（ややこしいので大きさは適当）
    private Vector spinVector;
    private Projectile ball;
    // 1秒あたり何回転するか
    private int rps;
    public BallMovingTask(Projectile ball, Vector spinVector, int rps) {
        this.ball = ball;
        this.spinVector = spinVector;
        this.rps = rps;
    }
    @Override
    public void run() {
        //バウンドしたり打たれてボールが死んだらタスクをキャンセルする
        if(ball.isDead()){
            this.cancel();
        }
        // ボールの運動
        Vector velocity = ball.getVelocity();
        if(spinVector.length() != 0){
            // 運動と回転の外積
            Vector actualMove = velocity.getCrossProduct(spinVector);
            if(actualMove.length() != 0){
                // 外積を一度長さ1のベクトルに直してから正しい大きさにする
                actualMove.normalize().multiply(1/8 * Math.PI * Math.PI * 1.205 * Math.pow(73/1000, 3) * velocity.length() * rps);
            }
            // 運動のベクトルに加える
            velocity.add(actualMove);
        }
        ball.setVelocity(velocity);
    }

}
  • 実際にやってみると、

javaw_20181212_000139F.gif (30.3 MB)

  • できた。

    打撃

  • 打撃を再現するためには、
    • 多様な打球が飛ぶ
    • タイミングが問われる
    • 振るコースや高さの調整が要求される
  • といった要素が必要だと考えられる
  • 一番簡単なのは、何らかの操作があった時に「この範囲ならバットに当たる」という箱を作って判定する形
  • 箱の表面で当たり判定を行うのではなく、箱の中にボールが入っているような位置関係だったら「当たった」ということにする
    • コースや高さは目線操作で設定
    • クリックのタイミングが問われる
  • バットに当たった後どういう打球になるかは、その箱の中心と当たった瞬間のボールとの位置関係から考えればいい
    • ボールの上を振るとゴロに、下を振るとフライに
    • 振り遅れると打球が後ろに飛ぶ
    • 概ね感覚に合うのでは？
  • 打球の強さはその二点の距離が大きいほど弱く、小さいほど強くなるようにする
    • 「芯」に当たればいい打球、外すと弱い打球
    • これにはn-距離を使うといい感じだった(1～0の変域で連続的な数値になるので)

問題

  • 「打球の回転」を定義しようとすると問題が発生する
    • 基本的にはバットとボールの位置関係が回転にも影響するのでそれを使いたい
    • 箱の中心からボールの位置までのベクトルをとり、それとボールの運動のベクトルとの外積をとれば逆に「その方向に切れていく回転」のベクトル表現が得られるはず
    • しかし今回の場合運動のベクトルとそれがまったく一致してしまい、結果が零ベクトルになる
  • 全く同じベクトルでさえなければ零にはならないため、
  • 「箱の中での位置関係」以外に打球の方向を左右するものが必要
  • 普通に考えれば「スイング軌道」（バット自体の動き）

    スイング軌道実装の困難

  • 「これが正しい」というのが存在しない
  • 選手ごとに全然違うのはもちろん、理論的にこれが正解というのもわからない
  • あれば球児は悩まない(愚痴)
  • 理論武装が出来ないので、「多くの人にとって納得できる」のをでっちあげる必要がある

    野球界の迷信を取り入れる

  • 正解が存在しないので、「それっぽく見える」やつを使いたい
  • 野球界には古くから「理想のスイング軌道」についての迷信がある
    • 「最短距離（直線）」
  • しかしこれはもはやほとんどの人が信じていない、古い考え方とされている（※僕の主観です）
    • 「野球　最短距離」とかで検索しても否定的な記述が目立つ
  • ここ5年くらい（※主観）で多くの人に信じられるようになりつつある新たな迷信（※主観）がある
    • 「最速降下曲線」というもの
  • 「任意の2点間を結ぶ全ての曲線のうちで、曲線上に軌道を束縛された物体に対して重力 (に代表される保存力) のみが作用する仮定の下、物体が速度0でポテンシャルが高い方の点を出発してからもう一方の点に達するまでの所要時間がもっとも短いような曲線」らしい。
    • 要するに「ある地点からある地点まで何かを転がすときに一番早く転がる軌道」
    • https://www.youtube.com/watch?v=L2_d7MPeJks
    • こういう感じらしい
    • 「構えたところからインパクトまでがこの軌道だったら一番早いはず」という理論で紹介されていることが多い
    • お昼のワイドショーでも「大谷翔平のスイング軌道がこうだ」と取り上げられたらしい
  • 実際はスイング時は重力以外も関係する（というか人間が振り回す力が主）なので…？
  • が、「多くの人が納得してくれる」は達成できそう

    実装

  • 詳しい説明は理解できていないが、最速降下曲線の式は、Minecraftのワールド上で描こうとすると(x=θ-sinθ, y=1-cosθ)という感じになるらしい
  • プレイヤーの目のところを出発地点とし、θの値を0-πまで増加させて描いてみるとこんな感じ 2018-06-01_17.01.18.png (286.2 kB)
  • これをスイング時のバットの縦の動きと考える
  • そのまま横向きに回転させる
public static Location getBatPosition(Location eye, double roll , int rollDirection){
    // 目の位置
    Location eyeLoc = eye.clone();
    // 与えられた角度の分だけ横回転させる
    eyeLoc.setYaw(eyeLoc.getYaw() - (float)(90 * rollDirection) - Math.toDegrees(roll));
    // 回転させた方向にまっすぐ伸びるベクトルを得る
    Vector push = eyeLoc.getDirection().setY(0).normalize();
    double theta = Math.abs(roll * 2);
    // 最速降下曲線のx座標を求める式
    double x = push.normalize().getX() * (theta - Math.sin(theta));
    // 最速降下曲線のy座標を求める式
    double y = -(1 - Math.cos(theta));
    // 最速降下曲線のx座標を求める式
    double z = push.normalize().getZ() * (theta - Math.sin(theta));
    // 元の目の位置にそれぞれ得られた値を足した座標を得る
    return eye.clone().add(x,y,z);
}
  • こうなる 2018-06-01_18.12.51.png (184.7 kB)
  • この軌跡をどこか任意の点で微分して得られたベクトルを「バットのスイングによって与えられる運動」として加える
  • 自分は一番手っ取り早いので近くの2点を選んでその2点の差をとって使っている
  • 基本は一番低くなっているところとそのすぐ近くのもう一点
  • ※この軌跡をまるごとスイングとして使うのではなく、あくまで「バットに当たった瞬間のバットの動き」としてこの軌跡の一部分を用いる
  • 箱の中心からボールまでのベクトルと違うベクトルになるため、打球の回転のベクトルを得ることができるようになった

    副作用

  • 基本的には最速降下曲線の一番「底」の部分を使っているが、「任意の点」を選んでスイングのベクトルを得ることができるようになった
  • 一番底の部分を微分するとY方向の傾きは小さくなるはず
    • いわゆる「レベルスイング」=標準的なスイング軌道と考えることができる
  • 底以外の部分を使うことで打者の打球傾向をある程度変えられる
    • 底に至るより前のところを使えばゴロが多い「ダウンスイング」に
    • 後の方を使えば「アッパースイング」になる
    • パワプロで言う「弾道」のような要素として使える
    • ちなみに調整を行わずさっきの関数をそのまま用いると横回転の度合いも変わってくるため、「フライの打ちやすさと引っ張りの多さ」「ゴロの打ちやすさと逆方向への打球の多さ」が相関してしまうが、
    • それも統計上正しいようなのでよしとしている。

      参考資料

  • Spigot公式JavaDoc
  • 『野球の投手が投じる様々な変化球の特徴 ～移動速度，回転速度，回転軸の向きに着目して～』
  • ゴルフゲームでUnityの限界を突破する方法
  • Wikipedia「最速降下曲線」
  • 物理のかぎしっぽ「最速降下曲線」
  • BASEBALL GATE 「プルヒッティングのすすめ」