isuru89 / oasis Goto Github PK

A Challenge is a rule which will be executed within a limited amount of time, and if not, gets expired.

• Curators can create a challenge focusing on a user or a team or a game.
• Challenge can be played only by users of that team or game.
• Challenge always has an expiring time. After that time, the challenge will be stopped.
• A Challenge can be defined as won by the first user or first N users.
  • After that, any other users will be neglected by the challenge.

Users can play along milestones.

• Milestone must have a finite amount of levels.
• Milestones should be defined only using aggregation functions.
  • Sum of points
  • Sum of KPIs
  • Count of events
• Milestones does not have deadlines or end dates. They are playing forever.
• When someone has achieved maximum level of a milestone, that milestone will be considered as completed for that user.
  • Should be awarded an special badge and bonus points.
• Milestone values can only be ever monotonically increasing.
  • Penalty values or negative KPIs will be aggregating separately along with milestone

Hi,

Is there a guide to know how to deploy the solution? I am using windows environement.

thanks,

Currently when an application needs to get the feeds, it has to crawl through several tables.

It is better for performance that to have a separate notification table to search from it.

Later this gives ability to integrate easily with external notification mediums.

Currently if we insert a gamification element to the db and delete it, later we can't insert by the same name again.

Currently all db functions are stored with db module itself. But there can be moments where modules needs to deploy their own functions with db.

• Should be able to bootstrap while running engine or running api server
• Consider duplication function handling coming from two different module
  • should throw a meaningful exception in such scenario

Users can spend achieved points to buy somethings from shop.

• Game admin can define shop items which can be available to buy.
• Some items might be available after achieving certain milestones / states
• Some items might be expiring within certain time limit.
• Users can buy an item as long as user has necessary points.
• Users can buy the same item multiple times.
• Users can share a bought item with another user.
  • For free or for another price.
• Item sharing unlocks badges.
• Leaderboards can be defined based on purchased items/cost.
• Purchasing does not reduce points and changes ranks in point leaderboards.

It is better to introduce an attribute to a badge as a feature identification.

Such as a badge can be marked as platinum, gold, silver, bronze based on levels.

So leaderboards can show badges based on these attributes.

Provide a capability to award badges from race wins, such as,

1. Being top ranked for N times.
2. Being top ranked for N times consecutively.

Badge module should provide methods to query badge details for external parties.

• Query Badge List for an optionally provided date range
• Rule wise badge winners
• Badge count queries

Other than to points and rank, leaderboard may show the rank change relative to the previous day/week.

The rule is,

• when a user's points have not been changed since last time => No change
• Points have changed
  • Rank increase => diff of rank
  • Rank decrease => diff of rank

Challenges module should provide query methods to retrieve challenges related information to external parties.

• Query all current winners of a challenge under a game
• Query all winner counts of challenges under a game
• Count of the challenge wins by a user by date range
• User's challenge winning log with ranking

Points module should provide query methods to retrieve point related information to external parties.

• Retrieve user's point distribution based on rule, team, and source
• Retrieve leaderboard statistics
• Return user's ranking on different leaderboards

Currently there is no way of knowing progress of achieving a badge which needs to complete a streak to get it.

It is better if user can see the current progress of achieving next badge.

To minimize the failures in the engine, the definition add service must have strict validations on adding elements.

• KPI
• Points
• Badges
• Milestones
• Ratings
• Challenges

Hi, is there any documentation about this project? For example, the endpoints details/parameters, authentication, etc...?

Ratings module should provide query methods to retrieve rating related information to external parties.

• Rating changing feed of a particular user
• Ability to query ratings of users for a rating rule under a game

Currently injector insert records into the database one by one, which is very inefficient.

And should use batch queries to insert buffered records as a batch, so the network overhead will be minimized.

When a user is added, that user should belong to the global default team.

When user is first time logged-in, allow user to choose his/her favourite character for playing game.

There are predefined set of characters which user can select which is defined by admin at the deployment time.

User cannot change his/her character once chosen, but the admin can modify by the request of the user again only once in a lifetime. In such change, user will lose all his/her character purchases.

Such change of character should not affect to leaderboards, points, badges or any other game scoring mechanics.

Integrate the project with TravisCI and Code-Coverage online services to monitor projects build status.

An admin should be able to define rules which automatically activate/deactivate only for a specific season/time period.

For example, the admin/curator may want to define a particular rule which active only for the summer. (1st of July to 30th of September).

This time range can take several forms:

• Absolute time range (1st of June to 30th of September, Christmas day 25th of December, Every Friday)
  • This is easier and a user should be able to define multiple ranges within a single time period.
  • Daily time ranges (8am to 5pm)
  • Weekly time ranges (Monday to Friday)
  • Annual date ranges (1st of May to 31st of August)
  • Provide a custom check implementation
• Relative time range (1st week of every month)
  • This is not straightforward, because, to identify this kind we may have to use cron expression (?) which could be a performance hit to check each and every time a rule set derived.

Leaderboards can be two types.

• Point leaderboards - leaderboards based on achieved points.
• Item leaderboards - leaderboards based on shop item purchases.

Characteristics:

• User can be in a minimum three leaderboards at a given time.
  • Global ranking: across all team scopes.
  • Within team scope: across all teams.
  • Within a team: across all players in a team.
• All points of a user will be reset when that user has changed the team
• Leaderboards can be defined using,
  • Aggregation with set of point rules
  • For a time range
• Every leaderboard will have three rankings for each user above three different scopes.

Currently leaderboard considers only total points. Therefore, in case of a tie breaker, there is no other parameter to be used.

Leaderboard could also consider total event count (for total points) as a tie breaker.

Currently all points are referred by rule id. However, there is a case where some rule to produce same kind of points, so the engine needs to support this point grouping. This is useful in Milestones where it needs to accumulate points which will be generated from several rules. Having one common id is easier.

For ex, if there are two points rules having ids: point-rule-1 and point-rule-2 but user need to generate same point type out of those two rules, then user should be able to specify it like common-point-id.

Implementation: With every point rule, there will be a mandatory pointId field indicating point id.

Some fields of element definitions are not easily identifiable with their field names.

When a user is defining a leaderboard, the user should be able to define the display unit for aggregated points along with dashboard.
By default, when unspecified, the word 'points' will be used.

User should be able to change the label accordingly. Eg: Gold, XP, etc.

When a redis cluster is used, we need to use hash tags to support intelligent distribution of keys across all shards.

It is better to store same game data in a single shard rather than across several shard to support lua script execution too.

Players in the game are users.
User can have only one role at any time. Anyone can play a game at anytime.

1. Admin
   • Setup when deploying the OASIS
2. Curator
   • Are assigned by admins.
3. Player (default)
   • Are assigned to teams by curators

• Users are always in a team.
  • Users cannot play without in a team.
  • Users cannot be in two different teams at a particular time.
• [ ] A Team is always in a team scope.
• ~~[ ] Team Scope is a grouping of several teams.~~~
  • [ ] Team scope is similar to a project/department.
• A team name and team scope name must be globally unique.
• [ ] When a Team Scope is created, a default team will be created.
  • [ ] A default player will be created for the team scope under the default team.
• When a Team is created, a default player will be created by the name of that team.
  • [ ] This default team, which will be created when creating a team scope, will not have a default player
• Teams cannot be deleted but only disabled.

We should not query database everytime we want to get a leaderboard ranking, but we can cache it for a considerable time when no points or states are updated.

Point rule can be specified to mark as gold or not, so that whenever a balance is calculated only rules specified will be taken into account.

Point Rule may have a boolean field called isCurrency. Default value is true.

Ratings indicate the current KPI state of a user.
Unlike milestones, which are accumulating, a rating can fluctuate to any direction (increasing or decreasing).

• User can only be in one rating at any given time.
• When the rating of the user becomes changed, points will be awarded, if specified.
• When not specified, user will be in the default state as defined in the state rule.
  • When no condition satisfied, the rating will fallback to the default state (only specified)

Users should be awarded badges based on points or patterns.

• Badges can be given based on a simple condition.
• Badges can be given by satisfying some constraints continuously (streaks)
• Badges can be awarded when has done something(s) within a certain time period.
• Badges may award from point rules and milestones.
• Badges can have sub-badges.
• Badges can be defined in a way which a user can have only limited amount of badges from same types. By default, user can collect same badge many times unless otherwise definition allows so.
• A badge achievement can cause to award additional points to the user

Badge Patterns:

• First time doing something
• Exceeding some KPI thresholds
  • X achieved amount of P or higher
  • X achieved amount of P or lesser
  • X achieved amount of exactly P
• Doing something continuously N times
• Doing something continuously N times within certain time period T
• Getting P points within a day/hour/week.
• Daily histogram
  • On continuous days
  • On separate days

Time Constraints:

• Time considerations will always be into the past
• Events should consider for last X time-units relative to the current time
  • within last N days/hours
• Event should consider fixed time range relative to the current event time.
  • within daily, monthly, weekly.

• Provide a necessary and easy method to submit rules by reading a file
• Provide an easy method(s) to change the game state
• Support loading referenced game definitions parts from a file recursively if needed

Races are based on leaderboards and awards points according to the top ranking at a particular time.

• A race must have an associated leaderboard.
• In addition to that admin can define,
  • When to award (daily, weekly, monthly)
  • How many people should be awarded (top N), or
  • Minimum point threshold to award points
    • Only one of top N or point threshold can be specified at a time.
• Race point eligibility
  • When there is only one player in team/team scope, then no player will get points.
  • When there are players less than requested top N, only the top player will get points.
• Race calculation must be able to invoke from externally as well (using an game key)

Milestone module should provide query methods to retrieve milestone related information to external parties.

• Return single/multiple milestones status for a user
• Milestone status of the given set of users under a game
• Summary count of users for a milestone attributes-wise and team-wise.

An admin/curator should be able to configure a rule with restriction of maximum earned elements within a defined period, so that preventing users collecting too much elements.

This is inspired from Stackoverflow where a user can only earn maximum of 200 reputations for a day.

To have API documentation, integrate swagger to the Oasis.

When specifying element definitions, there should be a property to specify the revision attribute so that engine can identify whether the element should be replaced or not

It is better to support supplementary durable databases like MySQL or MariaDB to store admin data, rather than only in Reids.

Users should be awarded points.

• Points will be earned from KPIs, ratings, and challenges.
• Curators can award points or disallow points manually.
• Points will be always calculated in BigDecimals and rounded to 2 max decimal points.
• Can be positive and negative (penalties)
• Every point must be recorded with timestamp against the user and team.

Point Rules:

• Point rules cannot be deleted. Instead, they can be disabled and create a new one.