Sea Battle Game Recipe

Transcription

1 Sea Battle Game Recipe Paul Turley is a business intelligence solution architect and manager for Hitachi Consulting. He is a Microsoft MVP and Certified Trainer. He designs solutions and teaches classes on SQL Server technologies to companies around the world. Paul is the author of several books, including Professional SQL Server Reporting Services (2000/2005/2008). Robert M. Bruckner is a technical lead with the Microsoft SQL Server product team. His core area of responsibility is the development of the report processing engine of Reporting Services. Robert frequently shares Reporting Services tips on his popular blog at robertbruckner.

2 Sea Battle Game 591 SEA BATTLE GAME At annual industry conferences like the Professional Association for SQL Server (PASS) Global Summit and Microsoft TechEd, members of various Microsoft product teams participate in a session called the BI Power Hour. This is one of the highlights of the conference where teams that contribute to the Microsoft Business Intelligence platform show off their technology in a fun way. It is about demonstrating, in perhaps unusual ways, how business intelligence and various tools of the BI stack can be useful. In past years, Reporting Services made a number of successful contributions to these events, such as Hangman, report manager as report, Etch-a-Sketch, Mastermind, an executive dashboard (Tic-Tac-Toe) and others. This recipe is a variation of a popular multi-player game played with grids and pegs, that we shall call Sea Battle. The goal of the game is to sink all of your opponent s ships (for example, a Battleship), before the opponent has a chance to find and sink your ships. The faster you click, the better your chances of winning. The overall theme of the report is to demonstrate the use of interesting new data visualization features in Reporting Services It uses a chart with dynamic drill-through actions and data-point tooltips, gauges, and matrices with embedded images and other report items. While Reporting Services was clearly not designed as a gaming platform, this demonstration of the product s flexibility brought out the competitive spirit in the SQL Server BI team. Robert Bruckner said, When I made an initial version available for limited beta-testing on an internal report server, the news spread quickly and we immediately had more than 50 people playing, and frantically clicking on the chart s drill-through links trying to win against their human opponents. This created quite a bit of load on the report server that is also used by hundreds of other users, and provided a nice stress test scenario. In this recipe, you will review the design elements of a working report solution, rather than build the whole thing yourself. Product Versions Reporting Services 2008 or newer SQL Server 2008 or newer What You ll Need SeaBattle Start New Game.rdl SeaBattle.rdl SeaBattle.rds SeaBattle.bak - database backup Techniques Demonstrated Drill-through-to-self report action Chart report actions

3 592 PART IX GAMES Multiple parameters Parameterized expressions to set report item properties Using stored procedures to update data and return results Using custom images in charts and gauges Reviewing the Report To set up the environment and get started, follow these steps: 1. Restore the SeaBattle database from the provided database backup file. 2. Open the shared data source and test the connection to the SeaBattle database. 3. Using BIDS or Report Builder, deploy the data source file and both reports to the report server. To play the game, do the following: 1. Navigate to the Report Manager or the report server using the browser. 2. Run the SeaBattle Start New Game report. This will display a welcome message with your figure user name and a message prompting you to wait for another user to enter the game. 3. In a separate browser window on the same computer or from a different network location, open the same report. This time, the report will display the first user s Windows ID, prompting you to start the game. 4. If you are playing as a single user, simply use the second browser window to interact with the game report. If you have two users, refresh the first browser and begin playing the game. 5. In the large grid, located in the top-left area of the report page, click one cell at a time to try to locate and sink enemy ships. If two or more players are participating, take turns clicking the grid. FIGURE P9-4 Figure P9-4 shows the player opponent s grid which is used to visualize hits, misses and ships that have been sunk by clicking on the cells. A small matrix acts essentially as a data-driven grid control next to the chart to show your own ship positions and the opponent s hits and misses. The overall health status of the opponent s ships is shown using gauge report items with a custom pointer that uses an image to simulate a rising water level, as a ship sustains more and more hits (see Figure P9-5.) Successfully sinking a ship is rewarded with an animated explosion. The really fun part is the multi-player aspect: a basic method to match up two report users so they can play against each other by simply interacting with their report on a report server. Aircraft Carrier FIGURE P9-5 Battleship

4 Sea Battle Game 593 HowItWorks The SeaBattle report contains all the working elements for the game. Figure P9-6 shows an example of the report elements at runtime. The major components consist of a scatter chart that uses custom images to plot the position of your opponent s ships. The dataset returns a value for every position in the chart X-Y coordinates, so these data points show up as cells in a grid. The chart shows your strike misses and hits as the underlying table gets updated. This is the primary user interface. A drill-through action sends the position of each cell that you click and this action is recorded in the database, which then returns information about misses, hits and previously sunk ships. FIGURE P9-6 To the right of the opponent s grid, a gauge is used to let you know how well you re doing relative to your opponent. Below this is a matrix showing the placement of your own ships. The ship positions are generated automatically at the beginning of the game. In the lower section of the report, a matrix is used to display the progress of enemy ship strikes and sinks. For each ship, a wave image is displayed over the top of the appropriate ship. The height of the wave is modified to show how far down the ship is sinking based on the number of strikes. The following table shows all of the images embedded into the SeaBattle report. On both the opponent s grid chart report item and on your home grid, each ship is represented by individual ship sections. Different ships occupy a different number of cells composed of a front (or bow ), back ( stern ), and zero or more middle pieces. This is the reason that the aircraft carrier looks more like an extra-long battleship. Since ships may be positioned either horizontally or vertically on the grid, two different images exist for each ship element. Four completely assembled ship images are used to display the sinking status in the lower report section.

5 594 PART IX GAMES Image Name ShipFront ShipMid ShipBack ShipFrontVert ShipMidVert ShipBackVert Miss Hit AircraftCarrier Battleship Destroyer PatrolBoat Waves Sunk (animated image) The startup report (SeaBattle - Start New Game) uses a dataset referencing a stored procedure called NewGame, which serves two purposes; to begin a new game and to return the current game session for the second user joining once the game has been started. Three parameters are used to track the PlayerID, which is the network user name based on the UserID report global object; a GameID, which is generated by the first user starting a game; and the PlaySolo flag, used to toggle the game between solo and multiplayer modes. Upon close examination, the NewGame stored procedure establishes the number of players, cleans up the prior session if necessary, retrieves or derives a GameID and then returns a result set including the game and opposing player information.

6 Sea Battle Game 595 CREATE PROCEDURE SMALLINT = 0 AS AS BIT = 0 IS NULL AS INT AS SMALLINT TRANSACTION = COALESCE((SELECT MAX(GameId) FROM MatchUp GROUP BY GameId HAVING COUNT(PlayerId) = 1), 0) = (SELECT COUNT(PlayerId) FROM MatchUp WHERE GameId=@GameId) IF (@PlayerCount = 1 = 0) AS SMALLINT = (SELECT OpponentGridId FROM MatchUp WHERE GameId=@GameId) = 0 = ELSE = 1 = COALESCE((SELECT 1+MAX(GameId) FROM MatchUp), 1) = [GetRandomGridLayoutId] INSERT INTO MatchUp @PrimaryPlayer) -- initialize grid when primary player registers = 1 DELETE FROM [Grid] WHERE GameId AS SMALLINT AS SMALLINT = 1 <= 9 = 1 <= 9 INSERT INTO [Grid] VALUES NULL, NULL) INSERT INTO [Grid] VALUES NULL, NULL)

7 596 PART IX GAMES = 1 -- add computer player AS SMALLINT = INSERT INTO MatchUp VALUES (@GameId, 0) COMMIT ELSE = (SELECT PrimaryPlayer FROM MatchUp WHERE GameId=@GameId AND PlayerId=@PlayerId) AS NVARCHAR(50) = (SELECT PlayerId FROM MatchUp WHERE GameId=@GameId AND PrimaryPlayer<>@PrimaryPlayer) SELECT GameId, AS OpponentId FROM [MatchUp] WHERE GameId AND PlayerId To initiate the game, each player s grid layout must be defined with each ship in a randomized position. As you can see, the NewGame stored procedure calls another stored procedure named GetRandomGridLayout to perform this task. CREATE PROCEDURE SMALLINT = -1 AS AS SMALLINT = (SELECT MAX(GridLayoutId) - 1 FROM ShipLocation) AS SMALLINT = (SELECT 1+ROUND(@MaxLayoutId*RAND((DATEPART(ss, GETDATE())) + DATEPART(ms, GETDATE())* 100), 0)) = (SELECT 1+ROUND(@MaxLayoutId*RAND((DATEPART(ss, GETDATE())) + DATEPART(ms, GETDATE())* 100), 0)) When the first user opens this report, a GameID is generated and the game report waits for the first user to log in by running the report. When the second user runs the report, a link is displayed, prompting the users to begin game play. Figure P9-7 demonstrates the core technique that makes these two reports work. It shows one of a few similar report actions, which drill-through and pass parameters back to the same report. This is the technique we refer to as a drill-through-to-self report action. A dataset in the report then receives these

8 SeaBattleGame 597 parameters and passes them to a stored procedure as the report is executed after the user clicks the link or cell. FIGURE P9-7 After the first player has entered the game, the third textbox (titled Click to play against <player X>! ) on the report is displayed using a conditional expression. To see how this works, view the Hidden property for Rectangle1 and Rectangle2 on this report. The second link is a report action that opens the game board in a report named SeaBattle. The SeaBattle report contains two datasets named GameData and OpponentData. These are based on stored procedures named GameTurn and GameStatus, respectively. With each click of the opponent s grid, the X and Y coordinates for that cell are passed to the report as a drill-through-to-self report action. Note the parameters in the following stored procedure: CREATE PROCEDURE SMALLINT = SMALLINT = 0 AS -- are 0 during initialization or when -- executing GameStatus for the opponent player AS SMALLINT = (SELECT OpponentGridId FROM MatchUp WHERE GameId AND PrimaryPlayer

9 598 PART IX GAMES AS NVARCHAR(50) = (SELECT PlayerId FROM MatchUp WHERE GameId AND PrimaryPlayer -- return grid and ship data as PlayerName, G.X, G.Y, G.Hit, L.ShipId, L.ImageName, D.ShipType, D.Units AS ShipUnits, CASE WHEN G.X AND G.Y THEN 1 ELSE 0 AS LastHit, (SELECT COUNT(G2.Hit) FROM [Grid] G2 LEFT OUTER JOIN [ShipLocation] L2 ON (L2.X = G2.X and L2.Y = G2.Y and L2.GridLayoutId=@GridLayoutId) WHERE L2.ShipId = L.ShipId AND G2.GameId AND G2.PrimaryPlayer AS HitUnits FROM [Grid] G LEFT OUTER JOIN [ShipLocation] L ON (L.X = G.X and L.Y = G.Y AND L.GridLayoutId=@GridLayoutId) LEFT OUTER JOIN [ShipData] D ON D.ShipId = L.ShipId WHERE G.GameId AND G.PrimaryPlayer The GameTurn stored procedure is actually a wrapper around the GameStatus procedure. It accepts the same set of parameters, updates the Grid table with the current coordinate information and then executes the GameStatus procedure, which returns the updated game status information to the report. CREATE PROCEDURE SMALLINT = SMALLINT = 0 AS IF (@X <> 0) AND (@Y <> 0) -- update grid AS INT = (SELECT 1+COUNT(Hit) FROM Grid WHERE GameId AND PrimaryPlayer UPDATE [Grid] SET [Hit] = 1, [ClickSequenceId] WHERE GameId AND PrimaryPlayer AND X AND Y -- return GameStatus The effect of these actions is clear simply by running the report and playing the game. Although there are a few more details, the essential mechanics are simple: As each player clicks a cell on their opponent s grid, the drill-through action and subsequent GameTurn stored procedure call updates rows in the

10 Sea Battle Game 599 Grid table within the SeaBattle database. Calls to the GameStatus stored procedure return ShipLocation data to determine hits and misses and ultimately sinks, wins, and losses. Final Thoughts This report is an impressive example of the kind of dynamic interactivity made possible with some creative report design. Many of the report design techniques exhibited in this game have also been demonstrated in other recipes. This one just puts the pieces together in a different way. Regardless of the application, the essential components are the same: report actions that send parameter values back to the same report, database procedures or programming code that processes those parameter values and then modifies report item properties to change the user s experience. In this case, a completely interactive experience was managed by storing ship positions in a database table and updating another table with information about where players clicked within a grid. Credits and Related References Several members of the Reporting Services product team were instrumental in creating the SeaBattle reports used in the BI Power Hour conference demonstrations. Thanks to Robert Bruckner for gathering the details and posting information about this demonstration to his blog at Robert includes some additional information about setup and optimized play.