パスワードを忘れた? アカウント作成

過去1週間(やそれより前)のストーリは、ストーリアーカイブで確認できますよ。

15263561 comment

yumeのコメント: Re:おいコラ!われ! (スコア 1) 5

by yume (#4016286) ネタ元: またブラウザゲーム作ったよ〜〜

ごめん、SOPHOS UTMがなんなのかわからない。それがセキリュティソフトなら、itchのブラウザゲーム で危険なものは無いからドメインごと無視して大丈夫……だと思うよ。
ブラウザで起動しただけでやばいものとか、いまどき作れるのかな? 詳しくないけれど。

15263484 journal
日記

yumeの日記: またブラウザゲーム作ったよ〜〜 5

日記 by yume

itch.ioで『Bad Guy TV』を公開したよ。
ファンタジーテレビ番組風のチキンレースゲーム。
Mini Jam : 78 の参加作品。期間は72時間。

今回の制限は「You are the Bad Guy」。
Bad Guyは「悪役」という意味だけど、「悪いやつ」を意味するとは限らない、って『シュガーラッシュ』で言ってたのを思い出して、じゃあ悪役を演じる何かを作ろうか。と考えた。
で、最近遊んだ『Loop Hero』をもっと単純化できないかなぁ、というアイデアと合体して「ゲストヒーローを倒れる直前まで戦わせる危ないテレビ番組」という設定に。

ゲームには「ゲストヒーロー」が登場し、勝手に右に進んでいく。
右端に到達するたびに、プレイヤーは次の二つを選ぶ:
・悪役をステージに追加する。
・ボス戦を開始する。
これ以外の操作は不要!

15260172 journal
日記

yumeの日記: メデューサ・ゲーム改・10 1

日記 by yume

◉高さの表現(ぼつ)
このゲームは典型的な2D top-down視点だ。
完全な真上から見るわけではなく、擬似的に少し角度をつけて見ているタイプ。
こういうタイプのゲームの場合、ゲームオブジェクトの原点は足元にするものが多いと思う。
足元を原点とすれば、高さの違うオブジェクト同士でも何も考えずに配置できるからだ。

しかし、このゲームは「視線」が重要なゲームなので、足元を原点としてタイルを敷いていくと、ちょっと都合が悪い。
原点を足元にして、視線も原点から出るとなると、「視界」足元から視線が伸びているように見えるからだ。
単純に視界の原点を頭の高さまでずらす、という場合、縦方向に差ができて、パズルが直感的でなくなる。
となると視界は原点=タイル中央で、なんとかそこを頭の高さにしたい。

15259913 comment

yumeのコメント: Re:ラメ曲線 (スコア 2) 83

ん〜前提が間違ってるんじゃないでしょうか。ロゴを変えることの目的は外部からはわかりません。

それに、変更するからには大きく変わらないといけない、ということはありません。
変更することは手段であって目的ではないので。
もっと軽微な変更でも、目的にかなうならよいでしょう。

確かなことは、この変更に価値があると決定され、発表されたということです。

個人的には、この変更はよい変更だと思います。
Xiaomiは「Appleっぽい」ことがブランドですし、発表は話題になってます。

15259683 comment

yumeのコメント: ラメ曲線 (スコア 5, 参考になる) 83

一見角を丸くしただけに見えますが、普通のコンパスではちょっと製図できない少し変わった曲線です。
元々はラメという数学者が考案した曲線(を描ける数式)で、それを建築家やデザイナーが応用するようになりました。そこそこ歴史は古くて、例えばヘルマン・ツァップという書体デザイナーの『Melior』というセリフ書体がラメ曲線を応用しています。1952年の作品です。
https://www.fonts.com/ja/font/linotype/melior/story

身近な例では、iosのアイコンなんかがラメ曲線を使っていると言われていますね。そこから発展して、webデザインでも最近はよく見るようになりました。

CIとしては……そもそもロゴを頻繁に変えることに、そこまでのメリットがあるのか(新ロゴリリースの話題作り以外)、という話もありますから、いっそここまで全然変わってないのもアリだなぁと思いますね。ちゃっかり話題にものぼってるし。

金額としては……CIをしっかり担当するなら、なんだかんだすごい手数と大量の案が必要にはなるので、Xiaomiと原研哉さんクラスなら全然おかしい金額ではないだろうと思います。ロゴマークのデータだけ渡して終わりじゃなくて、ロゴが関わる全てのプロダクトの設計と、将来作られうる様々なプロダクトでのロゴの使われかたみたいなのも設計しますしね。

話題としては……。切り取りかた次第では「角を丸くして3300万円」と言えなくもないので、好きです。

15256986 journal
日記

yumeの日記: メデューサ・ゲーム改・9

日記 by yume

◉TurnManagerの改善
ターン中のイベントを動作種別に細分化した。
TurnManager
以前は3つのイベント(TurnStart、EvilSight、TurnEnd)で制御していたが、抜本的に変更した。
新たなターンイベントは以下の6つとなる。
(ターン開始時に実行)
・OnDetectPlayer //兵士などがプレイヤーを探知し、探知状態を切り替える。
・OnPathFind //兵士などが目的地への

15256097 journal
日記

yumeの日記: メデューサ・ゲーム改・8 1

日記 by yume

◉石化と捕獲。

で、兵士を構成する最後の要素「見られたら石化する」を実装する。

……の前に、邪眼の効果が発生するタイミングをちゃんと定義しよう。

ゲーム上で、邪眼が発動する瞬間は、今のところ毎フレームだが、実際に必要なタイミングは:
A. プレイヤーが向きを変えたとき(ターンは消費しないが、邪眼の状態が変わるため)
B. ターンが終了したとき。
C. 邪眼が通る条件が変わったとき(柱が動いたときなど)
の3点だろう。このうち、プレイヤーが向きを変えたタイミングは誰も検知していないので、これを検知する必要がありそうだ。

ん〜〜〜。レベルマネージャーのように、レベルごとに邪眼の管理者がいる方がやはりよさそうだな。
EvilSightManagerとしよう。

15255457 journal
日記

yumeの日記: メデューサ・ゲーム改・7

日記 by yume

◉兵士 - 経路探索

Soldierの経路探索を実装する。
使うのはやはり前回同様A* Pathfinding Projectだ。
ただ、今回はターンベース・グリッドベースな仕組みなので、前回のように外部のサンプルスクリプトそのまま走らせてうごくというものではない。

定義を考えておこう。

経路探索移動は、呼び出されたとき:
・経路探索を呼び出し、現在地に隣接する目標座標、ないし方向を取得する。
・目標に向かって、ターンベースで1マス移動する。

経路探索は、呼び出されたとき:
・現在地とプレイヤー間の、障害物を避けて通れる経路を算出する。
・その経路から、現在地に隣接する1マスを目標地点として返す。

15254809 journal
日記

yumeの日記: メデューサ・ゲーム改・6 1

日記 by yume

◉ターンシステムと兵士

このゲームのもうひとつのコア・メカニクスであり、最も実装が面倒くさい兵士を作る……の前に、ターンシステムを作る。

ターンは、次のような概念だと思う:
・プレイヤーがターンを消費する操作を行ったとき:
 ・全てのターンを持つオブジェクトのターンが経過する。
  ・ターンを持つオブジェクトは、自分が次に行う動作を知っている。
  ・ターンを持つオブジェクトは、ターン経過時にその動作を実行する。

ううむ、厄介そうな概念だ。でも多分、イベントをうまく使えば実装できると思う。やってみよう。

TurnManager
ステージごとにひとつ存在する。次の要素を持つ:
・TurnEvent
ターンが進むことを購読者に知らせる。
・AdvanceTurn()
プレイヤーの操作や、あるいは他の要素から呼び出されて、TurnEventを発行する。

15254223 journal
日記

yumeの日記: GameJamで一位だったよ〜 2

日記 by yume

itch.ioでMini Jam 77: Courageに参加してたやつ、総合一位だったよ。(147作品中)
enjoyment部門で1位がとれたことはないので、次はenjoymentで一位をとりたい。

他の人の作品で今回気に入ったのは、
2位の作品(ブラックジャックとベルトアクションが合体したやつ)

13位の作品(倉庫番と視界パズルが混ざったやつ。メデューサゲームにちょっと似てる)
だった。

15252648 journal
日記

yumeの日記: メデューサ・ゲーム改・5 1

日記 by yume

前回の続き。

◉レバー
んで、次はレバーを作る。
レバーの前に、まず抽象的概念の「Touchable」を作る。
Touchableは、Playerとの接触を検知し、接触状態ならTouchイベントを発行する。
また、Touchイベント中にインタラクトすると、Interactイベントを発行する。

LeverSwitch : SwitchBaseは:
1. Touchableを参照し、
2. Touchイベントを購読し、Touch状態に合わせてレバーの表示を変える(枠線をつけるとか)。
3. Interactイベントを購読し、インタラクトされた時にスイッチイベントを発行する。
よさそうだ。やっていこう。

15251506 journal
日記

yumeの日記: メデューサ・ゲーム改・4

日記 by yume

前回の続き。(タイトル変えた)

●壁

さて、パズルの基礎となる要素をどんどん作っていく。
まず、ざっと作っていた「壁」についてもう一度精査しておこう。
壁の役割は:
・Actor(プレイヤーや、同じように歩けるもの)の移動を阻害する
・Light(表現上の視界)を阻害して、影を落とす
・EvilSight(プレイヤーや鏡からの視線)を阻害する
の3つだ。この機能を保ったまま、前作よりも効率よくステージ設計するためにTileMapで行う。
しかし問題がある。

typodupeerror

一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy

読み込み中...