Exploring Puzzle Games: Block Man!!

Transcription

1 CSE212: Fundamentals of Computing II Final Project May 7, 2004 Exploring Puzzle Games: Block Man!! Game developed by Alfredo Arvide, David Redenbaugh, Rick Very 1

2 Exploring Puzzle Games: Block Man!! Alfredo Arvide, David Redenbaugh, Rick Very University of Notre Dame Abstract. Blockman is a puzzle game we invented where you control a player, Blockman, and navigate him through a maze of blocks to the finish. The safe path to the finish must be created or manipulated by pushing blocks and avoiding the Badguys. Gameplay uses simple rules and offers an engaging evironment to hone problem solving skills. The version of the game presented here holds great potential for creation of more levels and block types for further expanding user s mental skills and encourage development of better strategies. 1 Keywords templates, GUI, inheritance, puzzle levels, block types 2 Introduction Block Man is a project that implements a turn-based puzzle and strategy game. Block Man is made up by a board where a main character, Block Man, gets to overcome obstacles that the maze filled board might put in his way. Along the way, Block Man might encounter blocks that must be moved out of the way clearing a path to victory at the finish square. Block man must also watch out for fierce Bad Guys that will follow him and eat him if he is not careful enough. Once Block Man reaches the end of the maze, he must not sigh in relief, rather he must get prepared to face more challenges for this game has multiple levels. Just watch out for the last level, where a Boss will keep you from winning the game. 3 Rules of the Game: Like every game, this game has its own rules that we defined before we started to make the code for it. First of all, there is a board which the character will go through, and find the finish. This board has walls that he is not allowed to cross, and has to overcome certain obstacles. To make this game worth playing, we gave it a lot of though on what these mentioned obstacles should be. We decided to create two types of blocks: movable and unmovable. The unmovable blocks are self explanatory, they would serve as walls and as obstacles that the character would have to go around. The movable blocks on the other hand, we decided to make more interesting. First, we created the infinite movable block, in other words, this block can be moved all over the board unless it gets stuck in a corner. Furthermore, we created blocks that would add a certain twist to the game. These blocks would have a finite number of moves. We created a 3 move block, a 2 move block, and a 1 move block. Therefore, you can only move these blocks as many times as they are designed to move. Also Block Man is only stong enough to move one block at a time, so he cannot push a block if there is another block in the place it would take. This makes the game fun to play because some levels are designed to allow only one way to go through. If that certain path is not followed, then the user will have to reset the level and start over because the level is in a deadlock and can no longer be solved. Also, we wanted to add more obstacles, so we added a Bad Guy that would follow around the Block Man and try to catch him. If the Bad Guy were to catch the Block Man, then Block Man would loose his life and the level would have to be restarted. 4 Implementation Our basic approach was to create a set of classes using object oriented design (OOD) to create the different kinds of blocks and characters and then have collection of these contained within a board. The main intent was to create objects that were relatively independent, so that each object knows the information about itself

3 and has basic functions to access and modify this information appropriately. We looked at Sokoban: a system object case study about OOD for guidance on a possible approach to distributing responsibilities since they worked with a game similar to our idea (see References). A basic overview of Sokoban, you are a warehouse man who pushes crates around a room and try to place them back on their shelves. This is not too far from the basic idea of our game, so the different UMLs they provided and the discussion of the advantages and disadvantages of the distribution of responsibilities provided a good example framework. Our general plan was to create blocks of two more specific types, players and actual interactive block objects, and then a board which contains pointers to these blocks. Each block type will keep track of its ability to move further, the block objects will know what kind it is and keep track of the moves left. The players know their coordinates and the number of moves they have made. However since the blocks and players movements depend on what surrounds them we chose to have the board control the movement of the pieces and set up the levels, so it controls and monitors the main part of the game. For the full UML of our class hierarchy see Figure Blocks Players First we had a player classes inherit from the block class and the goodguy and badguy then inherit from the player class. These are the only pieces that can push other blocks. The goodguy is controlled by the user and takes directions through input (by cin for the text based version or through buttons or keystrokes in the GUI) to navigate the board. The badguy needs to get its directions from the program instead of the user so it has a basic random function to choose this, unless the artificial intelligence we created tells it a smart move to make. For more on the AI of the badguys see the discussion of the board. Interactive blocks We chose to implement three special block types that have specific uses in the puzzle, a stationary block, an empty block and a finish block. Their capabilities are fairly clear based on their names and they serve these functions. The stationary blocks cannot be moved by Blockman regardless of its position, they are just too big and heavy for him to move. They are placed in the level to act as walls and generally provide an unwanted obstacle for Blockman in his quest to find the end of his maze. The empty blocks are technically not blocks from the perspective of the user, they fill the place of the void places in the maze where Blockman can travel freely without impedence. This way the user can still be given a representation of space while still having the board know that something occupies that coordinate. Pushable Blocks The blocks that can be pushed by Blockman are under an abstract class called pushable block that inherits from block. Under this class we chose to use a template class that has a type for the block and the number of allowable moves the block begins with. This class, called movable, inherits from pushable block so that it has all of these properties and then it is very simple to add new kinds of blocks. For this project we chose to have four kinds of movable blocks, one-move, two-move, three-move, and unlimited-move blocks. Because we used the templates, many more variations of movable blocks could be easily created. An example could be blocks that can only move in the horizontal or vertical direction, adding another intriguing twist to the game play. Each of these blocks monitors its move count and after each move decrements its count, this means that board can use the query functions of the specific block to check the status of the blocks remaining moves. 4.2 Board Movement Operations The board is the most complex part of our project because it has the most responsibilities to manipulate the pieces that inhabit the board. The Board has a 20x20 matrix of pointers to block types and special added pointers for the human players and the bad guys so that they can be easily moved in the game. The board moves pieces by essentially switching the places of two adjacent blocks (or three if Block Man is pushing a block object). This makes the movement simple and avoids the problems that accompany unnecessary destruction and creation of blocks. This works because the number of each type of block in a particular level never changes, so Block Man in essence pushes his way through the board, and each empty block he displaces simply goes behind him in his wake. One primary function that is called to move a piece, given a direction and the player that is trying to move. Since the players are the only active 3

4 members on the board all the other blocks react to their activities. The board has query functions that check for the type of block in the space being moved. Based on this information, it proceeds to check if this is a valid move based on the rules and if invalid the board is left unchanged. If it is valid then the board tells the blocks and swaps the pointers in the board matrix. Levels Each level is custom designed, ranging from a simple introduction level to challenging opponents and mind-bending puzzles. Each level is a separate function that initializes the board matrix and is called through the choose level function. The biggest advantage this customization has it that it gives modularity to our code allowing for more future levels to be added. If the number of levels were expanded, it might be more appropriate to create a new class, but since we only had a few levels in this project, they were kept as functions within the board class. Due to the unique character of each level layout, each level was designed by specifying each individual coordinates. The board has data members to know the current level, a Boolean value for whether the level is over, and an integer value to tell the result of the level. Badguy Artificial Intelligence Since the badguy needs to know about the Block Man and the other pieces on the board, we placed the AI in board class. The functions for the AI check within a visibility range and if Block Man is found he will try to move toward Block Man. In cases where Block Man is not visible then the Badguy alternates between random movement and imitating the last move of Block Man. 5 Graphical User Interface The approach we took to develop the Block Man game was by implementing two different building blocks, the GUI and the Driver. The GUI was developed using Win32 API in C++. This allowed us to manipulate Bitmaps and make buttons by using standard windows calls. The driver on the other hand, was a text based edition of the game. This game worked without a problem, so when the GUI was finished the two were integrated through the use of only six functions, hence the GUI is independent from the game, but they work together. This approach made our lives simple because we knew that the game worked, and we were only having GUI problems. The Graphical User Interface (GUI) for Block Man consists of three parts: a Game Board, a Help Menu, and a Moves Menu. Each of these sections of the GUI are embedded into one window that puts the user in control of everything at the same time. If the user needs to know what a certain block does, then the user only needs to consult the help menu, and a quick sentence or two will advise the user what to do. 5.1 Game Board The Game Board keeps track of where the character is, and what is happening at a certain point in the game. The game board is made up of several bitmaps that are part of an array. Therefore, the only thing that the GUI does is ask the matrix of objects what bitmaps to put at what position. It works really nicely because that test based version of the game that we developed independently works on its own, performs its calculations, runs smoothly, and then the GUI just displays the present status of the game. This is done by indexing the Bitmaps in a Bitmap Array. Each Bitmap corresponds to a certain integer from 0 to 28 and each object knows what number they represent (including what state they are at for movable blocks). 5.2 Help Menu The Help Menu is a very nice thing to have, especially in a game that has not been developed before. When you play Minesweeper, you know what to do because it is a famous game. But no one knows what to do with Block Man when the game starts. So the Help Menu is there to help out. If you have a question on what each block does, then you can click on the picture, and advice will be displayed on the screen. 4

5 5.3 Moves Menu The Moves Menu allows the user to pick whether they want to play with their mouse, or their keyboard. The Moves Menu allows the user to click on several buttons that will help you navigate the Block Man to the finish line. The user can also use the keyboard, and either method is encouraged. 6 Future Plans With a game that is fully functional at the basic level, we have future plans to further improve the gameplay experience. The first obvious addition to our game is more new levels. This is easily accomplished due to the way we have implemented the level changes. Also, we may add new types of blocks which behave in new ways and present new inherent problems. The last major development we would like to create is a graphical level editor. This would require writing a whole new program to input a levels design and would also require a way to externally save game levels and load them into the game. The other improvements we would make are fixing any bugs as they are discovered. We have fixed many of the bugs as we have discovered them, but one bug, however, has perplexed us and we have given up on it. When a person starts the Block Man game, then switches to an AOL Instant Messenger window (any version, including AIM express) and switches back to Block Man, the game has problems with printing the boards display. The only fix we have found is to resize the window. This resets the board printer, a process we cannot duplicate in our code. 7 Summary For our project, we chose to develop a puzzle game based on principles from Pac-man and Sokoban. This puzzle game has simple rules but also has a large capacity for scalability. We successfully implemented the game in the console. We developed the graphical user interface while we worked on the console implementation. When the console backend was nearly completed, we then began to link up the GUI we had designed to the actual gameplay functionality. Once we had the basic gameplay working in the GUI, we turned to tweaking the interface. This required learning many nuances of the Win32 API. We were able to get the game working completely with the GUI interface. We then developed eight basic levels with the capability of building many more. 8 Resources Winprog.net This website has a tutorial ( for the programming of the Win32 API. GUIs. After reading the entire tutorial we were able to understand how Graphic User Interfaces worked. Basically, each window is created separately, and each one has its own procedure. In the procedure of each window you are able to specify what kind of window you would like, that is a Child, a Parent, or a Dialogue Box. After the windows are created, the WinMain() function has to be defined. This function allows us to handle and process messages that the environment might throw to our window. For example, if My Window is open, and a button is clicked, our WinMain function would process that event and post a message in our buffer. Then inside our window procedure we would tell our window what to do. Winprog.net has a good explanation of the basic workings of the GUI. Hence this tutorial was essential to the development of our GUI. Microsoft Devlepers Network (MSDN) The MSDN Developers site was a great source of information. When we needed to know the parameters for a certain function call, the MSDN website had all the answers. We looked to this webpage to answer most of our GUI questions, and indeed it helped much. We originally had made the game to be played with the mouse, but we wanted to provide our users the option of using the keyboard too, so we found the Virtual Keyboard functions at the MSDN. This allowed us to map all the keys in normal keyed keyboard to their respective names (i.e. the message VK ESCAPE corresponds to the Escape key). For more info visit 4fqw.asp 5

6 ACMDL Sokoban: a system object case study It is available on the website This article comes from the ACM International Conference Proceeding Series archive from the Proceedings of the Fortieth International Confernece on Tools Pacific: Objects for internet, mobile and embedded applications - Volume 10. This article gave a valuable approach to optimized OOD for Sokoban, a game similar to our Block Man. Its structured and methodic approach was useful in deciding what responsibilities of each object in our game would be and which would be delgated to other class objects. 9 Appendices Fig. 1. the crew: (left to right) Rick, ALfredo, Dave 9.1 Biographical Information Alfredo Arvide A Junior at the University of Notre Dame, and a Computer Engineering Major helped with the development of this project. He currently works as a Peer Mentor for the Introduction to Engineering Systems 111/112 class and plans to do research with Professor Wolfgang Porod, PhD. on Quantum Dots and their future applications as transistors. His goals include graduating in 2005, make a breakthrough while working for a prestigious company, and marrying his beautiful fiance Melissa. David Redenbaugh David, sophmore at the University of Notre Dame, finds life on north quad means excessively long walks to the lab but added to the excitement of longs hours staring at a screen. An avid fan of mentally challenging games made him an instant addict to Blockman. Uncertain what he wants in life, he is looking for challenges with a creative side and secretly hopes to pursue art and design related activities while in computer engineering. Richard Very Rick is currently a sophomore at the University of Notre Dame. On campus, he lives in Alumni Hall, but hails from Pittsburgh, Pennsylvania. When hes not trying to keep up with all his Computer Science work, he can be found surfing the internet or playing the latest computer games. 6

7 Fig. 2. UML diagram of heirarchy 7

8 Fig. 3. Screenshot: intial screen Fig. 4. Screenshot: game in progress 8