WebGLで18+ゲームを作って、負けると「装備を脱ぐ」🔞

続き:《同じアニメーション、3つの技術スタックで実装したらどう違うの?》 WebGL による二次元じゃんけんゲーム。 ルールは普通: グー > チョキ チョキ > パー パー > グー でも面白いのはここ: 負けると服を脱ぐ。 ええ、それだけです。単純かつストレート。 きっかけは「スプライトシートを研究したかった」 最初はゲームを作るつもりなんてなかった。 ただ研究したかっただけ: atlas sprite レイヤー合成 アニメーションカット こんな技術要素。 それで考えたんです:「実際に使える場面がないと?」 そして思い付き: じゃあ、二次元脱衣じゃんけんにすればいいと。 そしたらプロジェクトが暴走し始めた。 このプロジェクトで一番大変だったのはゲームロジックじゃない じゃんけんのルールはシンプルすぎる。 本当に大変だったのは:服のレイヤー管理 キャラクターは「1枚の完成した画像」ではなく: ベース画像 (全裸バレ防止のため、わざと暗号化済み) 服 A 服 B 服 C アクセサリー 遮蔽レイヤー 重ね続ける。 「脱衣」の正体はレイヤー管理 プレイヤーが勝った: 設定された順番で服を1枚除去 コンピュータが勝った: 逆順で服を着せる 聞こえるのは簡単。 実際は山のような問題にぶつかる: 例えば「ベース画像が一瞬見えてはいけない」 これは特に重要。 もしこうすると: 古い服を先に消す 新しい服を後で追加する その一瞬ベース画像がチラ見えする。 見た目がすごく変になる。 なので後で:reveal カバーロジックを使うことにした。 新しいレイヤーが即座に上に被さる。 極力避けたい: 「裸が1フレーム映り込む」 プロジェクト自体は不真面目に見えるけど 少なくとも技術的には美しくありたい。 WebGL はここで本当に心地いい このプロジェクトは最終的に WebGL で実装した。 理由はシンプル:レイヤーが多すぎる。 ...

2026年6月13日 · 1 分 · MoeJue

同じアニメーションを3つの技術スタックで実装した場合の違い

最近、なかなか面白い小実験をやってみました。 二次元キャラクターのちょっとしたアニメーション効果を、それぞれ: WebGL Canvas 2D 純 DOM + CSS の3つの方法で実装し直しました。 効果自体は複雑ではありません: まばたき 眉毛/下まぶたの連動 汗のゆらゆらした揺れ アホ毛の振り動き でも本当に面白いのは、「作れた」こと自体ではなく: 同じものを、3つの技術スタックで実装したとき、どれくらい差が出るのか? というところです。 本質的には「フロントエンドグラフィクス色の濃い」再現実験でした。 最初はただアホ毛アニメーションを再現したかった インスピレーション元:https://tamanidamani.itch.io/nijikas-ahoge 当時のシンプルな思い:「自分だったらどう実装する?」 そしてやるほどに熱中してしまい、最終的にこうなりました: じゃあ、WebGL、Canvas2D、DOM の3パターン全部作ってみよう。 そうしてリポジトリは今の形になりました: canvas/ canvas2D/ dom/ 同じ効果を3つのバージョンで実装しています。 まず結論 一言でまとめるなら: WebGL が最強だけど、Canvas2D が一番書きやすくて、DOM がビジネス向け 1. WebGL バージョン:「本当のゲーム開発」に一番近い このバージョンが一番手間がかかります。 なぜなら本質的には「フロントエンドアニメーション」ではなく:GPU グラフィクスプログラミング だからです。 どう実装しているのか? コアとなる考え方は: 背景レイヤー1枚 スプライトを重ねていく shader で描画制御 JS でアニメーションパラメータを動かす 例えば: アホ毛の回転 まばたきの切り抜き alpha ブレンド これらはすべて GPU 側で処理されます。 だんだんとこういうものに触れるようになります: uniform texture shader UV 頂点座標 テクスチャ座標 そして笑顔が消えていきます。 でも WebGL は本当に強い 要素が増えてくると、WebGL の「全然平気」という感覚が際立ちます。 特に: ...

2026年5月29日 · 2 分 · MoeJue

AEはできませんが、コードは書けます

✨ 緒山まひろの隠れ家 ✨ 🌸 緒山まひろの隠れ家へようこそ 🌸 わぁ!私の秘密基地を見つけちゃったんだね!(*≧ω≦) ここは緒山まひろの個人サイトだよ。かわいいアニメーションと面白いコンテンツがいっぱい! ここでは、私のお気に入りのアニメ、マンガ、ゲーム、そして日常のささやかな幸せをシェアしていくね~ 💕 私について 💕 私は緒山まひろ。エロゲを愛する引きこもりのダメニートだよ。 アニメ、マンガ、ライトノベル、そしてかわいいものが大好き! 好きな色はピンクと水色! ∩∩ (・ω・) <- 私だよ! _| ⊃/(__ / └-(___/ 🎀 サイトコンテンツ 🎀 🌟 素敵なアニメーション 📚 私のプライベートフォト 🎵 おすすめの音楽 📷 日常のワンシーン 🌈 関連リンク 🌈 🎭 デモ: https://mahiro.moejue.cn/ 🏠 個人ブログ: https://MoeJue.cn/ 🐱 GitHub: https://github.com/iAJue/Mahiro 📧 公式サイト: https://onimai.jp/ 📝 著作権情報 📝 このサイトは @Moejue によってデザイン・開発されました サイト内で使用されているすべてのアニメーション、マンガの画像、キャラクター、および関連コンテンツの著作権は、原作者(ねことうふ)およびその発行元(スタジオバインド、一迅社)に帰属します 著作権侵害の可能性がある場合は、上記の連絡先までお知らせください。速やかに関連コンテンツを削除いたします GNU GENERAL PUBLIC LICENSE Version 2 Copyright © 2025 MoeJue. All rights reserved. 💌 スペシャルサンクス 💌 緒山まひろを好きでいてくれるみんな、ありがとう!(●’◡’●) ...

2025年8月23日 · 1 分 · MoeJue

マルチチェーン対応は、想像以上に複雑だ

初めてのマルチチェーンウォレット統合の実践的考察 ようやく時間ができてコードを整理できるようになりました。Web3プロジェクトでマルチチェーンウォレット接続機能を導入する際、主にEthereum、Polygon、BSC、Solanaが関わってきます。一見すると「互換性のあるロジックをいくつか追加するだけ」のように思えますが、実際に実装してみると、多くのことが思ったほど単純ではないと気づきました。 this.networkConfigs = { ethereum: { chainId: '0x1', // 1 chainName: 'Ethereum Mainnet', nativeCurrency: { name: 'Ethereum', symbol: 'ETH', decimals: 18 }, rpcUrls: ['https://eth-mainnet.public.blastapi.io'], blockExplorerUrls: ['https://etherscan.io'] }, polygon: { chainId: '0x89', // 137 chainName: 'Polygon Mainnet', nativeCurrency: { name: 'MATIC', symbol: 'MATIC', decimals: 18 }, rpcUrls: ['https://polygon-rpc.com'], blockExplorerUrls: ['https://polygonscan.com'] }, bsc: { chainId: '0x38', // 56 chainName: 'BNB Smart Chain', nativeCurrency: { name: 'BNB', symbol: 'BNB', decimals: 18 }, rpcUrls: ['https://bsc-dataseed.binance.org'], blockExplorerUrls: ['https://bscscan.com'] } } マルチチェーンは単に「複数のウォレットをサポートする」ことではない 最も強く感じたのは、チェーンが異なればウォレットのインタラクション方法も異なり、SDKの考え方すら違うということです。イーサリアムエコシステムでは統一されたWeb3.jsで多くのロジックを処理できますが、Solanaになると、完全に別のシステムであることがわかります。プロバイダーの接続、接続フロー、PublicKeyの構築方法が異なり、ネットワークの遅延や安定性までもがユーザー体験に影響を与えます。 ...

2025年7月5日 · 10 分 · MoeJue

マルチプラットフォーム記事同期ブラウザ拡張機能 - ArticleSync

ArticleSync - マルチプラットフォーム記事同期プラグイン ArticleSyncは、ユーザーが複数のソーシャルプラットフォームに記事を簡単に同期・公開できるブラウザ拡張機能です。ローカルの下書きから、知乎(Zhihu)やBilibiliなどの主要プラットフォームに記事を公開することをサポートしています。これにより、異なるソーシャルメディアプラットフォーム間で記事を同期する作業が、シンプルかつ効率的になるワンストップソリューションを提供します。 ブラウザ拡張機能の仕組みに基づき、ローカルでログインしているアカウントを自動的に検出し、アカウント情報の漏洩や環境の異常といったリスクを防ぎます。 Chrome Manifest V3ブラウザ拡張機能の標準に基づいて開発されており、カーネルのバージョン要件にご注意ください。 背景 ご存知の通り、私は最近、いくつかのブログプラットフォームと多くのソーシャルサイトを新たに使い始めました。もし、それらすべてで活発に更新を続けたいと思ったらどうすればいいでしょうか。(私がまだ生きていることを証明するために)ついでに、ワンクリックで記事を転載することもできます。 私が最も頻繁に更新するのは自分の小さなサイトですが、他のプラットフォームはたまにしか更新しません。しかし、毎回手動で投稿するのは面倒です。そこで、ローカルでログインしているアカウントを自動検出し、自動で投稿してくれるプラグインが作れないかと考えました。 「自分のことは自分でやる」ということわざの通り、数日間いじくり回して、なんとか使えるものができました。残りの部分は時間があるときに更新します。お金をくれるなら話は別ですが。 このプラグインにはまだ多くの未完成な部分があり、本番環境で複数のプラットフォームでのテストも行っていません。エラーが発生するのはごく普通のことですので、その際はIssueを提出するか、自分で修正してPRを送ってください。てへぺろ〜 話の邪魔にならないように、スクリーンショットは最後に載せておきました。 それと、オープンソースは大変なので、スターを付けてくれると嬉しいです。へへへ〜 本当は、私のコミュニティプラットフォームを自動でフォローするような、個人的な機能を追加しようかとも思いました。 機能と特徴 マルチプラットフォーム対応:知乎(Zhihu)、Bilibiliなどの主要プラットフォームや、自作のオープンソースCMSシステムをサポートしています。 ステータス追跡:プラグインのインターフェースで記事の同期状況を確認できます。 アカウント管理:プラグインに連携されている各プラットフォームのアカウント情報を確認できます。 高い拡張性:開発者はアダプターパターンを通じて、簡単により多くのプラットフォームに拡張できます。 安全性と信頼性:ブラウザ拡張機能の仕組みに基づいているため、アカウントの安全性を確保し、情報漏洩などのリスクを回避します。 Todoリスト [ ] 独立した記事エディタ [ ] 画像のワンクリック同期 [x] MarkdownとHTMLの相互変換 [ ] サードパーティの画像ホスティングサービス [ ] 複数アカウント管理 [ ] マルチOSクライアントバージョン [ ] ワンクリックAI要約 [ ] 動画の同期 [ ] タグ、カテゴリのサポート [ ] より親切なエラーハンドリング [ ] より多くのプラットフォームへの対応 対応プラットフォーム メディア カテゴリ ステータス URL 対応形式 更新日時 Bilibili (哔哩哔哩) 主要セルフメディア 対応済み https://bilibili.com/ HTML 2024/10/13 知乎 (Zhihu) 主要セルフメディア 対応済み https://www.zhihu.com/ HTML 2024/10/13 博客园 (Cnblogs) ブログ 対応済み https://cnblogs.com/ HTML 2024/10/14 新浪头条 (Sina Headline) 主要セルフメディア 対応済み https://weibo.com/ HTML 2024/10/14 Emlog オープンソースCMS 対応済み https://www.emlog.net/ HTML 2024/10/14 WordPress オープンソースCMS 対応済み https://cn.wordpress.org/ HTML,Markdown 2024/10/14 Discuz! オープンソースCMS 対応済み https://www.discuz.vip/ Markdown,Text 2024/10/15 インストール手順 リポジトリをローカルにクローンします: ...

2024年10月16日 · 2 分 · MoeJue