Role-Playing Game: The Legend of Tenka ECE 145 Winter 2001 Jason C Chen ID# 13399819 Professor Pai Chou March 17, 2001
TABLE OF CONTENTS INTRODUCTION... 1 Research Motivation... 1 Motivation for Reader... 1 BACKGROUND AND RELATED WORK... 2 Websites... 2 Newsgroups...3 Electronic Documents in CodeWarrior IDE... 3 Project Specification... 4 Role-Playing Game... 4 Game Modules... 5 Platform-Specific Issue... 6 User Interaction... 7 Project Design... 7 Description of Modules... 7 Header Files... 8 1. Animation.h... 9 2. Combat.h... 9 3. UIConstant.h... 9 4. Other Important Functions... 9 Development Plan... 10 Project EVALUATION...10 Concluding Remarks... 11 Credits... 13 Bibliography... 14
Table of Figures Figure 1: Division of Labor ------------------------------- 1 Figure 2: Hardware Specification -------------------------- 2 Figure 3: GUI Flow Chart ---------------------------------- 3
INTRODUCTION PalmPilot, also known as Personal Digital Assistant (PDA), has been popular recently because of its portability and flexibility. It is small enough to fit into a pocket and yet powerful enough to do many tasks that used to be solely for personal computer. In addition, the PalmPilot only costs a fraction of an ordinary personal computer. Many software and hardware developers have realized the potential PDA possesses and rush to put their products onto PalmPilot platform. Believing that PalmPilot is going to be a ubiquitous electronic device such as cellular phone, my friends, Barry Chen and Jack Yuang, and I decided to develop a role-playing game (RPG) as our senior research topic Research Motivation There are two main reasons behind our decision to design an RPG. One reason is that all three of us devoted large amount of time on either console or computer games. In myriad of game genres, RPG is the most entertaining because it offers a fantastic world for player to explore. The other reason is that we have always wanted to produce a game. After playing numerous game titles, designing a game that encompasses every great quality that great games possess becomes an unspoken dream for us. The senior research project offers Barry, Jack, and I a chance to design and program an actual game Motivation for Reader Why should the reader be interested in this project? Three great incentives for readers to take notices: C programming, project design, and game development. The most obvious reason would be the C programming experience that one would learn from this project. The project is purely software based. For anyone who is interested in C language and wants to see how C is being applied to a real working program, this project offers a systematic evolution of the game 1
development. In addition, the readers can see how a project is designed. A project does not assemble itself into a working model, instead careful analysis of proposed components and specifications are required to model a successful project. Lastly, for readers who love RPG and, too, like to program a RPG game, this project would offer a great insight on how a RPG can be implemented. BACKGROUND AND RELATED WORK Websites PalmPilot is handing industry a big lesson <http://www.geocities.com/researchtriangle/lab/3533/palmhist.html> This site gives a quick overview on palm s evolving history. It contains several interesting facts. Palm Inc. Software Connection http://palmcomputing.palmgear.com/palm/shareware.cfm This web site contains numerous links to PalmPilot application. I obtained some of RPG idea from this site. Palm OS Connected Organizers http://www.the-gadgeteer.com/palmos.html An excellent website for general Palm handheld devices. I visited the website to get a general understanding of PalmPilot designs. Palm Inc. Palm IIIe Handheld http://www.palm.com/products/palmiiie/ This website offers a detail description of Palm IIIe model. I obtained the hardware specifications from the website and posted information under Projection Specification section. 2
Newsgroups Pilot GCC Programming Newsgroup news://news.massena.com/pilot.programmer.gcc A great newsgroup ground for C programmers programming for PalmPilot. The newsgroup concentrates UNIX C programming, however. Pilot Jump Programming Newsgroup news://news.massena.com/pilot.programmer.jump A newsgroup dedicated for Palm programming in JUMP and JAVA language. Although I am using C to program the game, I believe this newsgroup will be helpful for people who like to program in JAVA. Pilot Programmer Newsgroup news://news.massena.com/pilot.programmer General Palm programming newsgroup. I have only visited this newsgroup a couple times because it does not concentrate on C language. CodeWarrior Programmer Newsgroup news://news.massena.com/pilot.programmer.codewarrior This is the newsgroup that I visit most frequent because it concentrates on programming using CodeWarrior. Electronic Documents in CodeWarrior IDE Palm OS SDK Reference An excellent reference document for anyone who is interested in programming PalmPilot in C language. The documents lists all the commands and functionality that one would ever need to program application for PalmPilot 3
Palm OS Programmer's Companion. The Companion document describes the programming philosophy behind PalmPilot application. The document also explains major programming components of PalmPilot. However, the Companion does not list the actual programming functions. CodeWarrior Palm OS Tutorial for Windows. The tutorials covered in this document are excellent. It portrays the program development in fine detail. In the Tutorial, one would learn every fundamental function required to build a successful application. CodeWarrior Constructor for Palm OS Platform. This documentation contains detailed instructions regarding form resources. Every resource is covered in its own chapter. If one is ever interested in designing graphical user interface for palm, the CodeWarrior Constructor is a must-read. PROJECT SPECIFICATION Before one could start writing an application for PalmPilot, one must first layout the project goals. A clear-defined application format is vital to the development phase. With a clear-cut format, the project may deviate from original specification. In addition, a well-thought project specification will enable division of labor. It is important if the project is being share by multiple members. A huge amount of effort and time could be waste if the division of labor is not defined properly. Role-Playing Game A role-play game, as its name implied, require a player to assume a role. In general, this role would be a hero or avatar that will defeat a legendary nemesis, or final boss. The player will be given with a low-level character in the beginning of the game. He or she must increase the 4
character s statistics through myriad of battles and quests. A compelling storyline must accompany the character s evolution or the game will be nothing but hack-and-slash. To advance the storyline, a quest system is implemented. The quest system will lead the player through a series of trial, and within each trial, a player will learn pieces of story. Sometimes a random quest system will be implemented to lessen the linearity of the storyline. Because our project is a role-playing game, the only input that the game will accept is from the user. The game will respond accordingly to user s input. Our game may sometimes generate random events without user s intervention to enhanced to game playability. To program a game with high entertaining value, re-playability, and under the hardware constraint of Palm IIIe, we decided to the game more text-based rather than graphic-based. Game Modules We divided the game into several modules: story, database, quest system, graphic, monsters, inventory, combat system, town system, and world-map system. After defining the major modules, we organizes the modules into three major groups, as seen in Figure 1, and each one of us will be responsible for one group. My task is the Graphic User Interface (GUI). One Figure 1: Division of Labor 5
may notice that some topics are overlapped. The overlapping topics are necessary become some topics requires cooperation between groups. The combat system, for instance, requires a GUI section to interact with the users, but the system also requires access to player and monster statistics. Platform-Specific Issue We use Palm IIIe as the application development platform. The following information Size and Weight Operating System Palm IIIe handheld Applications Palm IIIe Desktop Software Display Hardware Expansions Battery Life Connectivity IR Port Storage Capacity Items Included in the Box 4.7" x 3.2" x.7" ; 6oz Palm OS 3.1 software Date Book Address Book Desktop e-mail connectivity* To Do List Memo Pad Expense Calculator Security Games HotSync technology for local and remote synchronization with your PC. Date Book Address Book To Do List Memo Pad Expense Desktop e-mail connectivity* Desktop import and export formats: CSV, TAB delimited, and TXT Palm OS 3.1 software. Enhanced screen technology easier to see at all angles, in dim light, and in bright sunlight. Hardware add-on components (such as modem) via serial port. Approximately two months life on two AAA alkaline batteries. Internet ready with TCP/IP software included to enable Internet-based applications and e- mail. Beam your business card, phone lists, memos, and add-on applications to other IRenabled Palm Computing platform devices. Use third-party beaming applications with IRenabled phones, printers, etc. 2MB stores approximately 6,000 addresses 5 years of appointments 1,500 to-do items 1,500 memos 200 e-mail messages.* and lots of third-party applications. Palm IIIe handheld Palm Desktop organizer software Two AAA alkaline batteries DB-25 adapter Getting Started Guide Handbook HotSync cradle. Figure 2: Hardware Specification 6
on Palm IIIe is obtained from Palm Inc. Palm IIIe Handheld web site previously mentioned in the Background and Related Work section. User Interaction The game will be running as a Palm OS application. When the player enters the game by tapping the application icons, he or she will see an introduction describing the fantasy world and its history. After the introduction, the player will have the freedom to either start a new game or load previous saved game. The user will also be able to adjust the difficulty of the game and the text displaying speed. Easy game setting will allow users to start with stronger character and fighting lower-level monsters. Hard game setting will does the opposite: weaker character with higher-level monsters. PROJECT DESIGN Because I am responsible for the graphic user interface, I will only discuss GUI dimension of the project. I have designed a flow chart, so I can break down the GUI into modules as seen in Figure 3. Description of Modules Introduction Give players a brief description of the game world Give proper credit to game developers and other people who involve Credit in the project. Setting Allow players to change the difficulties and text speed Load Game Load a save game from one of the three slot New Game Start a new game Inn A place where players can rest, purchase food, and listens to gossip Item Shop A place where players can buy and sell items. Weapon/Weapon Shop A place where players can buy and sell armor and weapon This involve in the beginning of the game where a player just started Storyline a new game Home Where a new game start Responsible to handle all the shops and other special locations. It Town also shows the bitmap corresponding to a particular shop Portal Teleport between towns that player has already visited. 7
World Map Combat Final Boss Victory/Defeat Responsible to handle all the traveling location in the world. Towns and other locations will be displayed on the world map Where a player fights a monster. The players have four options during combat: attack, defend, use item, and run. The last trail that a player has to go through before completing the game. It will has its own story section and combat interface Depending on the outcome of the combat with the final boss, different ending will appear. Header Files Instead of writing a header file for individual modules, I group the similar functions into Figure 3: GUI Flow Chart 8
a header files. I choose this arrangement for two reasons. One is that many modules use the same functions. Therefore, some modules do not require special functionalities. The other reason is that fewer header files reduces file-search overhead. 1. Animation.h This file contains functions that specialize in bitmap animation. The showintro() function is written for the Introduction module. The function displays slides of story. Another function, imageswap(), allow a bitmap is be loaded in a form dynamically. This function also includes the WinDrawChars() function that enables dynamic string output to the screen. 2. Combat.h The combat.h header file contains AttackSequence() function. This function will be called every time a combat occurs. It keeps a track on both monster and player s statistics. Two components exist in the function. One component is responsible to keep track of data when the player is attacking the monster. The other component is responsible to keep track of data when the monster is attacking the player. 3. UIConstant.h This file contains no functions, but it declares all the necessary constant values and variable for the GUI programming. UIConstant.h also keep tracks several important variables for the quest system. 4. Other Important Functions Although TownManagement() function is not a part of any header files, it servers an important purpose: management the various shops in a town. The function rotates town shops in a round robin fashion. Another important function would be the GeneralFormHandleEvent() function. This function handles all other forms resources that do not require any special care. 9
DEVELOPMENT PLAN Develop Platform: Develop Language: Simulator Tool: Window 98 SE Code Warrior and PalmOS SDK Palm Emulator The development schedule is loosely based on weekly progress reports on my web page. 1. Before week 3, finish all the basic reading on C programming for PalmPilot. The software for the game development should be set up. 2. By week 4, start to program simple program for Palm; get myself familiarize with CodeWarrior. 3. By week 5, program my first pieces of UI codes. The codes will consist of display form resources on Palm. 4. By week 6, finished with basic UI codes. Start working on the basic town structure system 5. By week 7, worked on a better implementation of the town system 6. By week 8, I obtained codes from Jack, and start working on the basic combat system 7. By week 9, attempted to merges my UI codes with Jack's database codes 8. By week 10, prepared for the final presentation and polishing what we have so far. PROJECT EVALUATION Overall, my specification of user interface is quite accurate because I had many discussions with Jack and Barry regarding the user interfaces. Most parts of our game are development entirely from my UI designs. However, the number of forms and the codes needed to support them were unexpectedly large because of the scale of our proposed game. I did not expect that our little game would require a large amount of form resources. Due to the natural of RPG game, a huge amount resource is devoted into world building. In other words, to immerse 10
the users with a sense of a fantasy world, we have to spend considerable time on form resources, such as towns, shops, and quest-related map location. The UI codes require maintaining these form resources had gotten quite huge. I realized that the amount of form resource is the most difficult part of specify. We understood that a RPG game would require intensive programming. Therefore, we spent many hours on breaking down the project into manageable modules. I had further divided my part into sub-modules displayed in Figure 3 of the Project Design section, so I can work on individual sub-modules without worry about other ones. Because I had defined the flow chart to help me, I did not have many problems integrating them into one big user interface. Although I had little problem programming the user interface, I recently discovered that my codes had little expandability. The lack of expandability had caused me problems on coding a multiple town system. To rectify the problem, I would have to rewrite some on my codes to take scaling into effect. The overall performance of my UI codes is good. The program is responsive to user inputs. The bitmap animation, however, can be sluggish sometime. I had written a couple functions to generate bitmap animation. Although these two functions are functional, I believed that I could improve the speed on them. To reduce over-defining variables in my UI codes, I decided to place most of them on global scope. Placing variables into global scope has some advantages. One of them is I can access the variable anywhere in the program. The ability to access variable anywhere saved me time to do type conversions for some tasks. CONCLUDING REMARKS We have completed all the fundamental functions such as basic town structure. In the basic town structure, we implemented all the necessary functions to support any number of shops in a town and their interactions with the town. I also finished the basic combat system. The basic 11
combat system consists of two major components: Player's Action and Monster's Action. During the combat, the system is supposed to calculate the basic stats of the player and the monster. We also have done the general user interface codes that handle all the possible interaction between the forms and the user. Although we have all the forms for individual shops and the UI code to integrated them into the game. However, these shops require databases to access the inventories. However, Jack is having problems with the record modification. Therefore both shop system and database management section half-completed. As for the database management itself, Jack has successfully implemented codes for database and record creation. However, the main problem lies in the record modification. Another part of the game that we have been working on but not yet completed is the multiple-town system. As it's implied in the name, a multiple-town system involves UI codes that is capable on loading and unloading a town at will. There are two approaches to the multiple-town system. One approach is to draw a skeleton town and append information onto it dynamically. Another approach is to development more forms for individual towns. I choose the later approach, but I have not finished the design yet. Also, the random combat event system is being development to add more variations and realism to the basic combat system. Storyline integration is partially completed as well. To fully integration the storyline into the game, I must communicate more often with Barry. As of now, I have no clue on how the story will progress. There are two major modules left untouched. One of the untouched module is the quest system. We devised a quest system because it will help us to move the story forward in the game. The quest system is also a complicated system to design. It required the completion to storyline integration and database management to keep track of what the user had done. However, none of 12
the its component are done yet. World map system is another module that is not implemented in the game yet. Although the project is officially over. Barry, Jack and I have agreed that we had already spend considerable time on it, and would continue the work to finish it. The next step for my UI codes would be the completion of the random combat event system. The system will randomly choose a monster, depending on user's character level. In general if user's character level is high, the system will randomly choosing a high level monsters from a pool of high level monster database. Of course, I need to talk to Jack to understand how the monster database would be implemented. As for the mid-range goals, I would like to finish programming chapter one of the story. CREDITS Pilot/Palm's Page: I get the sample source codes for their PocketRoque. Although it didn't really match our game design, but it gives some insights of some programming techniques. MemoPad2 of the Tutorial: I built my interface codes on top of MemoPad's skeleton interface codes. Jack Yuang: Responsible for database implementations, and other core-programming codes that supports my UI codes. He is also the original author for the combat system. Barry Chen: Responsible for all the graphical design. Him has the ability to produce amazing graphics. 13
BIBLIOGRAPHY Palm OS SDK Reference. Electronic ed. 3Com Corporation. September 1999. <www.palm.com> Palm OS Programmer's Companion. Electronic ed. 3Com Corporation. September 1999. <www.palm.com> CodeWarrior Palm OS Tutorial for Windows. Electronic ed. 3Com Corporation. September 1999. <www.palm.com> CodeWarrior Constructor for Palm OS Platform. Electronic ed. Metrowerk Inc. July 1999. <www.metrowerks.com> Palm IIIe Handheld Details. Palm Inc. 2 Feb. 2001 <http://www.palm.com/products/palmiiie/details.html> 14