「考え事」に関する日記

次>

ドラゴンクエスト10とふにゃ1とfunyak

巳
あけおめ!

ドラゴンクエスト10(ミフミン)

ってことで、年越し前後のイベント。

第22回アストルティア★ハッピーくじ『年末大勝負くじ☆2024』 (2024/12/23更新)|目覚めし冒険者の広場
ちょっと前に発表されてたハッピーくじ、やっと交換してきました。
相変わらず参加賞と確定3等しか当たってないですが。
参加賞はアクロバットスターのしぐさです。
モーション自体は1.0からずっとあったのに結構今更感。

お正月イベント「新春とってもヘビ~な鏡餅!」 (2024/12/27更新)|目覚めし冒険者の広場
お正月イベント!
一発バトルして終わりの簡単なイベントなんだけど、イベント会場見て回ったりとかバトルの準備とかだらだらやってたら、まあまあ時間を食ってしまいました。
せっかくバトルの準備したんだしとか思っていきなり強ボス周回しだしたのが良くなかったか。
まあ、時間かけた分、クエスト化してない拾い物イベントもしっかりこなせたし、良しとするか。

蛇姫からのヘルプ巳~|目覚めし冒険者の広場
懐かしすぎるというか、12年も前の上、ゲーム本編に出てこなかったキャラだから覚えてる人少なそうな蛇姫のイベント。
とりあえず私は、衣装借りたのと、参加賞のためのノルマ1体討伐だけやっときました。
でも年明けてもこの進行度合い、大討伐イベントとしては微妙な勢いだなァ。
運営側は、イベント景品をもって新年を迎えられるように、全ノルマ達成したらイベント終了を待たずに景品を配布できるようにしたとか言ってた気がするけど、普通に道半ばのまま年越してしまいました。
12年後にはダッピール本人も登場したりするんだろうか…。

他の写真は以下から。日記には1枚しか載せなかったけど各バトルも写真撮ってるよ。
写真置き場「2024/12/31」
写真置き場「2025/01/01」

ふにゃ1(リリース)

本当はステージメーカーまで作ってしまいたかったのですが、今回は旧バージョンを取り下げたということもあり、完成より公開を優先しました。

ふにゃ1(開発状況)

今日のコミットは、公開のための最終調整だけです。
作りかけのステージメーカーは、非表示にしただけで、内部的には残してあります。

ふにゃ1(構想)

ここからは今後の構想です。
今回、未完成なバージョンをあえてバージョン2として公開しました。
本当は、ステージメーカーも含めた完成版をお披露目したかったというのはもちろんですし、なんなら、プレイ記録画面のように、新しい機能ももっと追加したかったのです。
つまり、今なすべき課題は、旧バージョンの再現と、新機能の開発です。
優先すべきは当然旧バージョンの再現ですし、構想中の新機能の中には、ゲームのプレイ感覚を大きく変えうるものも含まれます。
だから、旧バージョンの再現と新機能の開発は、明確にバージョンを分けたほうがいいと思ったのです。

ということで、今後の開発は、旧バージョンの再現を目指す2系と、新機能を目指す3系に分けようと思います。
とはいえ、2系を開発しつつ3系も並行するなんて器用な真似が私にできるはずがないので、新機能のうちプレイ感覚がそんなに変わらないのは2系に取り込みつつ、2系が完全に終わってから本格的な3系開発という流れになるかと思います。
そこまで…できたらいいなァ。

funyak

これはこれで考えていることがあるけど、今から書いても考えてもまとまらないのでまた後日…。

さかだちの街


2面の通常面をクリアして、裏面は2-Eまで進行。
裏を並行して進める方針でやっていると、通常面が仕掛けのチュートリアルで、裏面が本格的なパズルという印象です。

ゲーム記のページも作っているのですが、ネタバレをどう扱うか考えてます。
公式の配信ガイドラインでストーリーのネタバレ部分は隠すようにと言われているけど、1プレイヤーとしては、そういうネタバレ部分こそ画面写真で残したいわけですし。
画面写真の掲載は動画配信とは異なるので、守る必要はないのかも、とも思いますが、守れるものは守りたいという気持ちもあります。
ひとまず、この日記では、写真一覧へのページへのリンクは当面記載しないようにしておきます。

funyak

角にぶつかった特殊パターンについて考えています。
座標上の角にぶつかった場合、壁としては、最大4つ(手前と奥、縦と横の組み合わせ)とぶつかる可能性があります。
一方、共通当たり判定の仕様としては、一つとしかぶつからないので、どれか一つを選ぶ必要があります。
もちろん、いつも4つ壁があるわけではなく、2つだったり、全くなかったりというパターンもあります。
0は言うまでもなく当たりなしで、1はシンプルに当たった一つの壁を採用すればよく、4つは手前2つを合成すればいいはず。
組み合わせパターンの多彩な2と3が厄介なんですよね。

PHPUnit

ちゃんとクラスになっている部分はテストできるのですが、サーバーから呼び出されるPHPファイルに直接あれこれ書いているものは、なかなかテストしづらいのです。
ちゃんと「呼び出すファイル」と「ロジックを書いているファイル」を分けていればいいのですが、小さいプログラムを手っ取り早く実行できるようにしようとすると、やっぱり呼び出すファイルに直接書いた方が早いし解りやすかったりするのです(Hello Worldするためだけにフレームワークのあちこちを飛び回るようなプログラムは書きたくない)。
こういうのをなんとか自動テストの仕組みに乗せるにはどうしたらいいかと考えたのですが、結局テストって入力に対する出力を見るだけなので、入力に使う変数($_POSTなど)を差し替える、出力をバッファリングして捕まえる、というのがある程度の落としどころかなと考えています。

ドラゴンクエスト10とゲーム記

ドラゴンクエスト10

しろいコキンとァォィョッュも無事ハロウィンイベントクリアしました。
で、ついでにクリア後要素の毎日お菓子を捧げるやつもやってみたんですが、よくある福引券だったので、深追いしないことにしました。
イベント家具は一応回収しておきたい。

ゲーム記

ちょっと管理画面改修中…。
またまたこれも数年放置案件だったんですね。
やるべき課題がたくさん溜まってきて、優先順位をつけて着手していった結果、後回しにされた課題が無限に積み重なっていって、先にやりたい課題まで見つけにくい状態になってきたので、優先順位の低い課題も片付けていくことにしたのです。
早く実装が終わるものは、すぐに実装し、よく考えたら実装する価値のなかったものは、課題を抹消し、実装したいけど大変そうなのは、実装したい場所にTODOコメントでマークを付けるようにしました。
とにかく、たとえ微増でもマイナスでも、ゼロではない進捗を上げていくのです。
今回のゲーム記の件は、理想を掲げ過ぎた課題を現実的に可能なまで単純化して実装、という方針です。

User Generated Content

UGC関連のルールをどこに置くか検討中。
ヘルプページに置くのが手っ取り早いけど…。

User Generated Content

アンパンマンDBのコメントや掲示板の記事などのユーザー生成コンテンツ(UGC)に関して。
この取り扱いについて、権利的なことはこれまで何も定めていなかったのですが、Anpanatorとか、みんなのタグとか、ユーザーの投稿なくしては成り立たないコンテンツも出てきたので、ルールをはっきりさせた方がいいかなと思い始めました。
以下のサイトが参考になりそうな感じ。
ウェブサービスにおけるUGCの著作権処理について : 企業法務について

ドラゴンクエスト10

正直、強敵コンテンツがしんどいんですよね。
お花に水やりするのは好きだし、職人仕事も簡単に毎日一定額もらえるので重宝しているんですが、バトルコンテンツはあまり意欲がわかないです。
なんというか、毎回パーティーメンバー用意しないといけないし、強敵なら装備もそろえて対策も覚えなきゃいけないし、毎日行くにはしんどいんです。
だから、基本的には水やりと職人仕事だけして、バトルコンテンツは放置しているんですが、ボスカードは期限があるので行かざるを得ないんですよね。
勝てそうにないやつはテリーに任せてしまえるんですが、テリーに丸投げするためには、みちびきの香水を使って魔法の迷宮を周回しないといけないんです。
で、迷宮を高速で周回するためには、弱いボスコインとかを捧げて連戦するんです。
なんでボスと戦いたくないのにボスと連戦してんだって話ですよ。
で、その弱いボスコインはどうすれば集められるのかというと、迷宮を周回して福引を回すんです。
迷宮を周回するってことはつまり、ボスと戦うってことで、結局やっていることはというと、ボスと戦いたくないのでボスと連戦するためにボスと連戦しているってことなんです。
そこまでやってもテリーと会えるかどうかは運ですし、どうせ敵と戦うなら、同じ時間を使ってストーリーを進めたいです。
強敵コンテンツは、やる気と時間が有り余っているときに一気にやりたいんです。
カードの時間制限がただただひたすら重荷になっているんです。
強敵のボスカードを持っているから、ボスカードの分道具欄が圧迫され、テリーに会うためのみちびきの香水に道具欄を圧迫され、迷宮を周回するための弱いボスコインに道具欄を圧迫され、時間を支配されてしまうのです。
もう、強敵ボスカードを手に入れたら、即座に捨てた方がいいんじゃないかなって気がしてきています。
ボスカード以外だったら、やる気と時間と装備が全部そろうまでずっと放置でいいんですがね。

WellKnownUriParserとドラゴンクエスト10

WellKnownUriParser

ナマライザ自身の変更ではなく、使用している部品を独立させてライブラリ化しようと考えています。
今でもAccessAnalyzerと言うライブラリの一部として「RefererAnalyzer」という名前で作ってありますが、うまく機能に分かれていないのと、.NET Coreに対応していないのと、一般的過ぎて中身を表していない名前なのが気に入らなかったので、新たに作り直します。
そして、ここからが一番やりたかったことなのですが、NuGetに登録して、パッケージマネージャを通じて、現代的な「普通」のやり方で導入できるようにしようと思います。
毎回バイナリをコピーとか、一度ビルドしたはずのものを使用者側でもまたソースコードからビルドとか、そういうのはもうやめたいのです。

AccessAnalyzerのもう一つの片割れ「LogReader」も、設計ひどいし超メモリ喰いだし、切り分けてまともにしたいのですが、何せ設計のひどい巨大クラスなもので、すぐには無理かな、と言うところです。

ドラゴンクエスト10

別のこのゲームに限った話じゃないんですが、毎日繰り返し遊べる微妙な稼ぎ要素ってのがあるんですね。
本編もちゃんと終わらせてないのに、目指したいものもないのに、ずっと同じ繰り返し。
ドラクエ10では、ここ何年か、花の水やり以外ほとんどやっていません。
これじゃ何も進まないし、栽培で得た資金も使い道がありません。
水やりをやめてがっつりストーリーを進めるような気合はないけど、せめて水やりのついででも、一区間走るだけでもいいから、ゲームの進行をしたい。
ということで、今日は、ァォィョッュで、グランゼドーラ城からゼドラ洞への一区間を走りました。
ゼドラ洞入り口のルーラ地点を記憶しておいたので、次回はこの続きからできるって寸法なのです。

のんびりナマライザと爆ボンバーマン

のんびりナマライザ

最新版アップしました。
先週言っていた、検索語句解析のエラー修正&微妙な高速化、検索語句解析対象サイトの増加です。

爆ボンバーマン

どきどきモード、ホワイトアイスから始めています。ええ、やっとまともにプレイ始めました。
ゲーム記に掲載するための画面写真も撮影しています。今更ながら、攻略情報を本格的に充実させようと思うのです。

ゲーム記に攻略情報を掲載するにあたって、考えていることがあります。
それは、実際に手を動かして遊ぶ楽しみを奪わない、ということ。
結論を掲載するのは簡単なんです。あやふやなヒントだけ与えて、あとは自分の目で確かめよう、と道筋を示さないのも簡単なんです。
でも、前者だと、頑張って攻略した結果得られるのは、掲載されているのと同じ内容。攻略情報を見たときに既に得た者です。
後者だと、そもそも攻略情報として成り立ちません。ヒントから結論への道筋が見つけられなければ、攻略できません。
結論へ至るまでの正確な道筋を示しつつ、結論そのものの記載は避ける、というのがちょうどいい塩梅ではないか、と、考えています。

アンパンマンまとめWiki

アンパンマンまとめWikiをいまだに本稼動させていないわけですが、本稼動させにくい理由があるのです。
それは、私自身がWiki管理者として不適格ではないかということ。
Wikiはいろんな考え方の人が編集に参加することになるので、細々とでも長く続け、荒らされたら速やかに対処を行い、しかし荒れない範囲でなら編集者たちの意向を最大限尊重すべき、と思うのです。
しかし私は、「アキタラヤメル企画」に代表されるように一度始めたことを割りとすぐにやめてしまったり放置することがあります。
みんなにコンテンツを作ってもらっておいて、やる気がなくなったからやめますなんてことじゃだめなのです。
特に、何かが終わった後にその後継もすぐに終わってしまうというのは、利用者にとってとてもやるせない気持ちになるものです。
メテオスオンラインの後のメテオンもどきでそのことを痛感しました。
その一方で、私は管理するならとにかく自分の思い通りに管理したいという願望が強いようです。
私自身はっきりと自覚しているわけではありませんが、過去の自分の行動を振り返る限りそう思えるのです。
アンパンマン質問箱は私にとって答えやすい質問が来て当然という気持ちではじめ、答えにくいものはいい加減な答えで返した挙句、答えたくない質問ばかりが増えるという理由で終わらせてしまいました。
また、他人様のサイトで必要以上に自治をしようとしてかえってトラブルを悪化させたこともありました。
これらの回りくどい理由を抜きにしても、私が運営しているはずのWikiは現在すべて放置状態です。
一度作ってしまえばそれで完結というわけにはいかないので、作るのには慎重になっているのです。

ゲームの記録って楽しいのか

ゲームって、楽しければいいですよね。
だけど、ゲームをやっていて楽しくないことも多々あるんです。
それが、単なる記録作り。
コレクション要素をひたすら集めたりとか、主人公をひたすら強くしたりとか。
なんでそんな要素ができちゃったんだろうと考えてみます。
私はゲームをやった後急に虚しさがわきあがってきたり激しい後悔が生まれたりすることがあります。
自分は何を一体無駄なことをしているんだと。
その時その時は楽しくてもやめればもう楽しくない、後に何も残らない感じが嫌なのです。
じゃあ、後に何か残せばいいじゃないか、という発想がここで出てくるわけです。
ゲーム記を見てわかるように、ゲームのいろんなことを記録として書き残しています。
後で見てその時を思い出して感慨に耽るときもあります。
そんなことだから、ゲームそのものの、得点とか、集めたものとかも、それはもう大切なのです。
きっとそういう人が多かったんでしょうね、そうでなくても少なくとも開発者は記録の大切さを感じていたのでしょうね、ゲームにセーブ機能がつけられるようになると本当にいろんなことを記録するようになりました。
初期は得点、時期が進むにつれてゲームの進行度、ハイスコアを出したときのリプレイ、本編とは関係ないお楽しみ要素、本当にいろんなことを記録するようになりました。
記録されると終わった後も楽しい、もっと記録するともっと楽しい、そんな連鎖でどんどん記録するようになったんだと思います。
だけど、同時に記録があまりにも増えすぎたために、記録のためにのみプレイすることができるようになってしまうのです。
ハイスコアをひたすら求める程度ならば、テクニックを磨いたりこり高い得点法を考え出したり、張り合いがあるものですが、しかし、近年増えてきた「記録のための記録」のような記録のためのプレイであると、記録更新されなければただ苦痛だし、更新するためには張り合いの無い反復作業を延々と続けさせられることも少なくありません。
ゲームの記録って、たくさんあるから、とか、すごい記録だから、とかじゃなくて、楽しんだ結果だから、記録する、というのが、健全だと思うのです。
そう思ったのです。

弾ける

今日は母が中古のノートパソコンを買いに行くというので付き合って大阪まで行っていました。
そして私は母がノートパソコンを物色している間、自作パソコンに少し興味があったので部品のところを見て回っていました。
そして具体的に部品を見ていったときに初めて全体の見通しを立てていなかったことに気付く私でした。
そこで書籍コーナーによってその手の本を見ていたら、そのうちだんだん今の自分のマシンで充分な気がしてきて、結局自作のことは先送りにすることにしました。
その後無事ノートパソコンを購入した母と別の店に行ってゲームのフロアを見に行ったのですが、似たようなゲームばかり―全体的にピンク色、似たような顔、巨乳、ロリ、アダルトゲーム―がずらりと並んでいて、見ているだけでげんなりしてきました。
そもそもゲームはルールにも見た目にもいろんなバリエーションがあって、並べると目がチカチカするぐらいいろんなのが交ざってたほうが買う気も起こりやすいと思うし、正直、手を伸ばしても触れられない2次元のキャラクターが乳繰り合っているのを見ているようなのはゲームだとすら思ってないです。

それはそうと、これはゲームだと胸を張っていえるふにゃさんでは、ウナギカズラも凍るようになりました。
そして、前々から作ろうと思っていた弾けるエフェクトも作ってみました。
今のところ弾けるエフェクトは2種類作っていますが、どちらも同じ簡単なアルゴリズムでパラメータだけを変更して使っています。
そうそう、弟に指摘されて気付いたのでふにゃが氷を息を使いすぎたら疲れるようにもしておきました。

1135432932.png

戦いはドラマだ

唐突に何か。
私は、RPGを「なんだかんだと理由をつけて戦うゲーム」と考えている。
そりゃストーリーも重要かもしれない。
だけどストーリー的に重要なイベントは決定ボタンを押しつつ眺めるだけだ。
そんなのだったらゲームなどという枠ではなく、フラッシュとして腐るほどインターネット上に散乱している(それを言うならRPGだって掃いて捨てるほど散乱しているわけだが)。
RPGにおいてゲーム的な駆け引きが最も生じるところ、それはすなわちバトルなのだ。
イベントは言ってみればそれに対する動機付けやご褒美に過ぎない。
RPGのゲーム性といえば謎解きも重要だが、これもバトルと考え方はほぼ同じなので省略させてもらう。
かくも重要な「バトル」、重要なのだから重要なりに、それぞれ目立たせたい。
ボスは言うまでもない。
誰だって誰に言われずとも個性豊かで特別な存在にする。
もちろん、それはストーリーに関わるからだ。
しかし、ザコの扱いは、多くの場合悲惨だ。
世界観に合いそうなキャラ、場所に合いそうなキャラなどを、適当に選んでパラメータを調整してランダムで出現させるだけだ。
確かにザコは、倒されることこそ仕事で、とにかくたくさん出てきて、ストーリーにはあまり関わらず、あまりプレイヤーの記憶には残らない。
しかしそれは、テレビ番組におけるCMのようなもので、ストーリーに関係なくても出てきて、さらりと受け流される運命にはあるけれども、それでも心のどこかに少しだけ残る、そういうものではないのか。
テレビCMには必ずアピールポイントがある。
多くの場合は商品であるが、RPGの場合、アピールするのは目の前にいる敵たちである。
もちろん番組本編であるボス敵よりもすごくてはいけないのだが、ザコはザコなりに引き立たせてやりたい。
短いCMの中にも商品をアピールするというドラマがあるように、ザコ戦にもあっさりやっつけるというドラマがある。
そのドラマは「敵が現れた!」「敵をやっつけた!」「YOUWIN!」でいいのか。
CMで言えば「○○という商品です!」「こういうときに使います!」「買ってください!」のようなものだ。
テレビショッピングのように、戦うことそのものが究極目的であるゲームならそれでかまわない。
むしろそうするべきだ。
しかし、RPGの場合はそれは恒常的に起こるイベントだ。
このバトルという名のドラマを区切るメッセージは、果たしてみんな同じでいいのだろうか。
いいという考え方もある。
ドラクエのように、ラスボスでさえも「ゾーマをやっつけた」で終わるのは実に潔くて気持ちいい。
しかし、私はあえて逆の方向を目指そう。
「Bomber丸World」では、ボスにもザコにもそれぞれ勝利条件があって、勝利した結果も違うようにしようと思う。
しかし、戦いであること、勝利することが目的であること、それだけは絶対に忘れないようにせねばならないとは思う。
突き詰めていけば、多様性と一貫性の問題か。

個性

えっとですね。はい。RPGというのには、キャラクターの個性が必須なわけです。
例えば。個性作りのうまくいっていないRPGだと、誰と話しても作者一人が話しているような口ぶりだったり、逆にむやみやたらとわけのわからない言葉を語尾につけたりと、まあこれはこれでむしろ作者の個性なので別にいいのですけれども。
個性とは何かを考えるのです。
個性、それは人が、いや、人に限らず誰もが持っている他人とは違うところ。
ほとんど同じでもほんの少し違うところ。
遠くからじゃみんな同じに見えるのに、関われば関わるほどに際立って見えてくるところ。
村人一人一人にも個性はあってしかるべきものではありますが、逆に目立ちすぎると主要キャラクターがかすんでしまい、見当違いなキャラクターにばかり関わってしまい、むやみに難度を上げる結果となることもあります。
ストーリー進行に重要な役割を果たす人物には一瞬で誰だかわかる個性が必要だけれども、ただ数回話して情報を得るだけの村人にはそんな個性は必要ありません。
だからといって村人の個性をなくすと死んだ会話になってしまうのが当然であり、例え数回といえども関わりを持つのであれば、それ相応の少しばかりのさりげない個性が必要となるわけです。
個性はなくてはならない、しかし強すぎてはならない、という微妙な加減が必要なその他大勢のキャラクターは、もしかしたら主要キャラクター以上に個性の設定が難しいのではないでしょうか。

「Bomber丸World」ではですね、詳細未定のキャラたちがその微妙な役回りを演じていただくことになるはずです。

重い思い

サーバーのOSはRedHatLinuxだ。
Linux系はマルチタスクOSであり、複数のユーザーが同時に利用する。
だから、あまり高負荷なCGIは設置できない。
私自身のためでも訪問者のためでもない、サーバーを共有するほかのユーザーのためだ。
しかし、時としてCGI上で重い処理を実行しなければならないときがある。
もちろん一番手っ取り早い解決方法は処理を軽くすることであるが、理論的にも現実的にも限界というものがある。
例えば、N個のデータに対して処理を行いたい場合は、どんな場合でも最低N回の処理が必要になる。
また、実行しないという方法もある。
つまり、データをローカル環境にダウンロードしてそこで処理をすればサーバーに負荷はかからないという計算だ。
しかしそれには時間も手間も余計にかかる。
そこで、原点に立ち返って考えてみる。
なぜ高負荷の処理をしてはいけないのか。
マルチタスクの動作原理からわかるとおり、実際の処理は1つのCPUがこなしており、単純計算すれば、2人が同時に処理を行えば処理速度はそれぞれ半分になるということだ。
低負荷の処理であれば処理は瞬時に終わるため、2人が同時に、ということは少なく、仮にあったとして処理速度が半分になる期間はごく短いということになる。
そしてもうひとつ考えてみる。
高負荷とは何なのか。
言うまでもなく負荷が高いことである。
負荷が高いとはどういうことを言うのか。
非常に多くの処理を行う場合であろう。
しかし、その非常に多くのそれぞれひとつは実は軽い処理なのである。
例えば、同じ処理でも、10倍の時間を掛けて処理すれば単位時間当たりの負荷は10分の1に減るだろう。
つまり、常にほんの少し重い状態をキープすれば一見重さを感じないのではないか。

ということで、日記の左側メニューを生成する処理を作りました。
ローカルテストではこの機能は一回約0.17秒かかるようで、実際に使うのは数日に一回程度だから多少重くても気にしない。
逆にチャットのようなものだと一回一回が軽くても呼び出し回数が馬鹿にならなかったりしますけどね。

クオンティティ

長い文章を短時間で書ける能力が必要だと感じる今日この頃です。
何しろ私の場合考えすぎて最初の一文を書くのに一時間以上かかってしまったりして、早く書かなきゃいけないときにいろいろ困ったりするので。
とりあえず量をたくさん書いておけば質はあとからいくらでも良くできるし、冗長だと感じる表現も書いた後消せば結局短く完結にかけているわけで。
何を書くべきか書くべきでないかとか考えるよりかけることをどんどん書いていくといったよう・・・続きが思いつかなくなった。
まあいいや。

ランキングにスタイルシートを使いました。
でもいい加減そろそろAskaBBSの改造から抜け出さないと。
どこをどう考えたってAskaBBSの機能は一切残していないわけだし、無駄にもほどがあるということで、まあとにかく、いつかは完全オリジナルにする予定です。
私のCGIの書き方とも違う部分がいろいろあるわけですし。
といってもそんな書き方が確立できるほどCGIを作ったわけでもないけど。

わけあって「ゼルダの伝説-風のタクト」で神の塔に行ってみました。
ムジュラの仮面とかみたいにボスと何度でも戦えるようにしてくれていたら嬉しかったけどストーリーの関係上それは無理な話。
ゴードンさんの写真をパシャリ。
ついでに言うとクグツガノンは光の矢を適当に連射していればそれなりに楽。
剣で斬って動き止めても光の矢を構えてるうちに動き出しちゃうし。

地震があったようですね。
こちらには直接関係ないのですが、規模の割に被害が少なかったようで少し安心しました。

今日と明日

ウィルスメールらしきメールが届いていました。
メールを送ったのに届いていないという人は再度連絡をください。

国公立大学二次試験前期が始まりましたね。
もう私には関係のないことです。

アンケート、どんどん答えてくださいね。
回答数が1票や2票ってのは寂しいから。

「明日のために今日はある」
よく聞く言葉、のように見えますが、検索してヒットした数を見てみると、思ったよりかかりません。
明日を良くするために今日努力する、そんな雰囲気ですね。
ということは、逆に考えると、
「今日のために明日はある」
そう考えることもできませんか?
明日がなければ、今日努力する気になれますか?

ある意味数学的な問題

今日はこれといって書くことがないので数学の問題でも……出来ませんでした。

曲線 F(x, y)=0 を直線 ax+by+c=0 を軸として対称移動した時の曲線の方程式を求めよ。
一応答えは出たのですが、どうやら c=0 の時にしか成り立たなかったようです。
多分垂線と中点を使って解いたのが悪かったのだと思います。
しかも出た答えも複雑すぎて使い物になりませんし。

「ふにゃふにゃ」においても次のような問題に突き当たってしまいました。

座標平面上に、動かない直線Lと、等速直線運動をしている円Cがある。
この円Cがある微少時間のうちにLに衝突する条件を調べよ。
また、微小時間経過後のCの位置を求めよ。
なお、L,Cの方程式及びその他の必要な文字は各自定義すること。
早い話、攻撃の反射条件です。

無題

「クイズα」をバージョンアップしました。
最後の文字が"\"になるのを修正しました。
いちいち更新のたびにファイルサイズを書き換えるのは面倒です。

明日は9月1日ですが日曜日で学校は休みです。
私は9月1日の日曜日は夏休みとは思っていません。
新学期の第一日目がたまたま休みになっただけだと思います。
実質連休の日数は増えますけどね。

次>