The daily reset logic of the hand-travel service-side framework

Implementation Background

The series has been on the ground for so long that no business code has been written. In fact, I think so, because the business code of different game items is very large, business logic only you can not imagine, no planning greatly unexpected. If you want to be a more aggressive framework, the less business code is arguably the better. But think twice, still try to construct some game public business, also be the example code of this set of frame.

People who have played mobile games should know that no matter what game it is, the logic of the daily reset will often occur. For example, the player will have a copy of the maximum number of times a day, the player to buy a product also has the largest number of daily purchase ... One feature of these businesses is that there is a daily limit and the next day is reset. As for the next day is 0 point reset, or 5 point reset, it depends on the operation of the project update time. Daily Reset Business Considerations

The logic of the daily reset seems simple, and it takes a bit of effort to achieve it perfectly. Because the daily Reset has this feature:

1. The way in which players are handled at home and offline is different;

2. When you reset daily, consider thread safety and avoid concurrency problems.

For the first question, our approach is to deal with the players at home, and we perform the reset business sequentially by traversing the list of online players. Offline players are more troublesome, and it is not possible to remove all the players from the database and dispose of them. In fact, we can deal with the player login, when the player log in every day, we will be the player's reset identity and the system public reset time comparison, if not the same, you can perform the reset business.

For the second problem, consider the threading concurrency problem, which is combined with the asynchronous threading model used by the system. Because our threading model is load-balanced based on the player's distribution ID. Therefore, the daily reset should also adapt to it. The application of quartz in the game

Quartz is a very good job scheduling framework. In game development, we often use quartz to achieve fixed-point tasks and frequency tasks.

Using quartz, you only need to introduce the associated jar package, and then use the configuration file to configure the task trigger. Daily Reset Business Implementation 1. First, we define a timer event based on the current threading model. This event needs to be met and is thread-safe for the execution of the player's business. Also, for extensibility, this event can set the number of timer executions. To achieve thread safety, just allow the timer event to inherit from Abstractdistributetask. For specific reasons, refer to the thread model article in this series the message threading model for the hand-side framework

/**
 * Timer Task
 * @author Kingston/Public
abstract class TimerTask extends Abstractdistributetask {
	
	private int currloop;
	/** is less than 0 for unlimited task * *
	private int maxloop;
	
	Public timertask (int distributekey) {This
		(Distributekey, 1);
	}

	Public timertask (int distributekey, int maxloop) {
		this.distributekey = Distributekey;
		This.maxloop = Maxloop;
	}
	
	public void Updatelooptimes () {
		this.currloop + + 1;
	}
	
	public Boolean Canrunagain () {
		if (this.maxloop <= 0) {return
			true;
		}
		return This.currloop < This.maxloop;
	}

}

2. The player resets the Timer event daily (Dailyresettask) as long as it inherits the TimerTask.

public class Dailyresettask extends TimerTask {

	private player player;

	Public dailyresettask (int distributekey, player player) {
		super (Distributekey);
		This.player = player;
	}

	@Override Public
	Void action () {
		System.err.println ("Player" +player.getname () + "make daily Reset");
		Playermanager.getinstance (). Checkdailyreset (player);
	}

3. Write Quartz homework. Assuming that our daily resets occur at 5 o'clock every day, we can add such a configuration to the jobs.xml.

<!--daily Reset-->
<job>
	<name>DailyResetJob</name>
	<group>default</ group>
	<job-class>com.kingston.game.cronjob.DailyResetJob</job-class>
</job>
<trigger>
	<cron>
		<name>DailyResetJobTrigger</name>
		<group>default </group>
		<job-name>DailyResetJob</job-name>
		<job-group>default</job-group >
		<cron-expression>0 0 5 * *?</cron-expression>
		<!--run every 05:00-->
	</cron>
</trigger>

4. Quartz in debugging, must be running on their own thread. When the job trigger is reset, we iterate through all the players and perform a daily reset business for each player. In this process, we need to encapsulate the trigger point into a timer event and throw it into the main line of business Chengri processing. These operations are implemented on Dailyresetjob.

/**
 * Daily 5 o ' clock job
 * @author Kingston/
 @DisallowConcurrentExecution public
class Dailyresetjob Implements Job {

	private Logger Logger = LoggerSystem.CRON_JOB.getLogger ();

	@Override public
	void execute (jobexecutioncontext arg0) throws Jobexecutionexception {
		Logger.info (" Daily 5-Point scheduled task start ");

		Long now = System.currenttimemillis ();

		Systemparameters.update ("Dailyresettimestamp", now);
		Collection<player> onlines = Playermanager.getinstance (). Getonlineplayers (). values ();
		for (Player player:onlines) {
			int distributekey = Player.distributekey ();
			Encapsulates the event into a timer task and throws it back into the business thread processing
			TaskHandlerContext.INSTANCE.acceptTask (new Dailyresettask (Distributekey, player));

	}

}

5. For offline player processing, we need to record the reset time in a public system table (Systemrecord). In the Dailyresetjob.

Systemparameters.update ("Dailyresettimestamp", now);

When the player logs in, check the Loginmanager.handlselectplayer () method. The login logic occurs when the player sends a login message and the threading model that is in the architecture itself is thread-safe.

/** *
	 Login *
	 @param session
	 * @param playerid/public
	void Handleselectplayer (iosession session, Long playerID) {
		player player = playermanager.getinstance (). get (playerID);
		if (player!= null) {
			//bind session with player ID
			Session.setattribute (sessionproperties.player_id, playerID);
			Add online list
			playermanager.getinstance (). Add2online (player);
			SessionManager.INSTANCE.registerNewPlayer (playerID, session);
			Push into scene
			resplayerenterscenemessage response = new Resplayerenterscenemessage ();
			Response.setmapid (1001);
			Messagepusher.pushmessage (session, response);
			
			
			Check Day resets
			playermanager.getinstance (). Checkdailyreset (player);

		}
	

At this point, the game's daily reset business introduction to here is over.


Hand Tour Service End Open source Framework series complete code please go to GitHub->> Jforgame