みんなで新しいレシピ検索サイトを作ろう - 1151929568

1：スキル77.4：2006/07/03(月) 21:26:08 ID:zeazUVqI: 某サイトが売却されようとしています。
代替サイト案をみんなで考えよう

>>1-10 関連スレとか
2：スキル77.4：2006/07/03(月) 21:26:33 ID:zeazUVqI: FFrecipe サイト売却
http://live19.2ch.net/test/read.cgi/ogame/1150947165/
moogle.yappo.jp の中の人だけど用事ある？
http://live19.2ch.net/test/read.cgi/ogame/1151559695/
3：スキル77.4：2006/07/03(月) 21:28:06 ID:zeazUVqI: 62 名前：既にその名前は使われています[] 投稿日：2006/06/30(金) 03:19:25.82 ID:TdpmAyC+
作るもの
○アイテム、装備ステータス、食事効果ステータス、合成分解レシピ、店売り価格、オークション価格、バザー相場、ユーザーアカウントのDB
○上のDBを弄るAPI
○上のAPIをXML-RPCとかSOAPとかAtomPPとかで弄るインタフェイス
○そのDBのデータ
ここまでが再配布可能物（ユーザーアカウントデータは再配布しない）
データに関してはP2Pみたいな仕組みで各サイト間で補完しあいたい所

○上のAPIを使ったWebサイト
○ユーザー登録とかの処理
○上のユーザーの認証のTypeKeyみたいなやつ（ID/Passを漏らす事なく、このサイトの認証を利用して他サイトにアクセスできるやつ）
これは、プログラムとかの公開はしない
4：スキル77.4：2006/07/03(月) 21:28:28 ID:zeazUVqI: 63 名前：既にその名前は使われています[] 投稿日：2006/06/30(金) 03:27:06.17 ID:TdpmAyC+
○アイテム別のwikiみたいなの
○アイテムのお気に入り機能（amazonのウィッシュリストっぽいの）
○合成コストの自動計算ツール
○blogと連携できる何か（MTとかWikiとかのプラグイン書いて、アイテム名の自動リンクとかもいいよね。はてなダイアリーっぽいの）
これは自分が作ってもいいし、WebAPIとか認証APIをつかって誰かが作るのもありかなぁ。
WebAPIつかって検索サイトを他の誰かが作っちゃうのも全然ありだし。
5：スキル77.4：2006/07/03(月) 21:29:21 ID:zeazUVqI: 79 名前：既にその名前は使われています[] 投稿日：2006/06/30(金) 13:30:04.14 ID:36K9xcCa
SourceForgeでオープンで開発するのもいいかもね
同じようなことやってた影Moogleは閉鎖しましたが(´・ω・｀)

http://sourceforge.jp/projects/openmoogle/
http://openmoogle.sourceforge.jp/project/

85 名前：既にその名前は使われています[] 投稿日：2006/06/30(金) 17:45:50.35 ID:TdpmAyC+
>>73
それでもいいんですが、各自レシピデータをメンテしてたら労力がすごい無駄ですよね。
国土地理院の位置データみたいに、どっかで情報を集約して配布する奇麗な仕組みがあると
データメンテは各自少しづつやってって、残った時間で自分とこのサイトの拡張ができるかなぁと。
「みんなで作ったデータだから、誰でも自由に使えるべき」って感じで。
それでも、管理する中央サーバみたいのが必要だから、将来的に争いの種にはなっちゃいますねー
6：スキル77.4：2006/07/03(月) 22:03:41 ID:5Rci/0wU: この流れで>>3のプロジェクトページ候補地のURL張るのは蟻ですか？
7：肉 ◆/FfqwuqTMI：2006/07/05(水) 00:35:43 ID:UZQH1oOI: こっちに移ります。
製作はとんでもなく遅いと思うので期待しないっていう方向で。

後、yappoさんの方がスキルも製作速度も上だと思います。
私はWEB版ばななの機能として盛り込むために作るので又別物で。

現状出来ているのは、↓な感じの投稿フォームで
ttp://vanana.sakura.ne.jp/images/webanana007.jpg
レシピの追加、削除が出来る所まで。

編集、追加はヴァナモンの様にWiki方式です。
8：肉 ◆/FfqwuqTMI：2006/07/05(水) 00:46:06 ID:UZQH1oOI: ↑の図から変更する事。
・まず、アイテムテーブル、レシピテーブルを別にする。
・アイテムとレシピの登録フォームを別にする。
・HQのテキストボックスの位置をアイテム名の下に。(続けて入力出来る様に。)
・スタック数を「1,12,99」からの選択にする。
・三つ目のサブスキル削除
・前後方一致でアイテム名を検索して手間を省くように。

・画像に書かれたキー入力でSPAM投稿対策。(※出来ればやる)

×レシピの追加、削除が出来る所まで。
○レシピの追加、”編集”が出来る所まで。
9：肉 ◆/FfqwuqTMI：2006/07/05(水) 00:49:36 ID:UZQH1oOI: 追加
・必要スキルの削除

データのライセンスについて
Wiki方式で誰がどれをいつどのように編集して、誰にどれだけ権利のウェイトがあるか
分かりづらくなりますので、当然の事ですが二次配布可にします。
10：スキル77.4：2006/07/05(水) 01:27:48 ID:sqJli0iU: 肉さんいらっしゃい。
全部サゲてちゃ何なので一応上げておくよ。
ではmoogle.yappo.jpの中の人ともども良い開発を
11：スキル77.4：2006/07/05(水) 01:37:07 ID:s9eiaH6A: >>7
製作速度は激遅モードだったりします。
おおまかなネタは脳内にあるですが、ばくだんいわの「様子を見ている」のノリで空気を読んでる感じです。結構ずるいですね。
万が一FFrecipeが崩壊したら速攻で行動には移るですが、ちまちまスルー煽り叩かれつつ形にしていこうかなぁと。

UIは最近流行物のサービスっぽく突拍子の無い物にでもしとこうかなぁと。

>>8
> ・画像に書かれたキー入力でSPAM投稿対策。(※出来ればやる)
最近はネコクリックが熱いですyp！
12：スキル77.4：2006/07/05(水) 01:44:08 ID:s9eiaH6A: というか、自分も登録インタフェイス周りだけは考えてみるかな。
13：スキル77.4：2006/07/05(水) 01:56:10 ID:kRlAwur2: ＤＢの設計をやってみよう。
まずアイテムは名前が同じのがあるので、これをIDには使えない。
番号ふるしかないだろう。
効果などはアイテム種別によって異なるのでテーブルを分ける。
名前は言語別のテーブルに分ける手もあるが、少ないのでフィールドでいいか。
説明文も名前と同様だが、著作権が絡むので分離。
あとはスタック数やエクレア宅配トレード種別のフィールドを。

レシピもIDにできるフィールドが無いので、番号を振る。
フィールドは、スキル・素材・クリスタル・完成品(NQ/HQ)・分解かどうかの合成種別。
スキルは7つのフィールドでいいな。報告途中を考慮して上限の最大値と最小値の２つで。
素材や完成品は一つのフィールドに押し込めたくなるものの、検索がlikeになっちゃうな。
レシピIDと素材IDと数をフィールドに持つテーブルを定義するのＤＢ効率は良いが、プログラムが面倒か。
ここは諦めて、素材８つ用にフィールドを用意する。
完成品についてはアイテムIDだけでなくて数もいるな。
ああ、あと最近は特殊合成もあるのか。
14：スキル77.4：2006/07/05(水) 02:15:13 ID:s9eiaH6A: >>13
名前とIDの件については、アイテム名称変更の事例や入力ミスに対応する必要があるので必須ですね。
IDをkeyにして変更履歴も保存しておくと良さそうです。

前から思ってるのが、合成/分解という物をシステムとして分けて認識する必要があるのか？
という点です。
正直分解なんて腹子しかやってないので良くわかってないですが、どうなんすかね？
材料に使うアイテムが一つだけだったら分解と見なせるような気もします。

>素材や完成品は一つのフィールドに押し込めたくなるものの、検索がlikeになっちゃうな。
なんだかんだ言ってそんなにデータ量はないからデータメモリに乗ってlikeでも気にならないかも。
気になったらcacheするなり検索系のライブラリ入れるなり考える感じで。

各種IDに関してもシーケンシャルな数値IDにすると嫌な予感もするので、ハッシュなIDにしちゃうのも手かなぁと。
データサイズもトラフィックも、そんな神経質になる程の物ではないはずですし。
とかいって一日100万query来たら笑うですが。

正規化云々はなやみどころですな。
15：スキル77.4：2006/07/05(水) 11:28:13 ID:1R9W6QqQ: IDはｆｆ本体に合わせてね。アイテム名や説明文も解析して抜き出してね。
そうじゃないと、何が未入力で何が入力済みか調べるの、手作業でつきあわせることになるからねｗ

>>14
分解と合成は違う。成功率も違うし、「得た」「合成した」だっけ？文章も違う。
雷クリ使うけど分解じゃないものもあるし。きっちり分けて考えるべき。

>>13
テーブル設計はffrecipeの真似すればいいじゃん。まんま真似じゃなくてね。
14のメモリに持てばいいってのは同意。全部持ってもたかだか数M。
でもそうするとサーバーを2台に分けるとかのとき大変かもね。
16：スキル77.4：2006/07/05(水) 18:51:53 ID:63/8VlGo: 既存システムのDB設計は追加要素に追いつけてない所も多い、ffrecipeも例外じゃない。
一から組めるんなら組んじゃっても良いと思うよ。

名目上、ゲーム内部のIDがいいのは同意なんだが
・ゲームデータのID刷新があった場合どうするか
・解析前提となるとシステムに解析データを仕込むか解析データを持ってる登録人が必要になる
と、問題もある。

>>14
腹子って通常合成でしょ？
いわゆる分解は成功率/HQ発生にスキルが関わらない物の事。
17：13：2006/07/05(水) 22:44:17 ID:kRlAwur2: >>15
DB設計は著作物だからね。
新サイト作る大義は倫理なのだから、盗み返すようなことはやめた方がいい。
幸い自分はデータダウンロードしたことないので好きに考えられる。

>>14
オンメモリにしていいならまた別の設計ができるけど、
実際PHPとか使うわけでしょ。
リクエストの度に全データをロードするわけにもいくまい。
18：肉 ◆/FfqwuqTMI：2006/07/06(木) 00:27:09 ID:Re8Da8Yg: こんばんは

>>11
私は取り合えずばななの方で必要性もあったので、どうせいつかやる事なら
今から少しずつでも着手していこうかなと。
私の方はUIはそんなに詳しく無いですし、無難な物でいこうかなぁ。
負荷はFFrecipeさんからそんなに人が流れてくるとは思えないし、
現時点では大丈夫かなと思っております。

そしてネコクリックについて必死に検索する自分
19：肉 ◆/FfqwuqTMI：2006/07/06(木) 00:43:37 ID:Re8Da8Yg: ＞DB設計
うちはMoogleのDBを拡張して
登録日時、ID、名前、クリスタル、素材１～８、メインスキル、ランク、スキルごとの上限、
Ex、Rare、説明、スタック数、特殊合成、説明、メモ
で一テーブルと、同様の内容でバックアップにもう一テーブル作ってます。
ここから、説明、Ex、Rare、スタック数は省いて
登録日時、ID、名前、説明、補助説明、Ex、Rare、スタック数、メモ
でアイテム登録用のテーブルを作ろうかと。
20：スキル77.4：2006/07/07(金) 13:26:41 ID:H.jlxxG6: >>15
> でもそうするとサーバーを2台に分けるとかのとき大変かもね。
そんな事ないっす。というか家に置く場合は結果的に複数台構成になるし、P2Pっぽくするしでイケます。

解析データについては無しの方向で。FF11の偉い人にいいよって言われればやるけど。
結果的に同じ文字列が登録されるから同じ事になりそうだけど。。。
手段が違うだけでおんなじなんですよね。。。

>>17
PHPじゃなくてmod_perl使ってapacheの拡張モジュールとして動かす感じで。
メモリに乗るってのは、scriptとかにいちいちloadするんじゃなくて
結果的にOSのキャッシュに乗り続けるからon memoryになるよって事です。

>>18
ランダムに猫画像を配置した画像を作って、猫がある所をクリックすると認証が通るロジックです。
読みにくい文字を入力しなくていいし、マウスだけでオペレーションできて癒されるので人間に優しい。
21：スキル77.4：2006/07/07(金) 13:47:27 ID:7E0VH.UQ: moogle.yappoで解析使ってるのにいまさら使わないってアホかと
22：スキル77.4：2006/07/07(金) 15:28:41 ID:4qWKu5g2: 内部キー用のIDとは別に解析IDのようなものも
フィールドとして登録できるようにしとけばいいんだろうか。

解析データを誰が管理するの？って話になるから
必須ってのはどうかなーと思うのだけど。
23： ゴブクラ管理者 ◆1Ebj/BJ5c6：2006/07/07(金) 20:02:53 ID:avfG0Q8U: 今回のことを機にわたしもデータベース化しようかと、
手をつけ始めました。

上のほうであまりあがってないものですと、
レシピテーブルに
　隠しレシピフラグ
アイテムテーブル
　宅配不可フラグ
　バザー・トレード不可フラグ
　ロスト率

ロスト率は完全に判明しているわけでは有りませんが、
アイテムごとに設定されていそうなので、追加してみました。
（なし、中、高の3段階）

NPCの地図表示は若干てこずりそう（あとまわしになるかな）

あとはUIが使いやすくてかっこいいものになるといいのですが。
これが一番つらいorz
24：肉 ◆/FfqwuqTMI：2006/07/07(金) 20:50:23 ID:8gNX4BpQ: ネ実のスレでアイテム名はjavascriptで子窓開いて～という意見してくださった方、
こんな感じでしょうか。(住所入力とかでありがちなのにしてみた。)

http://vanana.sakura.ne.jp/images/webanana008.jpg
25：肉 ◆/FfqwuqTMI：2006/07/07(金) 21:09:31 ID:8gNX4BpQ: >>20
ネコクリックってあれの事だったんですか～
GDとクリッカブルマップ使えばいけそうですね。

>>23
こんばんは、いらっしゃい。
隠しレシピっていうのはNPCから教えてもらえないやつですよね？
私は合成はどれも60前とまりで意識した事無かったんですけど、
どういった場合に参考にする物なんでしょうか？
26：スキル77.4：2006/07/07(金) 22:17:12 ID:tTtN0d62: >>23
競売取引不可フラグ、競売カテゴリー、存在未確認フラグ　も欲しいな。
とかいいながら、ffrecipeのごちゃごちゃいろんなデータ追加しないって姿勢もいいなーとも思ってる。

個人的には隠しレシピかどうかは、全然気にしないな。
ロスト率は異常に高いものがあるってなんか聞いた覚えがあるけど、
ほとんど検証されないような気がするから、文章で注意書きあればそれでいいや。

>>20
解析データを使用していい？って■に聞けば、立場上だめってしか返答できない。
でも聞かなければ何もいってこない。大人の事情ってやつです。
アイテム8000くらいあるけど、手で入力する気…？

>>22
IDを二つも持つ意味はないかと。混乱の元。
27： ゴブクラ管理者 ◆1Ebj/BJ5c6：2006/07/07(金) 23:32:23 ID:avfG0Q8U: >>25
隠しレシピか否かは利用するだけの人には必要ないかも
しれませんね。
ごくたまに、隠しと知らなくて「聞き出せないヽ(;´Д`)ノ」
って言う人が現れます。その程度ですかね。

>>26
競売不可はすっかり抜けてました(´Д｀;)ヾ
競売カテゴリーは追加の方向で考えてみます。
存在未確認は注釈欄に記述でどうでしょうかね？

23では書いてませんが、わたしもFFID欄を作る
方向でやってましたが、なんかいらないですかね(´・ω・｀)

隠しレシピ、FFID、ロスト率などはあえて項目を作る
ことはせず、レシピ注釈項目を作ってそこに入れるって
程度でよさそうかな。