| Summary: | After the maintenance of the playing area is finished, i.e. the area is refilled, gravity is executed and there’re no more destroyable items left, there’re still more destroying pipeline outputs appearing showing either nothing changed or a single item is | ||
|---|---|---|---|
| Product: | CandyCrush 2020 | Reporter: | jli262-c |
| Component: | Source Code | Assignee: | jli262-c |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | ||
| Priority: | --- | ||
| Version: | 2.0 | ||
| Hardware: | PC | ||
| OS: | Windows | ||
|
Description
jli262-c
2020-12-02 20:30:11 HKT
Reason: It is caused by a race condition from a recursion structure created during executing. Originally, destroyDestroyable() will try to execute any prop it encounters immediately. In such a scenario, multiple destroying pipelines will be started. One pipeline is considered as finished only when it finishes all possible maintenance. Thus, the latest pipeline should finish maintenance on the playing area and output the final result. However, as it is a recursion structure (useItem() call destroyRoutine() call useItem() call destroyRoutine()...), the earlier pipelines haven’t finished executing. They will continue looking for destroyable items and output their result, which is after the actual final result. For example: 1.The user executes a prop A. 2.Prop A marks corresponding destroyable items. 3.Prop A starts a destroying pipeline #1. (useItem() #1 calls destroyRoutine() #1) 4.destroyDestroyable() #1 of destroying pipeline #1 encounters another prop B and executes it immediately. (destroyRoutine() #1 calls destroyDestroyable() #1 and destroyDestroyable() #1 calls useItem() #2) 5.Prop B marks corresponding destroyable items and starts another destroying pipeline #2. (useItem() #2 calls destroyRoutine() #2) destroyDestroyable() #2 of destroying pipeline #2 destroys all marked items and 6.destroying pipeline #2 finishes. The playing area and words “Swap success!” are printed to the console. 7.The bug rises here. Notice that we expect the program to stop and wait for next user input here. However, by backtracking we can find that destroyDestroyable() #1 hasn’t finished, as well as the whole destroying pipeline #1. Although everything is completed by destroying pipeline #2, pipeline #1 will continue executing, resulting in redundant output with nothing changed. Solution: add an array boolean pending[][] so that props and their calling of destroying pipeline will be executed sequentially. If one prop is executed, other props it encounters will be turned into pending status. After the pipeline finishes, the program will go back to execute other pending props. Details in 5.5 Pipeline of using a prop in Analysis and Design. |