キャラスロ、作ってみた

事の発端は、↓の記事である。そしてこちらのツイート

エロゲの立ち絵をランダムに並べたら、いろいろな役ができるというものだ。
これを実際に軽くではあるが、組んでみた。

立ち絵データは『萌え時計』のものだ。萌え時計は全身のデータがすでにあり、そこから切り抜いて貼り付けているので、キャラスロもこうしてほぼ全身で表示することが出来る。
惜しむらくはね、解像度がね……。
ホントはもっと高繊細なデータで出したいんだけど……作るのが滅茶苦茶めんどくさいのでとりあえず萌え時計と同じデータを使っている。

プログラムは単純にランダムな立ち絵を並べるだけだ。
それ以上のものではない。
今後の必要な処理として以下があげられる。

  1. 大きさや位置がバラバラ
  2. 演出
    スロットマシーンみたいにキャラがリール状に表示されるとか、当たり・外れの派手な演出とか。
  3. 役決め
    どうそろうとどれだけの価値があるのかとか。たとえば「同じ作品で揃う」「同じキャラで揃う」「幼馴染みキャラで揃う」「ロリキャラで揃う」「イモータル キャラで揃う」などなど。
    これ、真面目にやろうとすると確率を計算して、確率が低いものほど点数を高くしないと行けないとか、わりと面倒だったりする。
  4. ポーカーなのか、スロットなのか、麻雀(ドンジャラ)なのか
    ポーカーなら 4 キャラ、スロットなら 3 キャラ、麻雀なら 5 キャラでやるのがよいと思っている。

まぁ、いまめっちゃ忙しいので、果たして続きが作れるかは謎だけどw


立直

叶(同時に作品も統一)

これも立直

汐!全部制服だったらさらに役が上がってた

キャラは立直だけど、下着という役が成立

こちらは麻雀用。お嬢様という役(笑)

切り替えボタンと平吉

同人サイトのプロダクト(作ったもの紹介)ページに切り替えボタンをつけた。小説か、絵関係か、デジタル コンテンツかをカテゴライズした感じだ。それぞれのページを作るのでもよかったんだけど、パッと切り替わるといいかなと思って Javascript で実装した。
仕組みは非常に簡単で、小説・絵関係・デジタル コンテンツ全てのページを重ねて置いてあって、Javascript で表示・非表示を切り替えているだけである(CSSdisplay 属性)。

こういうことをしたい人ってけっこういるので、簡単に実現できる WordPress のプラグインがあるといいのになぁ……と思った。もしかしたらすでにあるのかもしれない(汗)。

同人サイトの話題が出たついでに、懺悔話(汗
今年送った年賀状には QR コードがついてて、年賀状の絵をダウンロード出来たんだけど、同人サイトを SSL したとき、この年賀状の絵もコピーするのすっかり忘れててダウンロード出来ないようになってたっていうお話。
ただ、このダウンロードってしてる人いるのか謎だったので、たぶんあんまり迷惑かかってない……はず(ぇー

さて、今日行ったのはセレスティン ホテルに入っている葱や平吉という和食屋さんというか定食屋さん。このホテルには一階に飲食店とコンビニが入っているんだけど、どれも際コーポレーションのお店なのでこの平吉もそうなのだと思う(そして芝公園に来てから、際コーポレーション経営だと思われる店には、すでに二つ入っている→タイガー餃子PAGLIACCIO)。
そしてすごく繁盛していて、中はほぼ満席。並び客もいたが、すぐに案内されていたのでボクらも入ることにした。

ボクらが入ったのは 13 時ちょっと過ぎなんだけど、その段階でいくつかのメニューが売り切れてた。ボクが頼んだのはチキン南蛮。他の写真は焼き魚定食と鍋焼きうどん。チキン南蛮はタルタルソースがすごく卵! マヨネーズ感よりも圧倒的な卵感、そしてフワフワ。お肉も柔らかくて、チェーン店なのにすごいなぁと思った。際が作るものはボクの舌と相性がいいらしい(ぁ

恐るべき iPad Pro の力と、衝撃のくら寿司

今日はずっと出先でプログラミングをしていた。
iPad Pro を買ってからと言うもの、ほとんど出番がなかったので(買ったあと定期的に入っていた打ち合わせがどんどんなくなってしまったという経緯がある)、いよいよ iPad Pro が活躍するときが!
しかも出先で PHP + HTML5 + Javascript の開発である。
腕がなるっていうかボクのプログラミング技術はどうでもよくて、iPad Pro がうなる!

開発手法は iPad Pro を使うものの RDP を使って自宅の仮想開発マシンにログオンして開発するというものだ。つまり見た目は iPad なんだけど画面に映っているのは Windows っていう(笑)。なので Windows で開発しているのと基本、変わらない。

驚いたのがバッテリーだ。ネットは Wi-Fi4G 回線はほとんど使わず。
動画とか画像とか扱う作業はなかったものの、14:30 から 20:30 までぶっ通しで作業をしたんだが、なんと残り 54% だった。半分も使ってない! 念のためモバイルバッテリーとか持って来てたんだけど、まったく出る幕なし。すげー、こんなにもつの、iPad って!?
ただこの省電力に大きく関わっているのは RDP である。そもそもウェブをレンダリングする必要がないのだ。これでかなり電力消費がおさえられることが解っている。そして通信するデータ量もぐっと抑えられている。したがって通信機器への負担も少ない。

ところで今回、プログラミングでハマったのが Javascript だ。どうしても意図通りに動かない部分があって、これがなかなか解決できなかった。しかも確証はとれてないのだが、どうも Google Chrome で起きてるっぽかった。というのもボクは Edge でデバッグするのだが、Edge では特に起きていなかったからだ。
原因は変数に status という単語を使っていたから。これを別の単語にしたら動くようになった。
status って Javascript で予約語なのかな……??
ざっとググった感じでは解らなかった。
まー、変数名が問題だというのに気付くのに二時間くらいかかってたんじゃなかろうか。もー。

一通り終わってから、夜ご飯に出た。
どこに行くか色々迷ったものの、最終的にくら寿司に落ち着いた。
くら寿司、超久しぶり。ボクがくら寿司に行ったのって東京に進出したばかりの頃で、びっくらぽんだっけ? ああいうのがなかった頃だったと思う。100 円の低価格回転寿司というと、ボクはもっぱらはま寿司に行ってた。

合理化ははま寿司でも閉口するくらい(要するに客の方に負担を強いることによってコストを下げている)なのだが、くら寿司はさらにその上を行っていた。でも注文する端末がすごく速くて反応がいいね。液晶もキレイ。交換したばかりなのかなぁ?
そしてメニュー内容の更新も頻繁。売り切れになったものはすぐに消えるし、補充されると(?)すぐ復活する。この辺、はま寿司はまだまだだ。さらに回っているお寿司にはカバーがかぶせられている。長時間外に晒されることを考慮しているのだろう。
また、注文した寿司は別レーンでやってくる(つまりレーンが二段になっている)から、間違うことも基本的にない。
すごいなぁ。
この辺はプログラミング好きなら、内部でどうやってるのかとか色々想像すると面白いかも知れない。

だが、肝心の寿司が……寿司……なのか? というものも多かった(笑)。
ボクは楽しかったから、まぁエンターテイメントとしてとらえたけど一緒に行った人はかなり不機嫌だったご様子。不機嫌って言うか、呆れたって言うか、ビックリしたって言うか、そんな感じ? 合理化とかカレーとかラーメンとかもいいけど、寿司屋を名乗ってるんだからまずその寿司をちゃんとしなさいよ、とのこと。

ごもっとも。

個人的にははま寿司の方が寿司もレベルが高い……ような気はした。
なんだろうね、くら寿司は完全に割り切ってるっていうか、そういう潔さを感じる。「ウチで寿司食っても美味くないよ。でも何でも揃ってるし子供を連れてきても困ることはないよ」っていうのがひしひしと伝わってくると言うか何というか。
もうプライドもなにもないなーっていうかw

そんなわけで、衝撃のくら寿司でした。たぶん今後もはま寿司に行くと思う。
でも聞くと、低価格回転寿司屋業界で一位はスシローなんだってね。スシローは入ったことないんだよねー。今度行って見るか。

ふくの鳥と AI と WordPress

今日は同僚が鶏の唐揚げが食べたいというので、いろいろと彷徨った結果、『ふくの鳥』というお店に入った。ランチメニューがどれも鶏の唐揚げだったからだ。鶏の唐揚げって言うと、あの丸っこいのを思い浮かべるのだけど、ここのは全て一枚肉だった。
同僚は油淋鶏、ボクはカレーを選んだ。

カレー屋さんじゃないカレーはあれね、業務用ね。
当たり前か(^^;

鶏の唐揚げは美味しかったと思うんだけど、カレーがぬめぬめっとしてた。
イマイチ!

ポイント カードについて、このあいだひどい目に遭ったわけだけど(そこまで言う?w)、ふとこの間 THANK で見たロビを思い出して、そもそも AI が普及したらポイント カードいらないじゃん! ってことに気付いた。
いや、AI とかそういう単語を使わなくても現状でも可能だ。
要するに顔認識システムを店頭に置いておいて、会計の時にその人が常連さんなのかどうかを判別して貰えばいいのだ。その人の来店回数や今まで使ったお金の積算を表示するなんて簡単だ。そしてポイントの付与も楽々だ。
たくさん貯まってたら「○○ポイントたまってますけど、お使いになりますか?」と、店員が聞けばいいのだ。自動割引でもイイし、レジのタッチパネルに表示して使うかどうかを尋ねるのでもいい。

いやー、明るい未来が見えてきそうだ。これで財布が金も持ってないのにパンパンなんてことはなくなりそうだ。頼みますよ!

今、仕事をいくつも抱えているんだけど、どれもが PHP + HTML + Javascript な案件なのね。で管理画面があったりとかいろいろするんだけど、クライアントさんには WordPress でやれるようにすることが多い。要するにデザインとかウェブサイトそのものはクライアントさんが作って、システムというか仕組みの部分はボクが組んで、クライアントが作った WordPress 内に組み込むといった感じだ。

ただ 100% WordPress で済むようにはしていなかった。
ボクが作ったシステムの UI は、ボクが自分で HTML を組み、CSS を組んで提供していた。
でもこれだと見た目が良くない。ボクはデザイナーではないからね。それにシステムごとに CSS を組むのがめんどうくさかった。

そこでボクが作ったシステムを全部 WordPress 側で呼ぶ仕組みを作った。
これでボクが作ったシステムも全部 WordPress を通して表示されるようになった。UI も統一されるし、デザインも統一されるうえにクライアントも操作に戸惑うことも減る(まったくなくなるわけではない)。
今までは WordPress とボクのシステムとで管理画面をアクセスする場所が違っていたりしたので、その辺も統一された。

本当は SS とか貼りたいんだけど、開発中なので貼れない……

信号のない横断歩道で…

信号のない横断歩道で横断したい歩行者がいたばあい、車をとめて譲るってのがある。確かに車を運転していて、これを守ってる人って少数だ。ただ車を運転している側からすると、けっこう見落とすのよ。時速 40 ~ 60km/h で走ってて、信号のない交差点にさしかかっても、そこにいる人が歩行者なのか横断者なのかちゃんと確認していないし、いたとしても止まるものだという意識がすっかり抜け落ちてる。あとは気づいた時には急ブレーキになってしまうとか。

さらにもう一つ問題なのが、後続の車だ。ボクが横断歩道手前で止まると後ろの人はなんでボクが止まったのか解らないらしく、追い抜こうとする。これのせいで横断者が轢かれそうになるということを二回も経験して、後続車がいる場合、ボクは止まらなくなってしまった。

じゃぁ一人のときは止まるのかというと、先に説明したミスがなくちゃんと止まれる距離で歩行者を発見できたら止まる。だがこれにもジレンマがある。たとえば 40km/h から停止するのには 16 秒かかる。対向車も含めてボクしかいない場合は、止まらずに通り過ぎた方が歩行者もすぐに渡り始められるのだ。横断歩道で止まるのは、後続車や対向車がいるときにこそ発揮されることなのである。なかなかもどかしいというか、悔しい問題だ。

仕事でブラウザ上に 3D 表示をする必要が出てきた。おかしいなぁ、ボクは会社ではプログラマではないのだが……(汗
まぁとりあえずマップとかオブジェとか表示してグリグリ動かせるようにはできた。
さて、これから先、ちゃんと組めるんだろうか……

ゴーンさんが逮捕された件、忙しいので情報収集が中途半端なんだけど、勢力争いの延長のように見える。法を犯しているのかどうかもよく解らない。あと犯していたとしても 1000 万円以下の罰金か懲役三年以下だったかな? 50 億円でそれならもうなんか、逮捕する意味あるの? とか思ってしまう。
あとゴーンさんを追い出して、日産はちゃんと自立できるんだろうか?
自滅しない? 大丈夫?? とか思うけど、とくに日産に何の思い入れもないので、どうでもいいやーってなった(ぁ

また気温の話かよ?

昨日は猛暑日で 37 ℃だったのね。で、天気予報で「昨日よりも 6 ℃も低いです」って言われたんだけど、それでも 30 ℃ オーバーなんだよなぁっていう、ただそれだけなんだけどさ、ボクらの暑さの基準が変わりつつあるような気がして、イヤだ。

本来なら 30 ℃を超えたら暑いはずなのに、猛暑日じゃないってだけでホッとするのはなんか違う気がするんだ。暑いものは暑い!

萌え時計って言うのがあるんだけど、コイツをクリックすると任意のページを開くことができるようになっている。つまりリンクが設定できるんだけど、マウスを萌え時計の上に持っていってもどこに飛ぶのかは押してみるまでは解らなかった。

それはそれで不自然だなと思い、リンクへ飛ばす方法を変えて、マウスを萌え時計に載せるとリンクが出るようにした。具体的な処理内容は今まで Javascript で window.open を呼び出していたのを、getElementById で取得したオブジェクトの href メソッドにリンク先を代入するようにした。

ただ、スマートフォンではオンマウス(マウスオーバー)の概念がないので、結局どこに飛ぶかはタップしてみるまで解らなかったりする……。ほんとこれ、何とかならないかなぁ。オンマウスってほんとに便利な機能なのになぁ……。

iOS はクソだなぁ……

 

事の発端は 3/6 に作った福引きシステムを Bluetooth のシャッターボタンでも引けるようにするという要望だった。夏コミが近くなり、この福引きシステムを夏コミにも使うのだが、前回、お客さんがなかなか引けないという場面があり、列が伸びてしまったらしいのだ。

お客さんがひけなかった原因は、単純に「タッチ」しなければならないのに、画面にタッチした時、指を画面から離す前に指で画面をこすってしまい、タッチとして判定されなかったためだ(スワイプとして判定されてしまう)。緊張したのかなんなのか解らないが、そういうお客さんが多かったらしい。なかなか引けなくて後ろの列が伸びてしまった。列が伸びると次のサークルを回りたい人はさっさと諦めて引かずに行ってしまうらしい。
そこで対策としてリモコンのシャッターボタンを押して貰えば、失敗が少ないのではないかというわけだ。

リモコンのシャッターボタンはキーとしては【Volume Up】の信号が送られてくる。
確かにスマートフォンを横向きに構えると音量ボタンがちょうどシャッターボタンぽい位置に来る。
なので Javascript でシャッターボタンを拾うように組んでみた。とりあえず Windows の Edge で実験。ちゃんと動いた。
ところが iPhone ではウンともスンとも言わない。んー? なんだ?
シャッターボタンは拾えないのかな?

そこで、どんなキーを押しても動くように組み直してみる。
それでも iPhone だと何も起きない。おいおい、どういうことだよ。
そこで気づいたのが、iPad だ。ボクの iPad にはキーボードが着いている。これなら絶対に動くはずだ!!

ところが、iPad + キーボードでも動かなかった!!

ここに来て初めてボクはググった。そしたらなんと、画面にキーボードが表示されていないと、iOS ではキー割り込みが発生しないのだった!!! なんだこのクソ仕様は!!! つまり Javascript では何をしようがどうしようが Form の上か画面にキーボードが表示されていないと、キー情報をとることができないのだ(ちなみに Android はできる)。

というわけで、リモコンのシャッターボタンでは iOS ではクジは引けない。回避方法はないのだ。この一連の変更はすべて無駄となった。

で、結局どうしたかというと、スワイプでも引けるようにとりあえずした。
ただこれでお客さんの失敗が減るかどうかは、夏コミに実際に引いてもらわないと解らない。それはまたその日の日記に。