6

Zend フレームワークで同様のバッジ システムを実行する必要があります。

実装方法がわかりません。イベント/オブザーバーと、チェックするアクションをトリガーするいくつかのアクション、またはたとえば10分ごとに実行されるcronなどについて考えました.

何か案は？

4

4 に答える 4

17

クライアント用のゲーミフィケーションプラグインを作成したDjango開発者として、私はStackOverflowとBigDoorをインスピレーションとして使用しました。ゲーミフィケーションは非常に簡単で、同時にひどくおかしくなります。

データベースにすでにUserテーブルがあるとすると、アプリケーションのゲーミフィケーションのコアは、「Currency」と「UserCurrency」の2つのテーブルを使用します。Currencyテーブルには、「名前」という1つの必須フィールドがありますが、「説明」もお勧めします。ゲーミフィケーションレイヤーへの管理インターフェースを作成する場合、説明は非常に役立ちます。

CurrencyUserテーブルには、ユーザーのID、通貨のID、およびユーザーが獲得したその通貨の金額の3つがあります。

「通貨」はゲーミフィケーションの流行語です。それはお金を指すのではなく、あなたが追跡しているものが何であれそれを指します。たとえば、SOは、あなたが出した賞金の数、投票数、自分以外の回答に賛成した回数、および回答の賛成票の1つが10を超えた回数を追跡します（最後の1つに注意してください：あなたではなく、他の人がそうします！）これらのイベントごとに、SOは基準のリストを実行し、関連する通貨を取得し、満たされたイベントに対して新しいUserCurrencyをインクリメントまたは作成します。

インクリメントが発生すると、それもイベントであり、機能の2番目の層がトリガーされ、しきい値を超えるとバッジが授与されます。

SOには「秘密の」バッジもあります。知っていましたか？これらのバッジは取得できませんが、フラグは別のテーブルに設定されています。編集の権限、コメントの権限、Wikiの管理の権限などです。

これを明確にするために秘密のバッジについて言及します。通貨を授与するユーザーイベントを追跡するためのコードは、アプリケーションに緩く結合された1つの独立したプラグインであり、バッジにつながる通貨イベントを追跡するためのコードは、2番目の独立した緩く-結合されたコード、およびアクセス許可につながる通貨イベントを追跡するためのコードは、3番目の独立した緩く結合されたコードです。それぞれの内部は、それぞれの間のAPIが明確である限り、他の内部を失うことなくある程度変更できます。

したがって、ゲーミフィケーションは簡単に記述できます。

それはまた、一体として難しいです。SOは、ユーザーに何をしてもらいたいかを真剣に考えていたため、インスピレーションを得ています。プログレッシブパーミッションシステムは、ひどいトローリングを防ぎます。バッジシステムは、最初からバッジシステムについてユーザーを教育します（「最初の投稿バッジ！」）が、ユーザーがさらに何ができるかについてもユーザーを教育します。バッジの名前と説明は楽しく、洞察に満ちており、ユーザーはより多くのことを学ぶことができます。「ゲーミフィケーション」はエンゲージメントだけでなく、ユーザーに「Xを理解したので、Y賞を獲得できます！」と伝える一種のドキュメントです。あなたがそのマークを打つことができないならば、gamifiyingを気にしないでください。

于 2011-09-02T17:12:55.447 に答える
1

私は次のようにアプローチしています。最初に、新しいバッジと条件が将来追加され、それらの一部は長期にわたって使用されるため、最初から、事実上すべてのユーザーアクティビティがイベントとしてログに記録されます。

私が取り組んでいるアプリはeラーニングゲーム/プラットフォームであるため、イベントタイプはクイズ、ユーザー、コミュニティのようなもので構成され、その中のイベントは次のようなものになります:(クイズの場合）回答質問正しく、回答質問が正しくない、クイズを完了する、（ユーザーの場合）ログイン、ログアウト、プロファイルの完了、（コミュニティの場合）質問をフォーラムに投稿する、フォーラムに回答を投稿する、回答の評価が+1など...

すべてのイベントはタイムスタンプを取得します。

バッジ/レベルなどを完了するための基準は関数に格納され、関数の名前はバッジのあるテーブルにあります。これにより、テーブルをシンプルに保ち、コードのより創造的な使用を活用することができます。

cronは短い間隔で実行され、イベントテーブル内のすべてのバッジ/レベルなどのキューを通過し、ユーザーアクティビティのログと相互参照されます。つまり、ユーザーがログインしたときにのみ、ユーザーはキューに追加されます。

これに伴う提案、特に。スケーラビリティに関してはありがたいです！

于 2011-08-02T21:53:59.067 に答える
1

トリガーを使用して実装します（疑似コード:)

On update votes_table create new row in users_points (how_many, for_what, when, ...);
on update users_points call check_if_enough_for_some_badge();
于 2011-04-26T18:31:48.077 に答える
1

私はそれをしたいと思います：

  • ユーザーのための多くのパラメーターを作成します (質問への回答、得られた投票など)
  • このパラメーターの前提条件でバッジを作成します (5 つの質問に回答、10 票を獲得など)。
  • ユーザーを更新するたびに、新しいバッジを確認し、それらをユーザー バッジに含めます。

私はそれがトリックを行うべきだと思います（：

ユーザーが新しいバッジを取得したときにユーザーに警告する必要がない場合は、毎回バッジを探す必要さえありません。前提条件に一致するバッジを表示するクエリを実行するだけです。

于 2011-04-26T18:12:44.123 に答える