カレンダー

06 | 2007/07 | 08
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31 - - - -

カテゴリー

プロフィール

drednote(Mr.Ty)

Author:drednote(Mr.Ty)
既にいい年しているにも関わらずエロゲをプレイしているヤバイおっさんです。きっと還暦になってもプレイしてそうな気がする。

最近の記事

最近のコメント

最近のトラックバック

月別アーカイブ

ブロとも申請フォーム

この人とブロともになる

主にエロゲのプレイ日記。他レビューっぽい事とか色々
エロゲプレイ記
  当サイト内記事にはゲームのネタバレが含まれる場合があります。
  ネタバレをみたくない方は、当サイトの閲覧をご遠慮願いますようお願い致します。
  また、当サイトの記事自体は全年齢対象ですが、
  扱っている評価物は基本的に18歳未満プレイ禁止の物が殆どですのでご注意願います。
[------]
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

--------(--) --:-- スポンサー広告 | 編集 |
[20070729]
MySQLを使ってEC-CUBEをインストールし、文字化けしているという報告が公式サイトの方で頻繁に見受けられる。これはまぁ、言ってみればMySQL4.1以降でデータベースの文字列エンコードの扱い方が変わった為の弊害という事になるんだけど、とにかくそのせいでEC-CUBEが文字化けして使えないという人は潜在人数にして結構いそうな気がするので解決法を書いておく事にする。

解決法1:PostgreSQLにする。
上で書いたように、これはMySQL4.1以降の文字列エンコードの扱い方が変わった事による弊害なので、PostgreSQLにすれば発生しない。Windowsだと検索速度もPostgreSQLの方が速い為、そう出来るのであればPostgreSQLで運用するのも1つの手だと思う。

解決法2:SC_DbConn.phpを少し変更して文字化けを解消する。
レンタルサーバーの都合により、どうしてもMySQLでやらなければならない人の方が恐らくはずっと多いだろう。だからそういった人を捨てるという選択肢はありえない。EC-CUBEにはコミュニティ版とも呼ぶべき、UTF-8のバージョンが非公式で存在しているんだけど、その改造の一部を適用する事でEUC-JPの運用でも文字化けしてるって人でも文字化けを解消する事が出来る。具体的には、data/class/SC_DbConn.phpの33行目、

$this->dsn = $dsn;

の行の次の行からに、以下2行を挿入する。

$buf = $objDbConn->prepare('SET NAMES eucjpms') ;
$objDbConn->Execute($buf) ;

上記のeucjpmsの部分は、データベースをujisで運用している人はujisに変更して欲しい。
以上の変更を予めSC_DbConn.phpに施してから、改めてインストールしなおして見て欲しい。それで恐らく文字化けは解消されている筈だ。
スポンサーサイト
[20070729]
EC-CUBEでネットショップを運営していて、何かデータを纏めて欲しいと思った時、多くの人は恐らく既存のCSV出力機能を使うか、或いは高度な機能でselect文を独自で書いて出力項目をカスタマイズする事と思います。
しかし既存のCSV出力機能では用意された項目以外の項目を追加出来ませんし、高度な機能での出力の場合、出力する度にwhere句が違う等といった条件が入る場合にはその都度select文を修正しなければならない為少し面倒です。そういった場合にはEC-CUBEの場合、データベースを直接弄ってCSV出力をカスタマイズしなければなりません。
ここで書く説明は、既存のCSV出力に対して項目を増やす際の説明となりますので、受注管理とかキャンペーンとか、そういった既存のCSV出力機能外に独自に項目を増やす場合は作業が少し増えるという事をまず理解しておいてください。次に、CSV出力項目の設定はdtb_csvテーブルに追加して行うのですが、この際追加出来る項目は既存の出力レコードから一意に決定出来る、即ちキーとして機能する項目に対してのみにリレーション出来るという事を覚えておいてください。既存の出力レコード、例えば受注管理ならdtb_orderになる訳ですが、このレコード中では一意である必要はありませんが、特定のレコードを決定した際に、外部テーブルの特定レコードもまた一意に決定出来る必要があります。これは、CSV出力する項目を既存のテーブル以外のテーブルから引っ張ってくる際にはサブクエリーによる呼び出しとなる為、結果レコードが複数件存在しえるような場合にはデータベースでエラーとなる為です。
ここでは例として、dtb_orderにdeliv_idが記録されている場合にこのdeliv_idを使用して配送業者名を検索してくる例をあげます。尚、デフォルトのEC-CUBEではこの項目は、テーブルには存在しているものの未使用で、実際には何も記録されませんので例を実行しても特に何も得る事は出来ません。この例を有効に使う為には別途、dtb_order.deliv_idに正確なdeliv_idを記録する機構が必要となります。

EC-CUBEのCSV出力機能は上で書いたようにdtb_csvテーブルのレコードを参照して項目を出しています。ここで、どのレコードがどの機能のCSV出力に該当するのかを調べるにはdata/include/csv_output.incを開き、この中の$arrSubnaviName配列を見ます。ここに記述されている名前はそのままCSV出力項目設定のサブナビに出てくる名前と合致します。この配列の添え字が、dtb_csvのcsv_idに該当します。これにより、受注管理のcsv_idは3である事が判ります。
既存のCSV出力機能に項目を追加する場合、noはinsert時にデータベース側が自動的にカウントするので良いとして、rankについては適当に調整しましょう。被っても特に問題ありませんが、これは項目の並び順に相当しています。データベースから項目を引っ張ってくる際のソート基準となりますので、適当に気をつけておいてください。
ではdtb_csvの各項目について少し説明をしてみます。

no:これはdtb_csvテーブルでのキーです。しかし実際には使われないので正直存在意義がよく判りません。とりあえずinsert時には自動的にカウントしてくれるので存在を忘れても特に不都合はありません。

csv_id:これはこのレコードがどのCSV出力機能に該当するのかを示す値です。上で書いている通り、csv_output.incの$arrSubnaviNameを見れば具体的にその値が何であるのかが判ります。今回は受注管理CSVへの項目追加という設定になっているので、この値は3となります。

col:これは実際に出力される項目となります。ここにselect文を記述する事で、外部テーブルの項目をサブクエリーとして取り出す事が出来ます。具体的にどう書くかは後で記します。

disp_name:項目名です。CSV出力した際に、1行目のヘッダ部分の名前としてこの値が使用されます。今回は配送業者、と書く事になります。

rank:項目の並び順です。データベースからデータを引っ張ってくる際のソート基準となりますので、項目を並べたい順番で値を振ってください。

status:その項目がCSV出力に含まれるかどうかの制御フラグです。この値が1ならその項目は実際にCSVに含まれる項目となります。1以外の場合は、CSVにはその項目は含まれません。

create_date:項目の作成日です。特に使われている場面はありませんのでどうでもいいですが、とりあえずNow()を指定しておきます。

update_date:項目の更新日です。CSV出力項目設定等で出力するCSVを変更した際に更新されますが、実際にこの値を使っている場面はありませんのでこれもどうでも良いです。insert時には一応Now()を指定しておきます。


さて、実際に出力される項目は上記のcolで制御するというのは判っていただけているかと思いますが、これをどう書くかという事について。
受注管理の場合、dtb_orderに含まれる項目であれば単に項目名を書くだけでその項目を出力させる事が可能となるのですが、しかし実際にはdtb_orderに含まれている全項目は既にdtb_csvに登録されている為に改めて書く事はありません。ですので追加する場合にはdtb_order以外のテーブルの項目という事になります。今回は配送業者という事ですが、これはdtb_delivのnameに該当します。EC-CUBE管理画面の配送設定の欄で、配送業者で指定した名前はname、名称に指定した名前はservice_nameが夫々該当するカラムとなります。dtb_delivはdeliv_idをキーとして持っていますが、dtb_orderのdeliv_idがdtb_delivのdeliv_idを指し示すという設定としていますので(何度も書きますが、デフォルトのEC-CUBEではこうなっていません。デフォルトのままではdtb_orderのdeliv_idは未使用です)dtb_orderのdeliv_idからdtb_delivのnameを検索するselectを書けば良い事になります。つまり、

(select name from dtb_deliv where dtb_deliv.deliv_id = dtb_order.deliv_id)

がcolに記述すべき値という事になります。従って、

insert into dtb_csv (csv_id, col, disp_name, rank, status, create_date, update_date) values (3, '(select name from dtb_deliv where dtb_deliv.deliv_id = dtb_order.deliv_id)', '配送業者', 54, 1, Now(), Now()) ;

というSQL文を実行する事で、受注管理CSV出力に配送業者を追加する事が出来る事になります。
上記は簡単な例で項目を追加してみましたが、実際にはサブクエリーで出力を1件に絞れない場合とか、もっと複雑な例もあるかと思います。しかし基本的には上に書いた例を応用し、また実際にCSVを出力している関数(lfGetCSVという関数がCSV出力用データを取り出す関数になっています。この関数は複数のファイルで定義されていますが、どれも大体同じような内容なので、同じ変更で通用します)を呼び出す際の引数等を調整する事でどんな複雑なCSV出力でも出来るようになります。
EC-CUBEはわりとカスタマイズが容易ですが、少し何かしようとするとPHPやデータベースを直接編集しなければならないのは確かです。ですのでどのテンプレートを弄ればどうなる、という事だけではなくデータベースのテーブルの役割、各PHPの役割を理解する事で更に大きなカスタマイズに対応する事が出来るようになるでしょう。
[20070727]
あかね色に染まる坂、ソフマップから届いたのでとりあえず開封。
で、早速プレイしてみてるわけなんですが、とりあえずまだ前半の内はそんなに荒れなければならない程だとは思いません。公式とか2chとかはもう物凄い事になってますがwまぁ夏休みなんでやりもしない暇な学生が荒らしてる分も加速してるのかもしれませんし、とりあえず自分でやらない事には自分の感想にはならないので誰か一人最後までやってみてから改めて感想を書こうと思います。
とはいえ、ここまで荒れるからにはそれなりに酷い内容なのは判りきってるんですけどねw。うな天とどっちがマシかな~とか思いながらプレイしてみようと思います。
[20070722]
Sofmapの豪華特典に釣られてwあかね色に染まる坂を予約してみたわけですが、feng作品は実は初体験。色んな所で語られるのはバグの話ばかりwで少し不安になりますが、まぁプログラマ氏もいつまでも無能なままじゃないでしょうし(Liarみたいな例もまれにありますがw)今作では問題無いと信じたいですね。
とりあえず無事発売されましたら、(時間があれば)プレイ日記も書いてみたいと思っています。

しかし、なんかエロゲ業界と言えばバグと延期がつき物みたいな印象がここ数年でついてきてるんだけど、やはり近年のシステムの複雑化はどうしてもそういった現象を引き起こしてしまうのでしょうかね?というか、バグと延期はなにもエロゲに限った事ではなく、携帯電話からWindowsから何から何までバグもあれば延期もあるしやはりある程度以上複雑なプログラムになってくると予測は最早ただの希望でしかなくなるという事なのだろうか?

2007-07-22(Sun) 21:22 雑記 | トラックバック(0) | コメント(0) | 編集 |
[20070717]
純愛は、HOOKが完成させるなどといきなり大きな事を言ってのけたHONEY COMINGですが、果たして?
HOOKといえばORANGE POCKETのあたりから段々とブランドカラーを出してきて、_summerで独占方面で一歩抜きん出てきた印象がありますが今作では更にトップに立とうとして出した意欲作という事なのでしょうか。まぁ、この方面ではオーガストやPurple Softwareなど既に優秀なソフトハウスが幾つか存在しており、その中で戦っていくのは一筋縄ではいかない事と思いますが頑張って貰いたいですね。では評価してみましょう。

独占について
麻里乃シナリオで一部微妙かな?という印象を与える場面もありましたが、全体としてみれば独占と考えて問題無いでしょう。というかこれがNGだとすると現存するゲームの恐らく90%以上はNGになってしまう訳で流石に厳しすぎますので。ですので大半の方には自信を持って独占であると言えると思います。少なくとも私は独占と考えて良いと思いました。
HOOKは今までの作品から見ても独占方面で頑張ってきているので、これからもその方向で伸ばしていって欲しいですね。

処女について
とりあえずHがあるヒロインについては全処女で確定していますし、雷堂苺先生とかあの辺のキャラについても処女と考えて良いと思います。という事で問題無く全処女。HOOKはオレポケ以降の作品しかやっていませんが、今までのところ非処女キャラがそもそも居なかったようにも思いますので処女フェチな人にとっても優秀なメーカーと言えるでしょうね。

萌え和姦について
こういう内容でレイプとかがある方が逆に驚きですが、この作品はそんな変な壊し方はしません。きちんと、ある種伝統的なシナリオ作法によりヒロインとは全員普通に和姦です。強制されて云々という場面もありませんし、そういう内容でも無いし。

ロリについて
ロリ担当はハゲ入道wの妹、こよりちゃんですが、なんか老獪というか妖艶というかw基本的なロリとはまた違う味があります。無論Hは無いわけですが、これはこれで良いんじゃないですか?一応おまけシナリオでこよりシナリオが独自で存在もしています。

ツンデレについて
最初、朝陽もツンデレかな?と思ってたんだけどよく考えたらこれは違いますね。単に素直じゃないだけでした。いや、それで尚且つ表面的には嫌ってる風だったらツンデレ完成になるんだけど、そうじゃなくて普通に悪友風味なのでツンデレとは言えないですね。という訳でこの作品でのツンデレ担当は麻里乃と由馬という事になりますが、個人的には由馬の方が良かったですね。詳しくはプレイ日記の方を参照して下さい。

絵について
HOOKではもうそろそろお馴染みの絵師、松下まかこさんとらっこさんによる絵は、今作でも綺麗で可愛い女の子が描かれています。ただ、主人公の方がどうも大昔のエロゲに出てくる主人公のような印象でw、ここをもうちょっとどうにかしてくれと思わなくもありませんでしたがw。薫や政則を見る限りでは、別に男キャラが描けないというわけでは無いっぽいので、やはり主人公についてのキャラクターデザインをもうちょっとどうにかして欲しいと感じました。

総評
ボリューム的にもシナリオ的にも絵的にも大体満足行く作品だと思います。まぁしかし流石にこれで純愛は完成、と言ってしまうとちょっとそれはどうかという気もしますが意気込みは感じる事が出来ました。HOOK公式ページを見ますとオンリーワンモードの意義などについて書かれていますが、実際なるほどなぁと感じましたし新しい事へのチャレンジという事で評価出来るのではないでしょうか。全体で見て、傑作と良作の中間くらい?でしょうか?傑作と言ってしまうと流石に言い過ぎな気もするのですが、ただの良作で埋もれる程度でも無い、という感じで。点数をつけるなら100点満点で

88点

といったところでしょうか。実際かなり良い作品だと思います。
お勧めします。
[20070712]
純愛は完成したか?その問いには残念ながらNoとしか言えないと思います。まぁ、完成というのがどの境地を指すのかにも寄るでしょうけれど、一般的に考えてある種の至高の領域への到達を完成と考えるのであれば、今作を至高とするには物足りないというのが正直なところです。
さて、大食い選手権第1位由馬選手wですが無気力系のツンが生きる気力を取り戻してデレデレといった感じの、これもある種のツンデレシナリオでした。なんか今作ヒロイン5人のうち3人がある種のツンデレと言える風で、ツンデレ含有率が高いですね。

由馬シナリオは、個人的には朝陽シナリオと肩を並べるくらい高レベルなシナリオだと感じました。まぁ、相変わらずベタなのは確かですが、別にベタが悪いってわけじゃないと思うので。
幸せだった家庭が不幸な事故により子供の一人が死去、事故の原因が己にあると夫々自分を責める家族、結果ばらばらに。こういった系の話はよくありますが、今作よく判らなかったのは由馬が自分を責めるのは判るんだけど、親が夫々自分を責めるってのがよく判らない。というか、別にどう転んでみたところで責任があるようには見えないし、そのせいで精神崩壊とか仕事に逃げるとか意味が判んない。なんで?って感じ。
ただ、そういったシナリオの不条理さはあるものの恋愛劇としてみた場合のシナリオとしては主人公が打たれても凹まずに前に進むというのはやはり、昨今多いヘタレ主人公を多く見ている身としては感動するものがあります。やっぱ話に対するストレス度合いってのは主人公が握ってるよね。プレイしていてストレスを感じる話というのは正直連続してプレイする気になれないし、大抵の場合は他のゲームに浮気してそのまま帰ってこない。だからヒロイン全員をクリア出来るゲームというのは(難易度的な話ではなく、モチベーション的な意味で、ね)それだけである意味実力を持っていると言って良いと思います。
話開始当初の素っ気無さから、話の終盤におけるデレデレ具合という変貌を見ると、これもかなり良質なツンデレと言って良いと思いますが、麻理乃と違ってこのツンデレはかなり良質であると感じました。まぁ終盤でツン分が全く残ってないのは嫌だって人もいるのかもしれませんが、私は由馬に関して言うならこれで良いと思います。実際、無気力系が生きる気力を取り戻したという話なんだから、元々別に嫌ってるわけでもないんだし。
舞台が元お嬢様学校だったという割に、今作の本物のお嬢様ヒロインは実は由馬だけという舞台設定の意味不明ぶりには泣けますがw由馬に関してはお嬢様らしいシナリオ展開も含んでおりそれはそれで良かったですね。ただ、なんか両親もすげーあっさり主人公の事認めてたけどそれでいいのか?大会社の社長w。かにしのの梓乃ルート最後みたいな、超親馬鹿両親が娘の幸せのため~みたいな感じで主人公を社長に祭り上げる、という流れなのであればある種のギャグ分も含んでおり納得出来なくも無いのですが、今作はそういう風味じゃありませんし、なんか普通に将来の話で社長云々な感じになったんだけど、本当にそれでいいのか?wどうせならけよりなの姫様ルート位、一緒になる為に努力する、みたいな話があっても良かったんじゃないかという気もしないでもないですけど、そこまでやると話長くなりすぎるから仕方が無いのかな。

まぁ色々書きましたが、それで通してプレイしてそこそこ楽しめました。とりあえず朝陽オンリーワンルートやったらレビューでも書きますかね。
[20070710]
ハニカミの4人目のヒロイン、クレアをクリアしたのでその感想などを書いてみようと思います。
ちなみにヒロインの正式名は前園・Clarissa・皐。でも前園と皐の部分はゲーム中殆ど出てきませんw。ならクラリッサの部分は出てくるのかというとこっちはもっと出てきません。肉親ですら普通にクレアと呼びかけますw。この長い名前の意味はいったいどこにあったんでしょうね。
さて、このクレアですが1つ、他のシナリオよりも悪い点?があります。エロシーンは一応他のヒロインと同様2回あるのですが、どちらもスタッフロール終わった後のエピローグ中でしか出てきません。いやさぁ、仮にもエロゲなんだから一応本編中でやろうよ。エピローグになるまでエロシーンがなんもないってのはどうなのよ。まぁ、コンシューマ移植前提で作ってたらこうなりましたって事なんだろうけど、もうちょっと考えようね、と言いたくなりました。まぁ実際今作はエロ薄いです。なんせ2回しかない。今時のエロゲでエロ2回ってかなり薄めだと思います(TH2とかは例外ね、あの辺はもうエロゲの範疇に入らない)。まぁくっついたら後は毎日ひたすらやるだけ、みたいなゲームもあるけど流石にそこまでじゃないとしてもちょっとは頑張って欲しい部分ですね。残念ながらこの点において、純愛を完成させると言いながらそれをエロゲの範疇で実現する事が出来ていないという感じでしょうか。まぁ次回は頑張ってください。
で、クレアなんですがこの人は、他のゲームだと間違いなく教会にいる、シスターとして描写されていたんじゃないですかね。今作では生徒でないと恋愛授業を一緒に受ける事が難しくなる関係上普通に生徒になってますが、性格は普通にシスターそのものって感じです。博愛主義で、何かにつけて主よ、みたいな事言うし。でまぁ、そんな感じなんで基本的に恋愛感情に疎いという部分があってそれを使って本シナリオのギミックが組まれているわけですが、ちょっとイライラするかな?という感じがありました。まぁでも麻理乃シナリオよりはまだ没頭してプレイ出来たからそれなりにストレスは感じ難くはなってるのかな?朝陽シナリオ程じゃないけど。ただこの人のシナリオは、冒頭で書いたエロがスタッフロール後にしか無いって事と、あと一番最後クレアが遠方の大学に行って遠距離恋愛状態になるんですが、クレアが久しぶりに帰ってきておかえり、みたいな感じでの締めになります。これが、他のゲームだと大抵こういう場合は遠距離恋愛終了の瞬間まで引っ張ったり、そのシーンをちゃんと書いたりするんだけどそれが無いってのがちょっと不満に感じましたね。まぁスタッフロール後にエロ2回をまわした関係上、他のヒロインのシナリオよりも若干シナリオが長くなってるように感じたので、そこでさらにそこまで引っ張ってしまうと流石に長くなりすぎると感じたのか、或いは単にシナリオライターが疲れたのかは知りませんがwでもこちらとしてはやっぱり書いて貰いたかったと思いました。こういう話って、結果が安定してる状態で終わればプレイヤーも安心してプレイを終われますが、結果が不安定な状態で終わってしまうとプレイヤーはプレイ終了後安心出来ないんですよね。言うまでも無く遠距離恋愛状態ってのは不安定な状態なわけで、実際このネタを元にゲームが何本も出来てたりするわけですからこの状態で安心して終われってのは無理があります。純愛を完成させるなどと言ったゲームで終了後にプレイヤー心理を不安にしてどうするよ?という気がするんですがどうなんですかね。
とりあえず、残る最後のヒロイン。大食漢(いや、女だけど)七里由馬をプレイ後、オンリーワンを多分朝陽か未央でプレイして本作を終わろうと思います。
[20070710]
EC-CUBEをどうしてもWindowsで使いたいと友人が言うもんで、仕方が無いのでそのままWindowsで進めてる訳ですがWindowsであれ他のOSであれEC-CUBE自体はMySQLとPostgreSQLのOSSな2大DBMSに対応してるわけです。ただ、レンタルサーバーなんかだと普通はMySQLが入ってるので(というかPostgreSQLの入ってるレンタルサーバーって凄まじくレアな気がします。殆ど見ない)私も最初からMySQLでしかやってなかったんですが、ふとした気まぐれでPostgreSQLでもEC-CUBEを動かしてみたんです。MySQLからPostgreSQLへのデータ移行は、データレコード数がまだ総数で6000件程度だった為、MySQLでSQL文で吐き出させた物を加工してpsqlに食わせてという手動操作によるデータ移行でした。で、PostgreSQLで早速商品一覧画面などを出してみたところ、どうもPostgreSQLの方が速い。無論、MySQLもPostgreSQLもあまりチューニングは施してない状態ではあるんですが、それでも見た目ではっきり判る位PostgreSQLの方が速かったんですね。
将来的にレンタルサーバーに移行させるのであればMySQLでやった方が良いのは明らかなんですが、ただ今契約しているレンタルサーバーのPHPのバージョンの問題で、EC-CUBEがそのままでは動かない。友人の業務が特殊で(というかぶっちゃけアダルト方面)借りられるレンタルサーバーにも限りがある為、今のところ仕方が無いので自宅サーバーで行くか?という事になってるわけですがハードウェアの冗長性はどうしたってレンタルサーバーにかなう訳が無い。ここが悩みどころなんですが、結局自宅サーバーのWindowsで行くのであればデータベースはPostgresでやった方が良いという事になるのかもしれません。

2007-07-10(Tue) 13:49 雑記 | トラックバック(0) | コメント(0) | 編集 |
[20070708]
HONEY COMINGのプレイ日記3人目。麻里乃をクリアしましたのでその感想など述べてみたいと思います。
麻里乃ですが、一言で言ってしまえば貧乏になった新藤麗子といった感じでしょうか。
知ってます?新藤麗子。大昔、PC98がまだ日本のパソコンの大半を占めていた時代に出たゲーム、下級生のツンデレ担当の金髪お嬢様。歴史あるツンデレ好きの人なんかだと大抵は知ってるキャラだと思うんですが、今回はその麗子の家が没落して貧乏になった、という設定を思い浮かべればわりと理解出来そうな気がします。
多分今時のぬるゲーマーなんかには結構きつめのツンが長く続くので、相当のツンデレ好きでもないとこの多賀谷麻里乃というキャラを最後まで攻略するのはきついような気もするんですが、最後の方には懐いてくれますので安心して頑張って攻略してみてください。まぁ、こういう風なキャラだと最後までツン風味は抜けない方が良いとは思うんですが(ツンっていうか、イマイチ素直になり切れない風味?っていうかそんな感じがあった方が良い)今作では残念ながら、そこまではならないですね。最後の方にはわりと素直な感じになっちゃいます。HOOKといえば、オレンジポケットで前原羽弥という優秀なツンデレを作ってるので、ツンデレキャラに慣れてないって事は無いと思うんですが麻里乃はわりとブレンド加減を間違ってるような気もしました。最後懐くのであれば、寧ろツン期間はもっと短くして、且つドラマティックにデレへ移行させた方が良かったように思います。今回、デレ期への移行はわりとシームレスというか、かなり徐々に移行してる感じであまり落差を感じなかった為、実際かなり最初と終わりで差があるのにも関わらずあまりそれを感じる事が出来ない勿体無さがあります。
麻里乃ルートではクライマックスで、貧乏キャラが借金の片に嫌な金持ちの元の嫁ぐというよくある展開が発生しますが、割と初期段階で光一郎が止めに入って事無きを得ます。まぁ、正直止めに入ったところでその場では原因となった事柄はなんも解決出来てないんだから、それで思い直すくらいだったら最初から自己犠牲精神なんか発揮するなと言いたいところですがwそんな状態なんで独占嗜好な人にはこの部分でちょっとイラッと来るかもしれませんがそこまで深刻なシーンでも無いので流しておきましょう。個人的には、ここで自己犠牲精神なんか発揮せず、持ち前の気性の荒さと我が侭さでもって麻里乃が金持ちの親の所にまで殴りこんで止めさせようとしたところ、今回のぼんぼんの我が侭行動が金持ちの親父に発覚して敢え無くぼんぼんは全財産、権力などを没収、多賀谷家には迷惑金として幾許かの金が振り込まれる(ここで金で解決出来ると考える所が金持ち所以という感じで)という感じに展開してくれると、かなりベタではあるんですが個人的にはスッとして良かったかなって気もするんですがベタすぎでしょうか?ちなみにこの金持ちぼんぼんはかなりバカで、多賀谷家に圧力をかけて麻里乃をどうにかしようとしてるんですが、ここで圧力を無くしたければどうしろ、というような脅迫が無いんですよね。脅迫もなしにただ単に圧力をかけるだけ。これだと麻里乃がぼんぼんの元に行く理由がかなり弱くなると思うんですけどね。
でまぁ、最後は結局貧乏ながらも同棲するというエンドなわけですが、どうせだったら両親が旅行に行った先で何かヒントを得て、再び金持ちに返り咲く事が出来そうだけど、それよりは家族の幸せ云々とかいってその展開を蹴る、みたいな感じのがよりベタだけど良かったんじゃないかって気もするんですがどうなんでしょうかね。まぁ、単に私が金持ちにコンプレックスを持ってるだけだからこういう感想になるのかもしれませんがw
ともあれ、これでメインヒロイン5人の内3人をクリアしました。今気付いたんですが、どうやら私は公式のキャラクター紹介ページの順番通りに攻略してきているようなので、次もこの順番通りにクレアで行ってみようかと思います。正直そこそこ個別シナリオの長いゲームなので、一気クリアは結構疲れる為途中休憩挟むかもしれませんが、とりあえずクレアという事で。
[20070705]
どうやらオンリーワンモードについて解釈を間違えてたみたいだ。オンリーワンモードは、選択肢を排除してそのヒロインのベストエンドを迎えるのは勿論だが、それ以上にそのモードを一度選択したら以後そのモードではそのヒロインしか選べなくなる、正にオンリーワンという漢らしいモードだったw。これはこれで良いな、まぁ通常モードで一通り遊んでから改めて、かなこれは。
で、未央ルート。これもまぁ兄妹ものとしては比較的ベタな展開ではあるけど、なんか周りが異様なほどあっさり受け入れてるのは修羅場的展開はこの話に合わないと判断した結果だろうか?多分その判断はある程度正しいのだと思う。近親相姦スキーな人達にとっては恐らく物足りないものなのだろうとは思うが、私のようなライトな人間にとってみればそのようなヘビーな展開をやられても気分が重いだけでちょっとついていけなくなってしまうので。
ところで、演劇の為に腹筋を鍛える話があるんだけどこれって腹の筋肉を実際に増量するんじゃなくて、神経を活性化させるだけで良いのかな?実際やってる訓練では筋肉なんかつきそうに無いし。筋肉を付ける為には作中のように毎日腹筋するというのは間違いで、限界ギリギリまでの腹筋運動を3日に1回位の割合でやるのが一番良い。この時、この限界ギリギリというのが実際にはとても難しく、大抵の場合は正しいやり方をしないと限界ギリギリまでは届かずその手前辺りで終えてしまう為にいくらやっても効果が出ないという事になってしまう。正しい筋トレというのは実はかなりハードなものなのだ。
残念な点だが、未央ルートの主人公は朝陽ルートの主人公のような勢いを感じなかったな。朝陽ルート終了辺りの主人公の勢いはとても良く、ある意味理想的な主人公像といっても良いのではないかと思っていただけに少し残念だ。まぁ、それでもウジウジと悩むだけのヘタレ主人公じゃないだけずっと良いのだけれどwただヒロインの妹の方はよく判らない理由で身を引こうとしてたんだけど、あれは結局世間体を考えて云々の展開だったのだろうか?というか兄が妹としてしか見てくれないから身を引く、というのはなんか違うと思ってしまうのだが。それにエンディングもなんか弱いな。1年後、とかじゃなく未央が自信をつけてから、とかそういうのの方が良かった気がする。まぁこれはこれでアリではあるんだけど、この終わり方だとまだモヤモヤするなぁ。
それでもやはり全体で見てそこそこ満足出来る話ではあった。最近は妙に反抗的で、なつこうともしない妹も結構出てたからこういう素直で可愛い妹は心安らぐw。
次は似非お嬢様?ツンデレ?な麻里乃行ってみるかな。
[20070703]
EC-CUBEは純国産のECサイト構築ツールという事でこの先が楽しみなソフトではありますが、まだ機能が足りないというのは先日も書きました。で、最近はどうやら様々な決済サイトと提携してクレジットカード等の支払い機能の強化を図っている模様ですが、日本では余り馴染みの無いPAYPALについては考慮されていないのか、今のところPAYPAL支払い機能はついていません。ただ、付くまで待つというわけにも色々いかない事情という物もありますので無い物は自分で作るしか無い訳ですね。
ちなみにPAYPALですが、とりあえず私の知る限りではクレジットカード決済の出来るサービスとしては最安値と言って良いんじゃないかってくらい手数料が安いです。手数料の安さってのはショップ側には重要な要点ではないでしょうか?何しろ安売りのせいで利益はギリギリまで削っているのにその上クレジットカード決済の手数料で高額を要求されたのではショップ側としてはクレジットカード決済を導入する利点がまるでありませんから。まぁ、JCBが使えないという点が日本ではかなりマイナスに響きそうではあるんですが、それでもクレジットカードを持っている人の大半は恐らくVISAかMASTERのカードを持っているであろう事を考えるとそれで大体用は済みそうな気もします。(まぁ、ポイントの事を考えるとやはり自分が普段使っているカードが使えないのでは不便なのは間違い無いのですが)
で、まず考慮その1。PAYPALで支払う際にはPAYPAL側のショッピングカーと機能を使用するのか、或いはあくまでPAYPALには支払いのみを受け持ってもらうのかを決めなければなりません。PAYPALの場合、ショッピングカート機能を持っていないサイトの為か、PAYPAL自身にショッピングカート機能があり、それを利用する事で静的なサイトであっても(つまりHTMLのみで構成されるサイトであっても)基本的なカート機能を持ったショップを作成する事が出来ます。しかし今考えているのはEC-CUBEへの組み込みであって、EC-CUBEには当然自前のショッピングカート機能があるのでそちらを利用するのが何かと便利でしょう。という事でPAYPALは支払いのみを使う事にします。そうするとどこでPAYPAL支払いに飛ばすかという事になるんですが、私はとりあえず支払い方法でPAYPALを選んでいた場合、CONFORM画面で確認を押したら通常のCOMPLETE画面とは違う、COMPLETE2画面というのを新たに作ってそこに飛ばすようにしました。で、COMPLETE2画面にはPAYPAL支払い用のボタンを表示しておきます。これにより、お客さんは確認ボタンを押した後引き続きPAYPALによる支払いへ飛ぶ事が出来るようになります。この時、PAYPAL側に出来るだけ情報を渡してお客さんが改めて自分の住所などを入力し直す事の無いようにしたいのですが、どうも変数のvalueにEUC-JPを使っているとPAYPAL側で上手く受け取る事が出来ないようです。私は結局諦めて、PAYPAL側で改めて支払い請求用住所を入力して貰うようにしてしまったのですが、恐らくはCOMPLETE2画面だけはUTF-8のコードで作ってしまえば住所データや名前データを改めて入力させるお客さんの手間は省けるんじゃないかと思います。ここでEC-CUBE側の注意点ですが、PAYPALはどうやら今のところ日本向けにはモバイル用サイトを用意してないっぽいです。これは実際、今の日本のモバイルでのインターネット人口の多さを考えると実に痛いのですが致し方ありません。その内対応してくるとは思うのですが(今は米国とカナダだけなのかな?まだ)、とりあえず今はEC-CUBE側でモバイル利用のお客様はPAYPALを選べないようにしておかなくてはなりません。モバイル用PHPとPC用PHPとではわけてありますので、モバイル用PHPのshopping/payment.phpに細工をしてPAYPAL支払いが選択肢に出ないようにしておきます。
考慮その2。PAYPALでお客さんが支払い終わった後、ショップオーナーが一々PAYPALからのメールをチェックしてからステータスを入金済みにしていたのでは、手間が掛かるしお客さん側にしても支払いが反映されるまで時間が掛かるのでは不安になります。なのでPAYPALからの支払い完了通知の通信を受け取れるようにしておかなければならないのですが、PAYPALからの支払い完了通知は2種類用意されているようで、それぞれPDT、IPNという名前で呼ばれています。PDTというのは支払い完了後、お客さんがショップ側に自動で戻ってくるように設定し、その時ショップに対してGET引数で支払い通知のデータを一緒に渡してもらい、ショップ側はその支払い通知を再度PAYPALに問い合わせて正当性を確認した後に、その支払い通知自身の正当性をショップ側の受注デーブルと付き合わせる事によって確認し、ステータスを入金済みに移行させる方法。この方法では基本的に、お客さんが支払い完了後ブラウザを閉じずに大人しく待っていて、ショップ側に制御を移さなければ通知を受け取る事が出来ません。なので基本的にはIPNの方で支払い通知を受けるようにする方が良いでしょう。IPNというのは、お客さんがPAYPALでの支払いを完了するとPAYPAL側がその場で、予め設定してあったnotify_url変数のURLを呼び出すという物です。これはお客さんが実際今どの画面を見ているかに関わり無くPAYPAL側はショップを呼び出すので確実に情報が伝達されます。ショップ側はIPN受け取り用のWEBプログラムを1つ用意しておき、それでIPNを受信して各種正当性の確認をした後受注テーブルを書き換えます。このIPNで呼び出されるタイミング自体は保障があるわけでは無いので、とりあえずお客さんがショップに制御を戻したら支払い有難うございました画面を出しておき、それとは別で支払いの正当性を確認する事になります。もし実際には支払いが失敗していたのに支払い完了画面を呼び出して、ありがとうございましたの文面を出すのは不味いという事であれば、PDTとIPNの両方を実装する事になるでしょう。私はとりあえずIPNの方だけ実装しましたが、ロジック自体はIPNとPDTではそれ程大して変わらないので簡単に流用する事が出来るでしょう。注意すべき点ですが、最初にPAYPALに制御を移す際、受注ID,すなわちEC-CUBEではdtb_orderのorder_idですが、これをinvoice変数に設定しておく事です。invoiceにこの値を設定しておく事でIPN、PDTでの支払い金額通知と、実際の受注テーブルに書かれている金額とを比較して、支払い金額の正当性を確認する事が出来るようになります。またそもそもinvoiceを設定しておかなければIPNで正当性が確認できた後、dtb_orderのどのレコードのstatusを更新すれば良いのかが判りません。またお客さんにPAYPAL側からメールが届くのですが、invoiceを設定しておけば請求書IDとして受注IDが記されますので、お客さんからの問い合わせに対しての検索がやりやすくなります。invoiceは必ず設定するようにしましょう。
これらの注意をする事でEC-CUBEにPAYPAL支払い機能を組み込む事が出来るようになりますが、実際問題としてPAYPAL類似のサービスは今後どんどん出てくるでしょう。Googleの支払いサービスは、まだ日本では開始されてないっぽいですが、日本で開始されればPAYPALのライバルになりえるでしょうしショップ側としてはどの決済サービスを使うのかの選択を迫られる事になるのでしょう。まぁ、私はもうPAYPAL支払いを組み込んだので心境的にはPAYPALで行きたい気がしますが、こればかりはショップオーナーの意向ですのでねw
[20070702]
久しぶりにプレイ日記でも書いてみましょうか。お題はHOOKの新作、HONEY COMING
純愛は、HOOKが完成させるなどと大言を吐いたからにはそれなりの完成度を見せてくれないと納得出来ないとか思いながらプレイしましたが、成る程中々の完成度でした。_summerで散々眠い眠いと言われた反省点からなのか、話の起伏もそれなりにちゃんとしており、それでいて展開が急すぎたり説得力が0だったりという事も無く、見せるべきところはしっかり見せてくれました。結果的にボリュームにも満足の行く出来になり、よく出来た作品だと言えると思います。
今作は予約特典がわりと豪華だったんですが、それに気付いたのが予約特典のつかない場所で入札した後でした。まぁ、GAME-STYLEなんですけどね。ここで買うと大抵の場合は最低値の4600円で買えるのでどこで買うよりも新作を最も安く買えるという事で割りと重宝してるのですが、今作のような予約特典の豪華な作品に対してはSOFMAPとかメッセサンオーとかに頼った方が良かったかなぁと若干後悔気味です。まぁ済んだ事は致し方ありません。

朝陽ですが、まぁ所謂幼馴染でわりとベタな方な設定だとは思いますが変に奇をてらって結果的に大失敗している作品が最近多くなっていたので、寧ろこういうベタな設定で面白い話を書こうとする姿勢には評価する価値があると思います。無論、何もかもがベタなままで話の展開までベタだったりすると流石に唯の御伽噺とかになってしまうので、それはそれで不味いわけですが今作ではそんな事もなく、オリジナルにして良い所はしっかりオリジナルの風味を付けつつ守るべきところはしっかり守る、というちゃんと「わかってる」作りになっていると思います。幼馴染系の話でよくある展開だと、小さい頃から隣にいたから良さが判らない、だとか寧ろいつも同じ相手だと発展が無いからとわざと幼馴染を恋愛対象に選ばないようにする、だとか或いは気付いていながらも関係が壊れてしまいそうだから気付かないふりをしていた、だとかそういう設定がありがちなところなんですが今作の場合は、どちらかといえば3番目に近いかもしれませんがやはり―当然ではありますが―オリジナルの設定が混ざってます。今作では、主人公の親父が、小さい頃から恥ずかしい事を延々見せてきた為に主人公は恋愛という物に苦手意識を持つようになって云々というのが基本設定としてあるわけで、その流れで複数ヒロインに惚れられながらも変にヘタレたところのない、寧ろ漢気のある設定になっています。こういう純愛系モテモテ主人公タイプだと、主人公がヘタレ気味な場合が結構あるんだけど今作の主人公はあまりそういうウジウジ勝手に一人で悩んだりといった部分が無く、熱い魂を持っていてプレイしていて気持ち良かったですね。やはり男はこうでなくては、という感じがします。対するヒロイン陣も、割とベタな設定を持ちつつも一味工夫しているといったのが勢揃いで、純愛を完成、とまでは流石に行かないとは思いますがそれでも通過点にはなっているのだと感じました。

選択肢は多くなく、寧ろ話全体の長さから考えれば有り得ない程少ないですが、それは今作の方向性による所が大きいのでしょう。今作はゲームというよりは寧ろノベル、お話に重きが置かれている物であり余計な選択肢はかえって邪魔になるという事なんですかね?ゲーム開始時にゲームのプレイタイプを3つ選ぶんですが、そのうちの1つは最初にヒロインを選んだら後は完全に一本道で必ずそのヒロインとのベストエンドが迎えられる事が保障されている事からもその事が伺えます。他の2つでは選択肢が出てくるのですが、うち1つは選択肢選択後、その選択によって好感度がどうなったか、といった事が明示されます。つまり正解の選択肢だったのか間違った選択肢だったのかが即座に判るわけです。残り1つが所謂今までの一般のゲームと同じで、選択した結果は話の結果を見るまで判らないというタイプですね。まぁ、選択肢自体結果の予想がつきやすい物ばかりなので間違える事はほぼ無いとは思いますが、ここまで徹底して難易度を下げ、それでも難易度が低すぎるだとかいう文句を払拭する為にあえて今までのゲームと同じモードも用意するというのは中々気合の入った念の入れようで恐れ入ります。

朝陽との話はまぁ、わりとありがちとは思うしあらすじにして良さが伝わるような物でも無いと思うんで書きませんが、兎も角一般のゲームでは端折られがちな些細な事でも割と注意して描かれているのには好感が持てました。展開が遅すぎるという事は無く、しかし必要な部分はほぼ全て網羅し、そしてエピローグも十二分に長い。というかスタッフロールが流れた後の話がまた長いw。スタッフロールが流れた後で更にエピソードが3つ4つ出てきたりして、時々エピローグ中だという事を忘れる位余韻に浸らせてくれます。これは良いですね。こういうタイプのゲームは余韻が大切なんですが、このゲームはそれがちゃんとわかってます。最後は教師になって母校に戻ってくるという、これもまぁ割とアリガチといえばアリガチなんですが、でも良い展開だと思います。そうそう、私がわりと重視している独占、処女属性ですがwこれも特に(少なくとも朝陽に関しては)問題無いですね。これに関しては全クリアするまではまだ判りませんが、今のところ不安になるような要素は出てきていません。
クリアしたのは今のところ朝陽だけですが、これなら他のヒロインにも期待出来るなと思いつつ進めてみましょうか。
HOME
copyright © 2005 drednote(Mr.Ty) all rights reserved.

Template By innerlife02

RSS1.0 ,
RSSフィード

応援バナー

検索フォーム

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。